[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180108133025.GA31867@bombadil.infradead.org>
Date: Mon, 8 Jan 2018 05:30:25 -0800
From: Matthew Wilcox <willy@...radead.org>
To: Jeff Layton <jlayton@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
viro@...iv.linux.org.uk, linux-nfs@...r.kernel.org,
bfields@...ldses.org, neilb@...e.de, jack@...e.de,
linux-ext4@...r.kernel.org, tytso@....edu,
adilger.kernel@...ger.ca, linux-xfs@...r.kernel.org,
darrick.wong@...cle.com, david@...morbit.com,
linux-btrfs@...r.kernel.org, clm@...com, jbacik@...com,
dsterba@...e.com, linux-integrity@...r.kernel.org,
zohar@...ux.vnet.ibm.com, dmitry.kasatkin@...il.com,
linux-afs@...ts.infradead.org, dhowells@...hat.com,
jaltman@...istor.com
Subject: Re: [PATCH v4 19/19] fs: handle inode->i_version more efficiently
On Fri, Dec 22, 2017 at 07:05:56AM -0500, Jeff Layton wrote:
> + cur = inode_peek_iversion_raw(inode);
> + for (;;) {
> + /* If flag is clear then we needn't do anything */
> + if (!force && !(cur & I_VERSION_QUERIED))
> + return false;
> + /* Since lowest bit is flag, add 2 to avoid it */
> + new = (cur & ~I_VERSION_QUERIED) + I_VERSION_INCREMENT;
Isn't this an extraordinarily complicated way of spelling:
new = cur + 1;
We know 'cur' has I_VERSION_QUERIED set, so clearing that bit and adding
two is going to be the same as adding 1 ... right?
Powered by blists - more mailing lists