... otherwise we just might free ffs with ffs->reset_work still on queue. That needs to be done after ffs_data_reset() - that's the cutoff point for configfs accesses (serialized on gadget_info->lock), which is where the schedule_work() would come from.
Signed-off-by: Al Viro <[email protected]> --- drivers/usb/gadget/function/f_fs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 0bcff49e1f11..27860fc0fd7d 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -2081,6 +2081,9 @@ ffs_fs_kill_sb(struct super_block *sb) struct ffs_data *ffs = sb->s_fs_info; ffs->state = FFS_CLOSING; ffs_data_reset(ffs); + // no configfs accesses from that point on, + // so no further schedule_work() is possible + cancel_work_sync(&ffs->reset_work); ffs_data_put(ffs); } } -- 2.47.3
