From: Jens Axboe <axboe@fb.com>
To: <paulmck@linux.vnet.ibm.com>, Tejun Heo <tj@kernel.org>
Cc: kernel test robot <xiaolong.ye@intel.com>, <lkp@01.org>,
Jens Axboe <axboe@kernel.dk>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [writeback] 8bc4ad9498: INFO: suspicious RCU usage. ]
Date: Fri, 2 Sep 2016 09:49:25 -0600 [thread overview]
Message-ID: <1a774b3f-9fdc-b620-9a35-d3e7ff18177a@fb.com> (raw)
In-Reply-To: <20160902153601.GM16261@linux.vnet.ibm.com>
On 09/02/2016 09:36 AM, Paul E. McKenney wrote:
> On Fri, Sep 02, 2016 at 10:56:22AM -0400, Tejun Heo wrote:
>> (cc'ing Paul, hi!)
>>
>> Hello,
>>
>> On Thu, Sep 01, 2016 at 02:13:34PM -0600, Jens Axboe wrote:
>>> On 09/01/2016 04:21 AM, kernel test robot wrote:
>>>> [ 7.323356] cdrom: Uniform CD-ROM driver Revision: 3.20
>>>> [ 7.334239]
>>>> [ 7.337256] ===============================
>>>> [ 7.340532] [ INFO: suspicious RCU usage. ]
>>>> [ 7.342419] 4.8.0-rc4-00008-g8bc4ad9 #1 Not tainted
>>>> [ 7.347065] -------------------------------
>>>> [ 7.350132] include/linux/cgroup.h:435 suspicious rcu_dereference_check() usage!
>
> Lockdep does not believe that any locks are held, correct?
Which is correct, the queue lock has been dropped at this point.
>>>> [ 7.410074] Call Trace:
>>>> [ 7.411328] [<ffffffff8178ed3b>] dump_stack+0x82/0xb8
>>>> [ 7.413982] [<ffffffff81123472>] lockdep_rcu_suspicious+0xf7/0x100
>>>> [ 7.415828] [<ffffffff817873f4>] bio_blkcg+0x89/0x93
>>>> [ 7.417336] [<ffffffff817891f0>] check_blkcg_changed+0x58/0x1b8
>>>> [ 7.428722] [<ffffffff81789b90>] cfq_set_request+0xd1/0x2a3
>>>> [ 7.439690] [<ffffffff81763fe3>] elv_set_request+0x1f/0x24
>>>> [ 7.442157] [<ffffffff8176856d>] get_request+0x38f/0x77f
>>>> [ 7.447449] [<ffffffff817689c2>] blk_get_request+0x65/0xa8
>>>> [ 7.449868] [<ffffffff81c692df>] ide_cd_queue_pc+0x76/0x19d
>>>> [ 7.453757] [<ffffffff81c695ee>] cdrom_check_status+0x51/0x53
>>>> [ 7.455372] [<ffffffff81c6a27e>] ide_cdrom_check_events_real+0x20/0x3f
>>>> [ 7.457294] [<ffffffff82579f94>] cdrom_update_events+0x18/0x21
>>>> [ 7.458987] [<ffffffff82579faf>] cdrom_check_events+0x12/0x1f
>>>> [ 7.460713] [<ffffffff81c68317>] idecd_check_events+0x1c/0x1e
>>>> [ 7.462393] [<ffffffff81778d12>] disk_check_events+0x47/0x103
>>>> [ 7.464129] [<ffffffff81778dea>] disk_events_workfn+0x1c/0x1e
>>>> [ 7.465844] [<ffffffff810fcafa>] process_one_work+0x272/0x4ee
>>>> [ 7.467462] [<ffffffff810fd247>] worker_thread+0x1eb/0x2c9
>>
>> The warning is from
>>
>> #define task_css_set_check(task, __c) \
>> rcu_dereference_check((task)->cgroups, \
>> lockdep_is_held(&cgroup_mutex) || \
>> lockdep_is_held(&css_set_lock) || \
>> ((task)->flags & PF_EXITING) || (__c))
>>
>> which is used by bio_blkcg() which is called by the following code in
>> check_blkcg_changed().
>>
>> rcu_read_lock();
>> serial_nr = bio_blkcg(bio)->css.serial_nr;
>> rcu_read_unlock();
>>
>> So, I have no idea. It looks like rcu_dereference_check() is being
>> called with rcu read locked but still triggering suspicious RCU usage
>> warning.
>
> Perhaps there is an rcu_read_unlock() somewhere on the code path?
>
>> The code hasn't changed for quite a while now, so it's also really
>> weird that it's triggering now. Paul, does anything ring a bell?
>
> I have not see something like this recently.
The question is if it's really new, or just re-triggering because the
writeback branch changes that function? It's further down though, so
can't impact the RCU section. And the writeback changes don't have any
RCU code in them...
--
Jens Axboe
next prev parent reply other threads:[~2016-09-02 15:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 10:21 kernel test robot
2016-09-01 20:13 ` Jens Axboe
2016-09-02 14:56 ` Tejun Heo
2016-09-02 15:36 ` Paul E. McKenney
2016-09-02 15:49 ` Jens Axboe [this message]
2016-09-02 17:00 ` Paul E. McKenney
2016-09-02 18:00 ` Tejun Heo
2016-09-07 16:41 ` Tejun Heo
2016-09-07 19:25 ` Jens Axboe
2016-09-08 1:43 ` [LKP] " Fengguang Wu
2016-09-08 2:04 ` Ye Xiaolong
2016-09-08 15:52 ` Jens Axboe
2016-09-09 0:46 ` Ye Xiaolong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1a774b3f-9fdc-b620-9a35-d3e7ff18177a@fb.com \
--to=axboe@fb.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tj@kernel.org \
--cc=xiaolong.ye@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome