| Age | Commit message (Collapse) | Author |
|
|
|
Not sure how this didn't get committed before -- it was supposed to be
part of this change:
https://mail-index.netbsd.org/source-changes/2022/05/22/msg138764.html
|
|
|
|
- Don't enable queue 1-15 interrupt.
- Don't enable queue 0 interrupt when the queue work is being scheduled.
- OK'd by knakahara.
|
|
|
|
|
|
Since the changes this year to eliminate a host of races and
deadlocks in open, close, revoke, attach, and detach, closing the
last instance of a device special node has the side effect of waiting
for all concurrent I/O operations (read, write, ioctl, strategy, &c.)
on the device to complete.
Unfortunately, while this works for physical devices which revoke
open device nodes in their autoconf detach functions, as invoked by
some hardware interrupt indicating that the device is no longer
present, pseudo-devices like vnd(4) work differently -- or, work by
luck, or don't work any more.
VNDIOCCLR acts kind of like an autoconf detach function in that it
revokes open device nodes, which closes the last instance. But
VNDIOCCLR is itself called via ioctl, which is an I/O operation that
close waits for. So we end up with a deadlock, spec_io_drain waiting
for spec_close lower down in the call stack:
> spec_io_drain() at netbsd:spec_io_drain+0x84
> spec_close() at netbsd:spec_close+0x1c6
> VOP_CLOSE() at netbsd:VOP_CLOSE+0x38
> spec_node_revoke() at netbsd:spec_node_revoke+0x14d
> vcache_reclaim() at netbsd:vcache_reclaim+0x4e7
> vgone() at netbsd:vgone+0xcd
> vrevoke() at netbsd:vrevoke+0xfa
> genfs_revoke() at netbsd:genfs_revoke+0x13
> VOP_REVOKE() at netbsd:VOP_REVOKE+0x35
> vdevgone() at netbsd:vdevgone+0x64
> vnddoclear.part.0() at netbsd:vnddoclear.part.0+0xaa
> vndioctl() at netbsd:vndioctl+0x78c
> bdev_ioctl() at netbsd:bdev_ioctl+0x91
> spec_ioctl() at netbsd:spec_ioctl+0xa5
> VOP_IOCTL() at netbsd:VOP_IOCTL+0x41
> vn_ioctl() at netbsd:vn_ioctl+0xb3
> sys_ioctl() at netbsd:sys_ioctl+0x555
In the past, there was a workaround for what was presumably a crash
instead of a deadlock here: don't issue revoke (vdevgone) on the open
character devices for the minor number in use by the ioctl. If you
use, e.g., `vnconfig -u vnd0', and vnconfig(8) picks /dev/rvnd0c or
/dev/rvnd0d, that special case kicks in. But if you use `vnconfig -u
/dev/vnd0d', the ioctl will be issued on the block device instead, so
the special case doesn't kick in, so the operation deadlocks.
It is actually probably safe not to revoke the block device if what
the ioctl caller holds open is that, because specfs(9) forbids more
than one open of a block device, so nothing else can have it open
anyway.
Unclear what the consequences of failing to revoke the character
device are -- but this is what vnd(4) has done all along. cgd(4) and
ccd(4) also don't bother to revoke. We don't have a notion of
`revoke every file descriptor _except_ this one'; only a vnode as a
whole can be revoked, including all references to it.
This is a stop-gap measure to avoid a deadlock we are definitely
hitting on some users. A slightly better measure would be to revoke
the block or character device according to which one is being used,
but that requires a little more work with two different d_ioctl
functions -- and wouldn't address isues with the character device. A
proper solution requires identifying the appropriate protocol for all
of these pseudo-device disk drivers and using it uniformly for them.
Reported on current-users:
https://mail-index.netbsd.org/current-users/2022/05/27/msg042437.html
|
|
|
|
|
|
|
|
Also make it only happen in the error case so success doesn't clutter
up the console output.
|
|
|
|
|
|
Fixes PR kern/56857.
|
|
- Intel 7 Series (mobile) SATA Controller (AHCI):
rev. 0x04 sometimes fails to probe Seagate ST500LT012.
Reported by RVP. Thanks!
|
|
- Intel Braswell AHCI: rev. 0x35 fails for Seagate ST2000LX001.
- Intel 8 Series (desktop) SATA Controller (AHCI): rev. 0x04 fails for
Seagate ST1000LX015 and WD WD10JPVX, whereas it works without the
quirk for some SSD models...
Reported by Matthias Petermann. Thanks!
|
|
make sure that bus_dmamap_unload(9) [or bus_dmamap_destroy(9)] or
bus_dmamem_unmap(9) are preceding to freeing DMA buffer, if it is
loaded or mapped, respectively.
This is mandatory for some archs. See, e.g.:
http://www.nerv.org/netbsd/?q=id:20210511T013030Z.013443cc790088147e4beed43f53dedabeaf9312
http://www.nerv.org/netbsd/?q=id:20220511T172220Z.561179f0b6fcc5b9cd73e274f69d74e2ce9e4c93
For some drivers, resource leaks for error paths are fixed at
the same time.
XXX XXX XXX
Compile test only (at least one arch per driver).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
C2000 qat has two engines, however it doesn't have arbiter.
If we enable both engines, qat interrupts twice wrongly (and second
interrupt notice invalid data). So, we enable only one engine.
|
|
|
|
|
|
|
|
|
|
make sure that bus_dmamap_unload(9) [or bus_dmamap_destroy(9)] or
bus_dmamem_unmap(9) are preceding to freeing DMA buffer, if it is
loaded or mapped, respectively.
This is mandatory for some archs. See, e.g.:
http://www.nerv.org/netbsd/?q=id:20210511T013030Z.013443cc790088147e4beed43f53dedabeaf9312
http://www.nerv.org/netbsd/?q=id:20220511T172220Z.561179f0b6fcc5b9cd73e274f69d74e2ce9e4c93
XXX XXX XXX
Compile test only (for amd64/ALL).
Thanks riastradh@ for double check.
|
|
No functional change intended: all drivers already return zero
unconditionally.
|
|
|
|
|
|
|
|
|
|
Make sure to return zero, not error, when we've already done
crypto_done and set crp_etype.
|
|
If opencrypto passes a bad sid in, that's a bug in opencrypto that
needs to be fixed, not a user-triggered invalid input that we need to
fail gracefully on.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kernel i386/ALL compiles again.
|
|
|
|
|
|
|
|
XXX
This bug affected only armeb. Unfortunately, the systems including
armel still lock up eventually with NFS root on mvgbe(4)...
|
|
that mbuf. This is mandatory for some archs.
|
|
|