[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 07 Jul 2016 15:14:13 +0100
From: David Howells <dhowells@...hat.com>
To: Jeff Layton <jlayton@...hat.com>,
Andreas Gruenbacher <agruenba@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>
Cc: dhowells@...hat.com, Christoph Hellwig <hch@...radead.org>,
"Theodore Ts'o" <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
"J. Bruce Fields" <bfields@...ldses.org>,
Trond Myklebust <trond.myklebust@...marydata.com>,
Anna Schumaker <anna.schumaker@...app.com>,
Dave Chinner <david@...morbit.com>, linux-ext4@...r.kernel.org,
xfs@....sgi.com, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-cifs@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH v23 13/22] vfs: Cache richacl in struct inode
Jeff Layton <jlayton@...hat.com> wrote:
> > + if (cmpxchg(&inode->i_acl, ACL_NOT_CACHED, sentinel) != ACL_NOT_CACHED)
> > + /* fall through */ ;
> > +
>
> So you do the same thing regardless of the outcome of the above? Why
> bother with the if at all here? Just do the cmpxchg and toss out the
> result.
gcc might complain if you don't check the result.
However, this does look like it's subject to a thundering herd problem. If
30000 processes all look at the ACL at the same time on a network fs, could
that cause 30000 RPC calls to be transmitted for the same thing?
David
Powered by blists - more mailing lists