On 11/1/21 2:01 PM, Tadeusz Struk wrote: > 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? People will take a look at it, but you sent it out on a Saturday right before a merge window, doing a 'ping' kind of followup on a Monday is way too soon. -- Jens Axboe
