From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Milton Miller <miltonm@bga.com>
Cc: Minchan Kim <minchan.kim@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@vger.kernel.org,
linux-ext4@vger.kernel.org, "Ted Ts'o" <tytso@mit.edu>,
Arun Bhanu <ab@arunbhanu.com>
Subject: Re: [BUG?] [Ext4] INFO: suspicious rcu_dereference_check() usage
Date: Sun, 21 Nov 2010 22:16:19 -0800 [thread overview]
Message-ID: <20101122061619.GA2764@linux.vnet.ibm.com> (raw)
In-Reply-To: <rcu-radix-tree@mdm.bga.com>
On Sun, Nov 21, 2010 at 09:31:14PM -0600, Milton Miller wrote:
> On 2010-11-22 at around 0:38:49, Minchan Kim wrote:
> > On Mon, Nov 22, 2010 at 2:37 AM, Ted Ts'o <tytso@mit.edu> wrote:
> > > On Mon, Nov 22, 2010 at 12:39:49AM +0900, Minchan Kim wrote:
> > > >
> > > > I think it's no problem.
> > > >
> > > > That's because migration always holds lock_page on the file page.
> > > > So the page couldn't remove from radix.
> > >
> > > It may be "ok" in that it won't cause a race, but it still leaves an
> > > unsightly warning if LOCKDEP is enabled, and LOCKDEP warnings will
> > > cause /proc_lock_stat to be disabled. So I think it still needs to be
> > > fixed by adding rcu_read_lock()/rcu_read_unlock() to
> > > migrate_page_move_mapping().
> > >
> > > - Ted
> > >
> >
> > Yes. if it is really "ok" about race, we will add rcu_read_lock with
> > below comment to prevent false positive.
> > "suppress RCU lockdep false positives".
> > But I am not sure it's good although rcu_read_lock is little cost.
> > Whenever we find false positive, should we add rcu_read_lock to
> > suppress although it's no problem in real product?
> > Couldn't we provide following function? (or we might have already it
> > but I missed it. )
> >
> > /*
> > * Suppress RCU lockdep false positive.
> > */
> > #ifdef CONFIG_PROVE_RCU
> > #define rcu_read_lock_suppress rcu_read_lock
> > #else
> > #define rcu_read_lock_suppress
> > #endif
>
> No, you don't need anything like this, as rcu_dereference_check already
> takes a test for alternate locking.
>
> However, looking more closely at the code, it appears this is the
> "the tree is write locked" case as described in radix-tree.h
>
> Looking at rcupdate.h, perhaps we need a version of radix_tree_deref_slot
> that uses rcu_dereference_protected?
>
> Copying Paul McKenney for rcu ...
This approach could work. One way of doing it would be to add a second
argument:
static inline void *radix_tree_deref_slot_check(void **pslot, int ldc)
{
void *ret = rcu_dereference_check(*pslot, ldc);
if (unlikely(radix_tree_is_indirect_ptr(ret)))
ret = RADIX_TREE_RETRY;
return ret;
}
static inline void *radix_tree_deref_slot(void **pslot)
{
return radix_tree_deref_slot_check(pslot, rcu_read_lock_held());
}
Another alternative would have radix_tree_deref_slot() pass "1" into
the "ldc" argument, which reduces splats but at the expense of failing
to detect problems. ;-)
Thanx, Paul
next prev parent reply other threads:[~2010-11-22 6:16 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-21 11:26 [BUG?] [Ext4] INFO: suspicious rcu_dereference_check() usage Arun Bhanu
2010-11-21 13:30 ` Ted Ts'o
2010-11-21 13:30 ` Ted Ts'o
2010-11-21 13:30 ` Ted Ts'o
2010-11-21 15:39 ` Minchan Kim
2010-11-21 15:39 ` Minchan Kim
2010-11-21 15:39 ` Minchan Kim
2010-11-21 17:37 ` Ted Ts'o
2010-11-21 17:37 ` Ted Ts'o
2010-11-22 0:38 ` Minchan Kim
2010-11-22 0:38 ` Minchan Kim
2010-11-22 0:38 ` Minchan Kim
2010-11-22 3:31 ` Milton Miller
2010-11-22 6:16 ` Paul E. McKenney [this message]
2010-12-07 19:01 ` [BUG?] memory hotplug: include/linux/radix-tree.h:145 invoked rcu_dereference_check() without protection! Gerald Schaefer
2010-12-08 1:19 ` KAMEZAWA Hiroyuki
2010-12-16 13:50 ` Gerald Schaefer
2010-12-17 0:04 ` Minchan Kim
2010-12-17 0:04 ` Minchan Kim
2010-12-17 5:47 ` Paul E. McKenney
2010-12-17 5:47 ` Paul E. McKenney
2010-12-17 5:59 ` Eric Dumazet
2010-12-17 5:59 ` Eric Dumazet
2010-12-17 15:08 ` Minchan Kim
2010-12-17 16:03 ` Paul E. McKenney
2010-12-17 16:03 ` Paul E. McKenney
2010-12-17 8:39 ` Mel Gorman
2010-12-17 8:39 ` Mel Gorman
2010-12-17 9:28 ` Mel Gorman
2010-12-17 15:22 ` Minchan Kim
2010-12-17 15:13 ` Minchan Kim
2010-12-17 15:13 ` Minchan Kim
2010-12-17 16:01 ` Paul E. McKenney
2010-12-17 16:01 ` Paul E. McKenney
2010-11-23 7:16 ` [BUG?] [Ext4] INFO: suspicious rcu_dereference_check() usage KOSAKI Motohiro
2010-11-23 7:16 ` KOSAKI Motohiro
2010-11-23 7:16 ` KOSAKI Motohiro
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=20101122061619.GA2764@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=ab@arunbhanu.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@vger.kernel.org \
--cc=miltonm@bga.com \
--cc=minchan.kim@gmail.com \
--cc=tytso@mit.edu \
/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.