From: Al Viro <viro@zeniv.linux.org.uk>
To: lkp@lists.01.org
Subject: Re: 266a9a8b41: WARNING:possible_recursive_locking_detected
Date: Mon, 16 Sep 2019 04:03:55 +0100 [thread overview]
Message-ID: <20190916030355.GZ1131@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190916025827.GY1131@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]
On Mon, Sep 16, 2019 at 03:58:27AM +0100, Al Viro wrote:
> On Mon, Sep 16, 2019 at 10:04:34AM +0800, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: 266a9a8b41803281e192151ae99779a7d50fc391 ("[PATCH] Re: Possible FS race condition between iterate_dir and d_alloc_parallel")
> > url: https://github.com/0day-ci/linux/commits/Al-Viro/Re-Possible-FS-race-condition-between-iterate_dir-and-d_alloc_parallel/20190915-052109
> >
> >
> > in testcase: rcutorture
> > with following parameters:
> >
> > runtime: 300s
> > test: default
> > torture_type: srcu
> >
> > test-description: rcutorture is rcutorture kernel module load/unload test.
> > test-url: https://www.kernel.org/doc/Documentation/RCU/torture.txt
> >
> >
> > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
> False positive; dget() on child while holding ->d_lock on parent is OK.
> We could turn that into explicit spin_lock_nested() on child + increment of
> ->d_count under that, but this is a pointless pessimization. Not sure
> what's the best way to tell lockdep to STFU here, but in this case it
> really ought to - locking order is correct.
Perhaps lockref_get_nested(struct lockref *lockref, unsigned int subclass)?
With s/spin_lock/spin_lock_nested/ in the body...
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: kernel test robot <lkp@intel.com>
Cc: "zhengbin (A)" <zhengbin13@huawei.com>,
jack@suse.cz, akpm@linux-foundation.org,
linux-fsdevel@vger.kernel.org,
"zhangyi (F)" <yi.zhang@huawei.com>,
renxudong1@huawei.com, Hou Tao <houtao1@huawei.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
lkp@01.org
Subject: Re: 266a9a8b41: WARNING:possible_recursive_locking_detected
Date: Mon, 16 Sep 2019 04:03:55 +0100 [thread overview]
Message-ID: <20190916030355.GZ1131@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190916025827.GY1131@ZenIV.linux.org.uk>
On Mon, Sep 16, 2019 at 03:58:27AM +0100, Al Viro wrote:
> On Mon, Sep 16, 2019 at 10:04:34AM +0800, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: 266a9a8b41803281e192151ae99779a7d50fc391 ("[PATCH] Re: Possible FS race condition between iterate_dir and d_alloc_parallel")
> > url: https://github.com/0day-ci/linux/commits/Al-Viro/Re-Possible-FS-race-condition-between-iterate_dir-and-d_alloc_parallel/20190915-052109
> >
> >
> > in testcase: rcutorture
> > with following parameters:
> >
> > runtime: 300s
> > test: default
> > torture_type: srcu
> >
> > test-description: rcutorture is rcutorture kernel module load/unload test.
> > test-url: https://www.kernel.org/doc/Documentation/RCU/torture.txt
> >
> >
> > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
> False positive; dget() on child while holding ->d_lock on parent is OK.
> We could turn that into explicit spin_lock_nested() on child + increment of
> ->d_count under that, but this is a pointless pessimization. Not sure
> what's the best way to tell lockdep to STFU here, but in this case it
> really ought to - locking order is correct.
Perhaps lockref_get_nested(struct lockref *lockref, unsigned int subclass)?
With s/spin_lock/spin_lock_nested/ in the body...
next prev parent reply other threads:[~2019-09-16 3:03 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 14:44 Possible FS race condition between iterate_dir and d_alloc_parallel zhengbin (A)
2019-09-03 15:40 ` Al Viro
2019-09-03 15:41 ` Al Viro
2019-09-04 6:15 ` zhengbin (A)
2019-09-05 17:47 ` Al Viro
2019-09-06 0:55 ` Jun Li
2019-09-06 2:00 ` Al Viro
2019-09-06 2:32 ` zhengbin (A)
2019-09-09 14:10 ` zhengbin (A)
2019-09-09 14:59 ` Al Viro
2019-09-09 15:10 ` zhengbin (A)
[not found] ` <7e32cda5-dc89-719d-9651-cf2bd06ae728@huawei.com>
2019-09-10 21:53 ` Al Viro
2019-09-10 22:17 ` Al Viro
2019-09-14 16:16 ` [PATCH] " Al Viro
2019-09-14 16:49 ` Linus Torvalds
2019-09-14 17:01 ` Al Viro
2019-09-14 17:15 ` Linus Torvalds
2019-09-14 20:04 ` Al Viro
2019-09-14 22:57 ` Linus Torvalds
2019-09-15 0:50 ` Al Viro
2019-09-15 1:41 ` Linus Torvalds
2019-09-15 16:02 ` Al Viro
2019-09-15 17:58 ` Linus Torvalds
2019-09-21 14:07 ` Al Viro
2019-09-21 16:21 ` Linus Torvalds
2019-09-21 17:18 ` Al Viro
2019-09-21 17:38 ` Linus Torvalds
2019-09-24 2:52 ` Al Viro
2019-09-24 13:30 ` Josef Bacik
2019-09-24 14:51 ` Al Viro
2019-09-24 15:01 ` Josef Bacik
2019-09-24 15:11 ` Al Viro
2019-09-24 15:26 ` Josef Bacik
2019-09-24 16:33 ` Al Viro
[not found] ` <CAHk-=wiJ1eY7y6r_cFNRPCqD+BJZS7eJeQFO6OrXxRFjDAipsQ@mail.gmail.com>
2019-09-29 5:29 ` Al Viro
2019-09-25 11:59 ` Amir Goldstein
2019-09-25 12:22 ` Al Viro
2019-09-25 12:34 ` Amir Goldstein
2019-09-22 21:29 ` Al Viro
2019-09-23 3:32 ` zhengbin (A)
2019-09-23 5:08 ` Al Viro
2019-09-16 2:04 ` 266a9a8b41: WARNING:possible_recursive_locking_detected kernel test robot
2019-09-16 2:58 ` Al Viro
2019-09-16 2:58 ` Al Viro
2019-09-16 3:03 ` Al Viro [this message]
2019-09-16 3:03 ` Al Viro
2019-09-16 3:44 ` Linus Torvalds
2019-09-16 3:44 ` Linus Torvalds
2019-09-16 17:16 ` Al Viro
2019-09-16 17:16 ` Al Viro
2019-09-16 17:29 ` Al Viro
2019-09-16 17:29 ` Al Viro
2019-09-17 8:59 ` Rong Chen
2019-09-17 7:03 ` zhengbin
2019-09-17 12:01 ` Al Viro
2019-09-17 12:01 ` Al Viro
2019-09-19 3:36 ` zhengbin
2019-09-19 3:36 ` zhengbin (A)
2019-09-19 3:55 ` Al Viro
2019-09-19 3:55 ` Al Viro
2019-09-19 4:16 ` zhengbin
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=20190916030355.GZ1131@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=lkp@lists.01.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.