Bug 38602
Summary: | suspicious rcu_dereference_check() usage in block/cfq-iosched.c:2776 | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Christian Casteyde (casteyde.christian) |
Component: | Block Layer | Assignee: | Jens Axboe (axboe) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | florian, joshuacov, maciej.rutecki, paulmck, rjw |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.0-rc5 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 36912 | ||
Attachments: | dmesg-kernel-3.0-0.rc5.git0.1.fc16 |
Description
Christian Casteyde
2011-07-01 04:18:40 UTC
Created attachment 64442 [details]
dmesg-kernel-3.0-0.rc5.git0.1.fc16
I get a very similar message during boot with kernel-3.0-0.rc5.git0.1.fc16:
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
block/cfq-iosched.c:2776 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
3 locks held by scsi_scan_0/208:
#0: (&shost->scan_mutex){+.+.+.}, at: [<ffffffff8133d968>] scsi_scan_host_selected+0xbf/0x191
#1: (&eq->sysfs_lock){+.+...}, at: [<ffffffff8123902a>] elevator_exit+0x1d/0x4e
#2: (&(&q->__queue_lock)->rlock){..-...}, at: [<ffffffff8125032f>] cfq_exit_queue+0x47/0x179
stack backtrace:
Pid: 208, comm: scsi_scan_0 Not tainted 3.0-0.rc5.git0.1.fc16.x86_64 #1
Call Trace:
[<ffffffff81086e4d>] lockdep_rcu_dereference+0xa8/0xb0
[<ffffffff81250227>] __cfq_exit_single_io_context+0x78/0xd7
[<ffffffff81250353>] cfq_exit_queue+0x6b/0x179
[<ffffffff8123903e>] elevator_exit+0x31/0x4e
[<ffffffff8123d501>] blk_cleanup_queue+0x4f/0x68
[<ffffffff8133b931>] scsi_free_queue+0xe/0x10
[<ffffffff8133efb2>] __scsi_remove_device+0xac/0xb9
[<ffffffff8133cee8>] scsi_probe_and_add_lun+0xa6e/0xaab
[<ffffffff8133d5ff>] __scsi_scan_target+0x580/0x5d2
[<ffffffff81088007>] ? mark_lock+0x2d/0x220
[<ffffffff81089654>] ? mark_held_locks+0x4b/0x6d
[<ffffffff814f35d0>] ? _raw_spin_unlock_irqrestore+0x45/0x52
[<ffffffff81089781>] ? trace_hardirqs_on_caller+0x10b/0x12f
[<ffffffff8133d6a8>] scsi_scan_channel.part.2+0x57/0x72
[<ffffffff8133d9b2>] scsi_scan_host_selected+0x109/0x191
[<ffffffff8133daaf>] ? do_scsi_scan_host+0x75/0x75
[<ffffffff8133daaa>] do_scsi_scan_host+0x70/0x75
[<ffffffff8133dad2>] do_scan_async+0x23/0x142
[<ffffffff8133daaf>] ? do_scsi_scan_host+0x75/0x75
[<ffffffff8133daaf>] ? do_scsi_scan_host+0x75/0x75
[<ffffffff810745e1>] kthread+0xa8/0xb0
[<ffffffff814fb324>] kernel_thread_helper+0x4/0x10
[<ffffffff814f39d4>] ? retint_restore_args+0x13/0x13
[<ffffffff81074539>] ? __init_kthread_worker+0x5a/0x5a
[<ffffffff814fb320>] ? gs_change+0x13/0x13
The full dmesg is also attached. The notebook is aspire 5050
Any chance to get this fixed before v3.0 is out? I believe that 3181faa85bd (cfq-iosched: fix a rcu warning), which is in mainline, fixes this problem. Could you please try it out? Commit 2a9d6df425d7b46b23cbc8673b2dfefa4678abdb has been merged into master some hours ago. I'll wail till rc7 is out and report back if it fixes the warning. I tested this with kernel-3.0-0.rc6.git6.1.fc16.x86_64. Everything is fine now - no rcu warnings. This bug can be closed now (it is already). Very good, Joshua! Thank you for testing this! Fixed in 3.0-rc7 |