I
don't think it'll be ok to call ->getattr while holding a spinlock.
> /* userspace relies on this representation of dev_t */
> seq_printf(f, "%d %02x:%02x:%ld ", fl_pid,
> - MAJOR(inode->i_sb->s_dev),
> -
On Wed, 2018-01-31 at 08:46 -0800, Linus Torvalds wrote:
> On Wed, Jan 31, 2018 at 4:29 AM, Jeff Layton <jlay...@kernel.org> wrote:
> >
> > Do you mind just taking it directly? I don't have anything else queued
> > up for this cycle.
>
> Done.
>
Thanks
nd nobody saves it into anything but a "bool" (which has magical
> casting properties and does not lose upper bits).
>
> Linus
Do you mind just taking it directly? I don't have anything else queued
up for this cycle.
Thanks,
--
Jeff Layton <jlay...@kernel.
From: Jeff Layton <jlay...@redhat.com>
As Linus points out:
The inode_cmp_iversion{+raw}() functions are pure and utter crap.
Why?
You say that they return 0/negative/positive, but they do so in a
completely broken manner. They return that ternary value as the
se
On Tue, 2018-01-30 at 17:50 +, Trond Myklebust wrote:
> On Tue, 2018-01-30 at 12:31 -0500, Jeff Layton wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > As Linus points out:
> >
> > The inode_cmp_iversion{+raw}() functions ar
On Mon, 2018-01-29 at 13:50 -0800, Linus Torvalds wrote:
> On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton <jlay...@redhat.com> wrote:
> >
> > This pile of patches is a rework of the inode->i_version field. We have
> > traditionally incremented that field on every ino
oblems.
Thanks!
----
Jeff Layton (21):
lustre: don't set f_version in ll_readdir
ntfs: remove i_version handling
fs: new API for handling inode->i_version
fs: don't take the i_lock in inode_inc_iversion
fat
On Thu, 2018-01-18 at 16:45 -0500, J. Bruce Fields wrote:
> On Tue, Jan 09, 2018 at 09:10:42AM -0500, Jeff Layton wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > The rationale for taking the i_lock when incrementing this value is
> > lost in antiquit
On Thu, 2018-01-18 at 16:38 -0500, J. Bruce Fields wrote:
> On Tue, Jan 09, 2018 at 09:10:41AM -0500, Jeff Layton wrote:
> > --- /dev/null
> > +++ b/include/linux/iversion.h
> > @@ -0,0 +1,236 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifnd
On Thu, 2018-01-11 at 12:23 -0800, Liu Bo wrote:
> On Tue, Jan 09, 2018 at 09:10:40AM -0500, Jeff Layton wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > v5:
> > - don't corrupt refcounts stashed in i_version of ext4 xattr inodes
> > - add raw vari
From: Jeff Layton <jlay...@redhat.com>
v5:
- don't corrupt refcounts stashed in i_version of ext4 xattr inodes
- add raw variants of inc and cmp functions, and have nfs use them
v4:
- fix SB_LAZYTIME handling in generic_update_time
- add memory barriers to patch to convert i_version
From: Jeff Layton <jlay...@redhat.com>
Add a documentation blob that explains what the i_version field is, how
it is expected to work, and how it is currently implemented by various
filesystems.
We already have inode_inc_iversion. Add several other functions for
manipulating and acc
From: Jeff Layton <jlay...@redhat.com>
The rationale for taking the i_lock when incrementing this value is
lost in antiquity. The readers of the field don't take it (at least
not universally), so my assumption is that it was only done here to
serialize incrementors.
If that is indeed th
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/fat/dir.c | 3 ++-
fs/fat/inode.c | 9 +
fs/fat/namei_msdos.c | 7 ---
fs/fat/namei_vfat.c | 22 +++---
4 files changed, 22 insertions(+),
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/affs/amigaffs.c | 5 +++--
fs/affs/dir.c | 5 +++--
fs/affs/super.c| 3 ++-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amig
From: Jeff Layton <jlay...@redhat.com>
For AFS, it's generally treated as an opaque value, so we use the
*_raw variants of the API here.
Note that AFS has quite a different definition for this counter. AFS
only increments it on changes to the data to the data in regular files
and co
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: David Sterba <dste...@suse.com>
---
fs/btrfs/delayed-inode.c | 7 +--
fs/btrfs/inode.c | 6 --
fs/btrfs/tree-log.c | 4 +++-
3 files changed, 12 insertio
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Jan Kara <j...@suse.cz>
---
fs/ext2/dir.c | 9 +
fs/ext2/super.c | 5 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/f
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/exofs/dir.c | 9 +
fs/exofs/super.c | 3 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
index 98233a97b7b8..c5a53fcc43ea 100
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: Theodore Ts'o <ty...@mit.edu>
---
fs/ext4/dir.c| 9 +
fs/ext4/inline.c | 7 ---
fs/ext4/inode.c | 12
fs/ext4/ioctl.c | 3 ++-
fs/ext4/namei.c
From: Jeff Layton <jlay...@redhat.com>
For NFS, we just use the "raw" API since the i_version is mostly
managed by the server. The exception there is when the client
holds a write delegation, but we only need to bump it once
there anyway to handle CB_GETATTR.
Tested-by: Krzysz
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ufs/dir.c | 9 +
fs/ufs/inode.c | 3 ++-
fs/ufs/super.c | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
index 2edc1755b7c5..
From: Jeff Layton <jlay...@redhat.com>
Mostly just making sure we use the "get" wrappers so we know when
it is being fetched for later use.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/nfsd/nfsfh.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Jan Kara <j...@suse.cz>
---
fs/ocfs2/dir.c | 15 ---
fs/ocfs2/inode.c| 3 ++-
fs/ocfs2/namei.c| 3 ++-
fs/ocfs2/quota_global.c | 3 ++-
4
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
security/integrity/ima/ima_api.c | 3 ++-
security/integrity/ima/ima_main.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/securi
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: Darrick J. Wong <darrick.w...@oracle.com>
---
fs/xfs/libxfs/xfs_inode_buf.c | 7 +--
fs/xfs/xfs_icache.c | 5 +++--
fs/xfs/xfs_inode.c| 3 ++-
fs/xf
From: Jeff Layton <jlay...@redhat.com>
If XFS_ILOG_CORE is already set then go ahead and increment it.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: Darrick J. Wong <darrick.w...@oracle.com>
---
fs/xfs/xfs_trans_inode.c | 14 --
1 file changed,
From: Jeff Layton <jlay...@redhat.com>
At this point, we know that "now" and the file times may differ, and we
suspect that the i_version has been flagged to be bumped. Attempt to
bump the i_version, and only mark the inode dirty if that actually
occurred or if one of the t
From: Jeff Layton <jlay...@redhat.com>
We only really need to update i_version if someone has queried for it
since we last incremented it. By doing that, we can avoid having to
update the inode if the times haven't changed.
If the times have changed, then we go ahead and forcibly inc
From: Jeff Layton <jlay...@redhat.com>
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 wa
On Mon, 2018-01-08 at 21:17 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 08, 2018 at 02:15:29PM -0500, Jeff Layton wrote:
> > On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote:
> > > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote:
> > > &g
On Mon, 2018-01-08 at 14:15 -0500, Jeff Layton wrote:
> On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote:
> > On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote:
> > > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote:
> >
> > (
On Mon, 2018-01-08 at 19:33 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 08, 2018 at 01:00:19PM -0500, Jeff Layton wrote:
> > On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote:
>
> (...)
>
> > > > Ok, thanks. If you're seeing hangs then that might i
On Mon, 2018-01-08 at 18:29 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 08, 2018 at 08:29:24AM -0500, Jeff Layton wrote:
> > On Mon, 2018-01-08 at 14:21 +0100, Krzysztof Kozlowski wrote:
> > > On Mon, Jan 8, 2018 at 1:56 PM, Jeff Layton <jlay...@kernel.org> wrote:
&g
On Mon, 2018-01-08 at 05:30 -0800, Matthew Wilcox wrote:
> 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 */
> > +
On Mon, 2018-01-08 at 14:21 +0100, Krzysztof Kozlowski wrote:
> On Mon, Jan 8, 2018 at 1:56 PM, Jeff Layton <jlay...@kernel.org> wrote:
> > On Sun, 2018-01-07 at 13:44 +0100, Krzysztof Kozlowski wrote:
> > > On Fri, Dec 22, 2017 at 1:05 PM, Jeff Layton <jlay...@kern
On Sun, 2018-01-07 at 13:44 +0100, Krzysztof Kozlowski wrote:
> On Fri, Dec 22, 2017 at 1:05 PM, Jeff Layton <jlay...@kernel.org> wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > Since i_version is mostly treated as an opaque value, we can exploit th
On Fri, 2017-12-22 at 07:05 -0500, Jeff Layton wrote:
> From: Jeff Layton <jlay...@redhat.com>
>
> Signed-off-by: Jeff Layton <jlay...@redhat.com>
> Reviewed-by: Jan Kara <j...@suse.cz>
> ---
> fs/ocfs2/dir.c | 15 ---
> fs/ocfs2/inod
On Fri, 2017-12-22 at 07:05 -0500, Jeff Layton wrote:
> From: Jeff Layton <jlay...@redhat.com>
>
> At this point, we know that "now" and the file times may differ, and we
> suspect that the i_version has been flagged to be bumped. Attempt to
> bump the i_version
On Tue, 2018-01-02 at 17:50 +0100, Jan Kara wrote:
> On Fri 22-12-17 07:05:53, Jeff Layton wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > We only really need to update i_version if someone has queried for it
> > since we last incremented it. B
On Tue, 2018-01-02 at 17:20 +, David Howells wrote:
> Jeff Layton <jlay...@kernel.org> wrote:
>
> > Note that AFS has quite a different definition for this counter. AFS
> > only increments it on changes to the data, not for the metadata.
>
> This also appl
On Sat, 2017-12-23 at 10:14 +1100, NeilBrown wrote:
> On Fri, Dec 22 2017, Jeff Layton wrote:
>
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > Add a documentation blob that explains what the i_version field is, how
> > it is expected to work, and how it
From: Jeff Layton <jlay...@redhat.com>
v4:
- fix SB_LAZYTIME handling in generic_update_time
- add memory barriers to patch to convert i_version field to atomic64_t
v3:
- move i_version handling functions to new header file
- document that the kernel-managed i_version implementation will
From: Jeff Layton <jlay...@redhat.com>
Add a documentation blob that explains what the i_version field is, how
it is expected to work, and how it is currently implemented by various
filesystems.
We already have inode_inc_iversion. Add several other functions for
manipulating and acc
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/fat/dir.c | 3 ++-
fs/fat/inode.c | 9 +
fs/fat/namei_msdos.c | 7 ---
fs/fat/namei_vfat.c | 22 +++---
4 files changed, 22 insertions(+),
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/btrfs/delayed-inode.c | 7 +--
fs/btrfs/inode.c | 6 --
fs/btrfs/tree-log.c | 4 +++-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/delayed-
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/exofs/dir.c | 9 +
fs/exofs/super.c | 3 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
index 98233a97b7b8..c5a53fcc43ea 100
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Jan Kara <j...@suse.cz>
---
fs/ext2/dir.c | 9 +
fs/ext2/super.c | 5 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/f
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: Theodore Ts'o <ty...@mit.edu>
---
fs/ext4/dir.c| 9 +
fs/ext4/inline.c | 7 ---
fs/ext4/inode.c | 12
fs/ext4/ioctl.c | 3 ++-
fs/ext4/namei.c
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/affs/amigaffs.c | 5 +++--
fs/affs/dir.c | 5 +++--
fs/affs/super.c| 3 ++-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amig
From: Jeff Layton <jlay...@redhat.com>
For NFS, we just use the "raw" API since the i_version is mostly
managed by the server. The exception there is when the client
holds a write delegation, but we only need to bump it once
there anyway to handle CB_GETATTR.
Signed-off-by: J
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ufs/dir.c | 9 +
fs/ufs/inode.c | 3 ++-
fs/ufs/super.c | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
index 2edc1755b7c5..
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/xfs/libxfs/xfs_inode_buf.c | 7 +--
fs/xfs/xfs_icache.c | 5 +++--
fs/xfs/xfs_inode.c| 3 ++-
fs/xfs/xfs_inode_item.c | 3 ++-
fs/xfs/xfs_trans_inode.c
From: Jeff Layton <jlay...@redhat.com>
Mostly just making sure we use the "get" wrappers so we know when
it is being fetched for later use.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/nfsd/nfsfh.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
security/integrity/ima/ima_api.c | 3 ++-
security/integrity/ima/ima_main.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/securi
From: Jeff Layton <jlay...@redhat.com>
We only really need to update i_version if someone has queried for it
since we last incremented it. By doing that, we can avoid having to
update the inode if the times haven't changed.
If the times have changed, then we go ahead and forcibly inc
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Jan Kara <j...@suse.cz>
---
fs/ocfs2/dir.c | 15 ---
fs/ocfs2/inode.c| 3 ++-
fs/ocfs2/namei.c| 3 ++-
fs/ocfs2/quota_global.c | 3 ++-
4
From: Jeff Layton <jlay...@redhat.com>
At this point, we know that "now" and the file times may differ, and we
suspect that the i_version has been flagged to be bumped. Attempt to
bump the i_version, and only mark the inode dirty if that actually
occurred or if one of the t
From: Jeff Layton <jlay...@redhat.com>
If XFS_ILOG_CORE is already set then go ahead and increment it.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/xfs/xfs_trans_inode.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_trans_
From: Jeff Layton <jlay...@redhat.com>
The rationale for taking the i_lock when incrementing this value is
lost in antiquity. The readers of the field don't take it (at least
not universally), so my assumption is that it was only done here to
serialize incrementors.
If that is indeed th
On Wed, 2017-12-20 at 17:41 +0100, Jan Kara wrote:
> On Wed 20-12-17 09:03:06, Jeff Layton wrote:
> > On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote:
> > > On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote:
> > > > [PATCH] SQUASH: add memory barr
On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote:
> On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote:
> > [PATCH] SQUASH: add memory barriers around i_version accesses
>
> Why explicit memory barriers rather than annotating the operations
> with the required sem
On Tue, 2017-12-19 at 10:29 +0100, Jan Kara wrote:
> On Mon 18-12-17 12:22:20, Jeff Layton wrote:
> > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote:
> > > On Mon 18-12-17 10:11:56, Jeff Layton wrote:
> > > > static inline bool
> > > > inode_maybe_in
On Mon, 2017-12-18 at 12:36 -0500, J. Bruce Fields wrote:
> On Mon, Dec 18, 2017 at 12:22:20PM -0500, Jeff Layton wrote:
> > On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote:
> > > On Mon 18-12-17 10:11:56, Jeff Layton wrote:
> > > > static inline bool
> >
On Mon, 2017-12-18 at 10:11 -0500, Jeff Layton wrote:
> From: Jeff Layton <jlay...@redhat.com>
>
> Add a documentation blob that explains what the i_version field is, how
> it is expected to work, and how it is currently implemented by various
> filesystems.
On Mon, 2017-12-18 at 17:34 +0100, Jan Kara wrote:
> On Mon 18-12-17 10:11:56, Jeff Layton wrote:
> > static inline bool
> > inode_maybe_inc_iversion(struct inode *inode, bool force)
> > {
> > - atomic64_t *ivp = (atomic64_t *)>i_version;
> > + u64 cur,
From: Jeff Layton <jlay...@redhat.com>
Add a documentation blob that explains what the i_version field is, how
it is expected to work, and how it is currently implemented by various
filesystems.
We already have inode_inc_iversion. Add several other functions for
manipulating and acc
From: Jeff Layton <jlay...@redhat.com>
v3:
- move i_version handling functions to new header file
- document that the kernel-managed i_version implementation will appear to
increase over time
- fix inode_cmp_iversion to handle wraparound correctly
v2:
- xfs should use inode_peek_iv
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/affs/amigaffs.c | 5 +++--
fs/affs/dir.c | 5 +++--
fs/affs/super.c| 3 ++-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amig
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/fat/dir.c | 3 ++-
fs/fat/inode.c | 9 +
fs/fat/namei_msdos.c | 7 ---
fs/fat/namei_vfat.c | 22 +++---
4 files changed, 22 insertions(+),
From: Jeff Layton <jlay...@redhat.com>
The rationale for taking the i_lock when incrementing this value is
lost in antiquity. The readers of the field don't take it (at least
not universally), so my assumption is that it was only done here to
serialize incrementors.
If that is indeed th
From: Jeff Layton <jlay...@redhat.com>
For AFS, it's generally treated as an opaque value, so we use the
*_raw variants of the API here.
Note that AFS has quite a different definition for this counter. AFS
only increments it on changes to the data, not for the metadata. We'll
need to rec
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/exofs/dir.c | 9 +
fs/exofs/super.c | 3 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
index 98233a97b7b8..c5a53fcc43ea 100
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/btrfs/delayed-inode.c | 7 +--
fs/btrfs/file.c | 1 +
fs/btrfs/inode.c | 7 +--
fs/btrfs/ioctl.c | 1 +
fs/btrfs/tree-log.c | 4 +++-
fs/btrfs/xattr.c
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Jan Kara <j...@suse.cz>
---
fs/ext2/dir.c | 9 +
fs/ext2/super.c | 5 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/ext2/dir.c b/f
From: Jeff Layton <jlay...@redhat.com>
For NFS, we just use the "raw" API since the i_version is mostly
managed by the server. The exception there is when the client
holds a write delegation, but we only need to bump it once
there anyway to handle CB_GETATTR.
Signed-off-by: J
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/xfs/libxfs/xfs_inode_buf.c | 7 +--
fs/xfs/xfs_icache.c | 5 +++--
fs/xfs/xfs_inode.c| 3 ++-
fs/xfs/xfs_inode_item.c | 3 ++-
fs/xfs/xfs_trans_inode.c
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: Theodore Ts'o <ty...@mit.edu>
---
fs/ext4/dir.c| 9 +
fs/ext4/inline.c | 7 ---
fs/ext4/inode.c | 13 +
fs/ext4/ioctl.c | 3 ++-
fs/ext4/namei.c |
From: Jeff Layton <jlay...@redhat.com>
Mostly just making sure we use the "get" wrappers so we know when
it is being fetched for later use.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/nfsd/nfsfh.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ufs/dir.c | 9 +
fs/ufs/inode.c | 3 ++-
fs/ufs/super.c | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
index 2edc1755b7c5..
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
security/integrity/ima/ima_api.c | 3 ++-
security/integrity/ima/ima_main.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_api.c b/securi
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Reviewed-by: Jan Kara <j...@suse.cz>
---
fs/ocfs2/dir.c | 15 ---
fs/ocfs2/inode.c| 3 ++-
fs/ocfs2/namei.c| 3 ++-
fs/ocfs2/quota_global.c | 3 ++-
4
From: Jeff Layton <jlay...@redhat.com>
If XFS_ILOG_CORE is already set then go ahead and increment it.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/xfs/xfs_trans_inode.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_trans_
From: Jeff Layton <jlay...@redhat.com>
We only really need to update i_version if someone has queried for it
since we last incremented it. By doing that, we can avoid having to
update the inode if the times haven't changed.
If the times have changed, then we go ahead and forcibly inc
From: Jeff Layton <jlay...@redhat.com>
At this point, we know that "now" and the file times may differ, and we
suspect that the i_version has been flagged to be bumped. Attempt to
bump the i_version, and only mark the inode dirty if that actually
occurred or if one of the t
From: Jeff Layton <jlay...@redhat.com>
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 wa
On Sun, 2017-12-17 at 09:37 +1100, Dave Chinner wrote:
> On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > Add a documentation blob that explains what the i_version field is, how
> > it is expected
On Sat, 2017-12-16 at 11:18 -0500, Jeffrey Altman wrote:
> Hi Jeff,
>
> A few thoughts on AFS usage below which might impact a future revision
> of the API. I hope they are useful.
>
> On 12/16/2017 8:49 AM, Jeff Layton wrote:
> > On Sat, 2017-12-16 at 08:46 -0500, Jeff
From: Jeff Layton <jlay...@redhat.com>
Add a documentation blob that explains what the i_version field is, how
it is expected to work, and how it is currently implemented by various
filesystems.
We already have inode_inc_iversion. Add several other functions for
manipulating and acc
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/fat/dir.c | 2 +-
fs/fat/inode.c | 8
fs/fat/namei_msdos.c | 6 +++---
fs/fat/namei_vfat.c | 20 ++--
4 files changed, 18 insertions(+), 18 deleti
From: Jeff Layton <jlay...@redhat.com>
The rationale for taking the i_lock when incrementing this value is
lost in antiquity. The readers of the field don't take it (at least
not universally), so my assumption is that it was only done here to
serialize incrementors.
If that is indeed th
From: Jeff Layton <jlay...@redhat.com>
For AFS, it's generally treated as an opaque value, so we use the
*_raw variants of the API here.
Note that AFS has quite a different definition for this counter. AFS
only increments it on changes to the data, not for the metadata. We'll
need to rec
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/affs/amigaffs.c | 4 ++--
fs/affs/dir.c | 4 ++--
fs/affs/super.c| 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/affs/amigaffs.c b/fs/affs/amig
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/exofs/dir.c | 8
fs/exofs/super.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
index 98233a97b7b8..36e314083b80 100644
--
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/btrfs/delayed-inode.c | 6 --
fs/btrfs/inode.c | 6 --
fs/btrfs/tree-log.c | 3 ++-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/delayed-
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Acked-by: Theodore Ts'o <ty...@mit.edu>
---
fs/ext4/dir.c| 8
fs/ext4/inline.c | 6 +++---
fs/ext4/inode.c | 12
fs/ext4/ioctl.c | 2 +-
fs/ext4/namei.c
From: Jeff Layton <jlay...@redhat.com>
For NFS, we just use the "raw" API since the i_version is mostly
managed by the server. The exception there is when the client
holds a write delegation, but we only need to bump it once
there anyway to handle CB_GETATTR.
Signed-off-by: J
From: Jeff Layton <jlay...@redhat.com>
Mostly just making sure we use the "get" wrappers so we know when
it is being fetched for later use.
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/nfsd/nfsfh.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
On Sat, 2017-12-16 at 08:46 -0500, Jeff Layton wrote:
> From: Jeff Layton <jlay...@redhat.com>
>
> For AFS, it's generally treated as an opaque value, so we use the
> *_raw variants of the API here.
>
> Note that AFS has quite a different definition for this counte
From: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
fs/ufs/dir.c | 8
fs/ufs/inode.c | 2 +-
fs/ufs/super.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
index 2edc1755b7c5..547c4d4
1 - 100 of 320 matches
Mail list logo
