From: Dave Chinner <david@fromorbit.com>
To: Alex Elder <elder@inktank.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/2] xfs: another memory barrier before wake_up_bit()
Date: Tue, 5 Feb 2013 10:26:17 +1100 [thread overview]
Message-ID: <20130204232617.GO2667@dastard> (raw)
In-Reply-To: <510FDE23.9050801@inktank.com>
On Mon, Feb 04, 2013 at 10:13:23AM -0600, Alex Elder wrote:
> In xfs_inode_item_unpin() there is a call to wake_up_bit() following
> an independent test for whether waiters should be awakened. This
> requires a memory barrier in order to guarantee correct operation
> (see the comment above wake_up_bit()).
>
> Signed-off-by: Alex Elder <elder@inktank.com>
> ---
> fs/xfs/xfs_inode_item.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c
> index d041d47..a7cacf7 100644
> --- a/fs/xfs/xfs_inode_item.c
> +++ b/fs/xfs/xfs_inode_item.c
> @@ -474,8 +474,10 @@ xfs_inode_item_unpin(
>
> trace_xfs_inode_unpin(ip, _RET_IP_);
> ASSERT(atomic_read(&ip->i_pincount) > 0);
> - if (atomic_dec_and_test(&ip->i_pincount))
> - wake_up_bit(&ip->i_flags, __XFS_IPINNED_BIT);
> + if (!atomic_dec_and_test(&ip->i_pincount))
> + return;
> + smp_mb();
> + wake_up_bit(&ip->i_flags, __XFS_IPINNED_BIT);
I'm not sure this a barrier is actually needed here. The "wake up"
bit is never stored or cleared anywhere in this case, it is used
only to define a wait channel and directed wake up. Hence the "need
a barrier so all CPUs see the cleared bit" case doesn't arise here.
We use an atomic variable instead, and that makes it safe.
If you read Documentation/atomic_ops.txt, you'll find that atomic
modification operations are required to have explicit barrier
semantics. i.e. that atomic_dec_and_test() must behave like it has
both a smp_mb() before and after the atomic operation. i.e:
Unlike the above routines, it is required that explicit memory
barriers are performed before and after the operation. It must be
done such that all memory operations before and after the atomic
operation calls are strongly ordered with respect to the atomic
operation itself.
So, the smp_mb() that is added here is redundant - the
atomic_dec_and_test() call already has the necesary memory barriers
that wake_up_bit() requires.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-02-04 23:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 16:12 [PATCH 0/2] xfs: insert memory barriers before wake_up_bit() Alex Elder
2013-02-04 16:13 ` [PATCH 1/2] xfs: memory barrier " Alex Elder
2013-02-04 23:06 ` Dave Chinner
2013-02-05 1:35 ` Alex Elder
2013-02-07 15:44 ` Ben Myers
2013-02-04 16:13 ` [PATCH 2/2] xfs: another " Alex Elder
2013-02-04 23:26 ` Dave Chinner [this message]
2013-02-05 1:38 ` Alex Elder
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=20130204232617.GO2667@dastard \
--to=david@fromorbit.com \
--cc=elder@inktank.com \
--cc=xfs@oss.sgi.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