lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 10 Jan 2018 15:12:42 +0100
From:   Krzysztof Kozlowski <>
To:     Jeff Layton <>
Subject: Re: [PATCH v5 19/19] fs: handle inode->i_version more efficiently

On Tue, Jan 9, 2018 at 3:10 PM, Jeff Layton <> wrote:
> From: Jeff Layton <>
> Since i_version is mostly treated as an opaque value, we can exploit that
> fact to avoid incrementing it when no one is watching. With that change,
> we can avoid incrementing the counter on writes, unless someone has
> queried for it since it was last incremented. If the a/c/mtime don't
> change, and the i_version hasn't changed, then there's no need to dirty
> the inode metadata on a write.
> Convert the i_version counter to an atomic64_t, and use the lowest order
> bit to hold a flag that will tell whether anyone has queried the value
> since it was last incremented.
> When we go to maybe increment it, we fetch the value and check the flag
> bit.  If it's clear then we don't need to do anything if the update
> isn't being forced.
> If we do need to update, then we increment the counter by 2, and clear
> the flag bit, and then use a CAS op to swap it into place. If that
> works, we return true. If it doesn't then do it again with the value
> that we fetch from the CAS operation.
> On the query side, if the flag is already set, then we just shift the
> value down by 1 bit and return it. Otherwise, we set the flag in our
> on-stack value and again use cmpxchg to swap it into place if it hasn't
> changed. If it has, then we use the value from the cmpxchg as the new
> "old" value and try again.
> This method allows us to avoid incrementing the counter on writes (and
> dirtying the metadata) under typical workloads. We only need to increment
> if it has been queried since it was last changed.
> Signed-off-by: Jeff Layton <>
> Reviewed-by: Jan Kara <>
> ---
>  include/linux/fs.h       |   2 +-
>  include/linux/iversion.h | 210 ++++++++++++++++++++++++++++++++++-------------
>  2 files changed, 155 insertions(+), 57 deletions(-)

Works fine on my nfsroot configuration so looks like the issues from
v4 are gone. FWIW:
Tested-by: Krzysztof Kozlowski <>

Best regards,

Powered by blists - more mailing lists