^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) Lockdep-RCU Splat
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) Lockdep-RCU was added to the Linux kernel in early 2010
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) (http://lwn.net/Articles/371986/). This facility checks for some common
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) misuses of the RCU API, most notably using one of the rcu_dereference()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) family to access an RCU-protected pointer without the proper protection.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) When such misuse is detected, an lockdep-RCU splat is emitted.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) The usual cause of a lockdep-RCU slat is someone accessing an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) RCU-protected data structure without either (1) being in the right kind of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) RCU read-side critical section or (2) holding the right update-side lock.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) This problem can therefore be serious: it might result in random memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) overwriting or worse. There can of course be false positives, this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) being the real world and all that.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) So let's look at an example RCU lockdep splat from 3.0-rc5, one that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) has long since been fixed::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) WARNING: suspicious RCU usage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) -----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) other info that might help us debug this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) rcu_scheduler_active = 1, debug_locks = 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) 3 locks held by scsi_scan_6/1552:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) #0: (&shost->scan_mutex){+.+.}, at: [<ffffffff8145efca>]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) scsi_scan_host_selected+0x5a/0x150
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) #1: (&eq->sysfs_lock){+.+.}, at: [<ffffffff812a5032>]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) elevator_exit+0x22/0x60
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) #2: (&(&q->__queue_lock)->rlock){-.-.}, at: [<ffffffff812b6233>]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) cfq_exit_queue+0x43/0x190
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) stack backtrace:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) Call Trace:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) [<ffffffff810abb9b>] lockdep_rcu_dereference+0xbb/0xc0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) [<ffffffff812b6139>] __cfq_exit_single_io_context+0xe9/0x120
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) [<ffffffff812b626c>] cfq_exit_queue+0x7c/0x190
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) [<ffffffff812a5046>] elevator_exit+0x36/0x60
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) [<ffffffff812a802a>] blk_cleanup_queue+0x4a/0x60
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) [<ffffffff8145cc09>] scsi_free_queue+0x9/0x10
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) [<ffffffff81460944>] __scsi_remove_device+0x84/0xd0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) [<ffffffff8145dca3>] scsi_probe_and_add_lun+0x353/0xb10
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) [<ffffffff817da069>] ? error_exit+0x29/0xb0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) [<ffffffff817d98ed>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) [<ffffffff8145e722>] __scsi_scan_target+0x112/0x680
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) [<ffffffff812c690d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) [<ffffffff817da069>] ? error_exit+0x29/0xb0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) [<ffffffff812bcc60>] ? kobject_del+0x40/0x40
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) [<ffffffff8145ed16>] scsi_scan_channel+0x86/0xb0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) [<ffffffff8145f0b0>] scsi_scan_host_selected+0x140/0x150
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) [<ffffffff8145f149>] do_scsi_scan_host+0x89/0x90
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) [<ffffffff8145f170>] do_scan_async+0x20/0x160
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) [<ffffffff8145f150>] ? do_scsi_scan_host+0x90/0x90
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) [<ffffffff810975b6>] kthread+0xa6/0xb0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) [<ffffffff817db154>] kernel_thread_helper+0x4/0x10
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) [<ffffffff81066430>] ? finish_task_switch+0x80/0x110
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) [<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) [<ffffffff81097510>] ? __kthread_init_worker+0x70/0x70
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) [<ffffffff817db150>] ? gs_change+0xb/0xb
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) if (rcu_dereference(ioc->ioc_data) == cic) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) This form says that it must be in a plain vanilla RCU read-side critical
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) section, but the "other info" list above shows that this is not the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) case. Instead, we hold three locks, one of which might be RCU related.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) And maybe that lock really does protect this reference. If so, the fix
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) is to inform RCU, perhaps by changing __cfq_exit_single_io_context() to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) take the struct request_queue "q" from cfq_exit_queue() as an argument,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) which would permit us to invoke rcu_dereference_protected as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) if (rcu_dereference_protected(ioc->ioc_data,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) lockdep_is_held(&q->queue_lock)) == cic) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) With this change, there would be no lockdep-RCU splat emitted if this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) code was invoked either from within an RCU read-side critical section
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) or with the ->queue_lock held. In particular, this would have suppressed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) the above lockdep-RCU splat because ->queue_lock is held (see #2 in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) list above).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) On the other hand, perhaps we really do need an RCU read-side critical
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) section. In this case, the critical section must span the use of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) return value from rcu_dereference(), or at least until there is some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) reference count incremented or some such. One way to handle this is to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) add rcu_read_lock() and rcu_read_unlock() as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) rcu_read_lock();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) if (rcu_dereference(ioc->ioc_data) == cic) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) spin_lock(&ioc->lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) rcu_assign_pointer(ioc->ioc_data, NULL);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) spin_unlock(&ioc->lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) rcu_read_unlock();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) With this change, the rcu_dereference() is always within an RCU
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) read-side critical section, which again would have suppressed the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) above lockdep-RCU splat.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) But in this particular case, we don't actually dereference the pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) returned from rcu_dereference(). Instead, that pointer is just compared
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) to the cic pointer, which means that the rcu_dereference() can be replaced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) by rcu_access_pointer() as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) if (rcu_access_pointer(ioc->ioc_data) == cic) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) Because it is legal to invoke rcu_access_pointer() without protection,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) this change would also suppress the above lockdep-RCU splat.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags