Summary: | devmatch: panic: general protection fault: sysctl_devices() -> sysctl_root_handler_locked() in hw.bus.devices sysctl handler when plugging in USB mouse | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | sigsys | ||||
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
Status: | Open --- | ||||||
Severity: | Affects Some People | CC: | emaste, hselasky, imp, usb | ||||
Priority: | --- | Keywords: | crash, needs-qa | ||||
Version: | CURRENT | Flags: | koobs:
maintainer-feedback?
(imp) koobs: maintainer-feedback? (hselasky) koobs: mfc-stable13? koobs: mfc-stable12? |
||||
Hardware: | Any | ||||||
OS: | Any | ||||||
URL: | https://twitter.com/ngortheone/status/1566802139858763776 | ||||||
Attachments: |
|
Description
sigsys
2020-10-12 23:01:52 UTC
Received report of what appears to be the same issue from a user on Twitter. Have requested they attach system information and crash traceback, pending. We have a patch in comment 0, which has one confirmation of resolution, but may require a rebase against latest CURRENT. @Reporter If you're able to produce an updated patch, please do so, thank you ^Triage: Request feedback from folks recently in and around kern/subr_bus, devmatch and USB I'll take a look at this. I think this is due to the nature of Giant unlocking itself when we think it is protecting the bus stuff. I have a different patch than sigsys' patch that converts Giant into a real lock, which sigsys' patch doesn't quite do. I worry that it will cause a lot of other problems if we don't do that and/or expose deadlock situations in other drivers / busses. All the places that use the lock *should* have giant locked already. Created attachment 236405 [details]
updated patch
Here's the refreshed patch in case it helps until a better fix is developed. Looking at it, I suspect it would be better to unlock before calling kobj_delete() in device_delete_child()... But I no longer have the panic-inducing mouse to test it. It gave out.
Warner: It's just a list, why can't you use a regular mutex to protect it? --HPS (In reply to Hans Petter Selasky from comment #4) Warner: Looked at the wrong patch. I think we can just switch the bus lock routines over to using an sx lock w/o adding or removing other locking which may be tricky for some of the consumers of newbus (they already cope with Giant though, so a giant-like sx lock I think will be fine). I've been looking for a way to reproduce this locally, since otherwise it's very hard to test that the fix works for sure... and my new-bus pessimism leads me to believe that any fix in this area will lead to further problem reports, maybe delayed by weeks or months. |