Messages in this thread | | | Date | Mon, 1 Nov 2021 13:01:42 -0700 | Subject | Re: general protection fault in del_gendisk | From | Tadeusz Struk <> |
| |
On 10/29/21 12:13, Tadeusz Struk wrote: > Hi, > I'm looking at a bug found by the syzkaller robot [1], and I just wanted > to confirm that my understanding is correct, and the issue can be closed. > First, the kernel is configured with some fault injections enabled: > > CONFIG_FAULT_INJECTION=y > CONFIG_FAILSLAB=y > CONFIG_FAIL_PAGE_ALLOC=y > > The test adds loop devices, which causes some entries in sysfs to be created. > It does some magic with ioctls, which calls: > __device_add_disk() -> register_disk() > which eventually triggers sysfs_create_files() and it crashes there, > in line 627 [2], because the fault injector logic triggers it. > That can be seen in the trace [3]: > [ 34.089707][ T1813] FAULT_INJECTION: forcing a failure. > > Sysfs code returns a -ENOMEM error, but because the __device_add_disk() > implementation mostly uses void function, and doesn't return on errors [4] > it goes farther, hits some warnings, like: > disk_add_events() -> sysfs_create_files() -> sysfs_create_file_ns() - > WARN() > and eventually triggers general protection fault in sysfs code, and panics there. > > I think for this to recover and return an error to the caller via ioctl() > the __device_add_disk() code would need be reworked to handle errors, > and return errors to the caller. > My question is: is it implemented like this by design? Are there any plans > to make it fail more gracefully?
Hi, Any comments on this one?
-- Thanks, Tadeusz
| |