From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] locks: add missing memory barrier in break_deleg
Date: Tue, 10 Jun 2014 16:48:28 -0400 [thread overview]
Message-ID: <20140610204828.GL3957@fieldses.org> (raw)
In-Reply-To: <1402431276-14350-2-git-send-email-jlayton@poochiereds.net>
On Tue, Jun 10, 2014 at 04:14:35PM -0400, Jeff Layton wrote:
> break_deleg is subject to the same potential race as break_lease. Add
> a memory barrier to prevent it.
Acked-by: J. Bruce Fields <bfields@redhat.com>
Though we might now just move the comment, smp_mb(), and inode->i_flock
calls into __break_lease?
--b.
>
> Signed-off-by: Jeff Layton <jlayton@primarydata.com>
> ---
> include/linux/fs.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index c3f46e499dd0..22ae79650b82 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1914,6 +1914,12 @@ static inline int break_lease(struct inode *inode, unsigned int mode)
>
> static inline int break_deleg(struct inode *inode, unsigned int mode)
> {
> + /*
> + * Since this check is lockless, we must ensure that any refcounts
> + * taken are done before checking inode->i_flock. Otherwise, we could
> + * end up racing with tasks trying to set a new lease on this file.
> + */
> + smp_mb();
> if (inode->i_flock)
> return __break_lease(inode, mode, FL_DELEG);
> return 0;
> --
> 1.9.3
>
next prev parent reply other threads:[~2014-06-10 20:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 20:14 [PATCH 0/2] locks: some small locks.c fixups for v3.16 Jeff Layton
2014-06-10 20:14 ` [PATCH 1/2] locks: add missing memory barrier in break_deleg Jeff Layton
2014-06-10 20:48 ` J. Bruce Fields [this message]
2014-06-10 21:05 ` Jeff Layton
2014-06-10 20:14 ` [PATCH 2/2] locks: set fl_owner for leases back to current->files Jeff Layton
2014-06-10 20:53 ` J. Bruce Fields
2014-06-10 20:59 ` Jeff Layton
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=20140610204828.GL3957@fieldses.org \
--to=bfields@fieldses.org \
--cc=jlayton@poochiereds.net \
--cc=linux-fsdevel@vger.kernel.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.