When device is in attaching state, detach should return EBUSY instead of success. In other case, there could be race between attach and detach during driver unloading. If driver goes sleep and releases GIANT lock during attaching, unloading module could start. In such case when attach continues after module unload, page fault "supervisor read instruction, page not present" occurred.
Details
Running multiple (~100) kldload; kldunload on driver that sleeps in attach (for example ENA on AWS instance).
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
It's an OK workaround, but the real problem is that we're not properly interlocked elsewhere.
sys/kern/subr_bus.c | ||
---|---|---|
3005 ↗ | (On Diff #54453) | Please add a comment that this is a horrific hack designed to cope with busses that aren't properly locked that allow entry into both attach and detach. Sadly, most busses are like this in the tree, and it's one of the big issues with my work trying to properly lock newbus. |
sys/kern/subr_bus.c | ||
---|---|---|
3005 ↗ | (On Diff #54453) | Warner is it worth going a little further than a comment, and emitting a warning upon DS_ATTACHING? |
sys/kern/subr_bus.c | ||
---|---|---|
3005 ↗ | (On Diff #54453) | How about following then: if (dev->state == DS_BUSY) return (EBUSY); if (dev->state == DS_ATTACHING) { device_printf(dev, "device in attaching state! Deferring detach.\n"); return (EBUSY); } |
sys/kern/subr_bus.c | ||
---|---|---|
3005 ↗ | (On Diff #54453) | This makes me happier since we warn about the problem, even if the root cause is well beyond the scope of this review to fix. |
sys/kern/subr_bus.c | ||
---|---|---|
3005 ↗ | (On Diff #54453) | I also added mentioning the work-around character of the patch in the commit log (r344676.) Thanks, |