linux/net/rfkill
Johannes Berg f2ac54ebf8 net: rfkill: reduce data->mtx scope in rfkill_fop_open
In syzbot runs, lockdep reports that there's a (potential)
deadlock here of data->mtx being locked recursively. This
isn't really a deadlock since they are different instances,
but lockdep cannot know, and teaching it would be far more
difficult than other fixes.

At the same time we don't even really _need_ the mutex to
be locked in rfkill_fop_open(), since we're modifying only
a completely fresh instance of 'data' (struct rfkill_data)
that's not yet added to the global list.

However, to avoid any reordering etc. within the globally
locked section, and to make the code look more symmetric,
we should still lock the data->events list manipulation,
but also need to lock _only_ that. So do that.

Reported-by: syzbot+509238e523e032442b80@syzkaller.appspotmail.com
Fixes: 2c3dfba4cf ("rfkill: sync before userspace visibility/changes")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-11 16:55:10 +02:00
..
core.c net: rfkill: reduce data->mtx scope in rfkill_fop_open 2023-10-11 16:55:10 +02:00
input.c rfkill: use DEFINE_SPINLOCK() for spinlock 2021-04-08 10:16:53 +02:00
Kconfig
Makefile
rfkill-gpio.c net: rfkill: gpio: prevent value glitch during probe 2023-10-11 16:36:52 +02:00
rfkill.h