Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0
@ 2020-10-31  0:44 Eric Biggers
  2020-11-06 17:52 ` Eric Biggers
  2020-11-10 15:55 ` Jeff Layton
  0 siblings, 2 replies; 7+ messages in thread
From: Eric Biggers @ 2020-10-31  0:44 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: linux-fscrypt, linux-ext4

From: Eric Biggers <ebiggers@google.com>

Currently inode_init_always() doesn't initialize i_ino to 0.  This is
unexpected because unlike the other inode fields that aren't initialized
by inode_init_always(), i_ino isn't guaranteed to end up back at its
initial value after the inode is freed.  Only one filesystem (XFS)
actually sets set i_ino back to 0 when freeing its inodes.

So, callers of new_inode() see some random previous i_ino.  Normally
that's fine, since normally i_ino isn't accessed before being set.
There can be edge cases where that isn't necessarily true, though.

The one I've run into is that on ext4, when creating an encrypted file,
the new file's encryption key has to be set up prior to the jbd2
transaction, and thus prior to i_ino being set.  If something goes
wrong, fs/crypto/ may log warning or error messages, which normally
include i_ino.  So it needs to know whether it is valid to include i_ino
yet or not.  Also, on some files i_ino needs to be hashed for use in the
crypto, so fs/crypto/ needs to know whether that can be done yet or not.

There are ways this could be worked around, either in fs/crypto/ or in
fs/ext4/.  But, it seems there's no reason not to just fix
inode_init_always() to do the expected thing and initialize i_ino to 0.

So, do that, and also remove the initialization in jfs_fill_super() that
becomes redundant.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 fs/inode.c     | 1 +
 fs/jfs/super.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/inode.c b/fs/inode.c
index 9d78c37b00b81..eb001129f157c 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -142,6 +142,7 @@ int inode_init_always(struct super_block *sb, struct inode *inode)
 	atomic_set(&inode->i_count, 1);
 	inode->i_op = &empty_iops;
 	inode->i_fop = &no_open_fops;
+	inode->i_ino = 0;
 	inode->__i_nlink = 1;
 	inode->i_opflags = 0;
 	if (sb->s_xattr)
diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index b2dc4d1f9dcc5..1f0ffabbde566 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
@@ -551,7 +551,6 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent)
 		ret = -ENOMEM;
 		goto out_unload;
 	}
-	inode->i_ino = 0;
 	inode->i_size = i_size_read(sb->s_bdev->bd_inode);
 	inode->i_mapping->a_ops = &jfs_metapage_aops;
 	inode_fake_hash(inode);

base-commit: 5fc6b075e165f641fbc366b58b578055762d5f8c
-- 
2.29.1


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0
  2020-10-31  0:44 [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0 Eric Biggers
@ 2020-11-06 17:52 ` Eric Biggers
  2020-11-20 18:50   ` Eric Biggers
  2020-11-10 15:55 ` Jeff Layton
  1 sibling, 1 reply; 7+ messages in thread
From: Eric Biggers @ 2020-11-06 17:52 UTC (permalink / raw)
  To: Alexander Viro, linux-fsdevel; +Cc: linux-fscrypt, linux-ext4

On Fri, Oct 30, 2020 at 05:44:20PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Currently inode_init_always() doesn't initialize i_ino to 0.  This is
> unexpected because unlike the other inode fields that aren't initialized
> by inode_init_always(), i_ino isn't guaranteed to end up back at its
> initial value after the inode is freed.  Only one filesystem (XFS)
> actually sets set i_ino back to 0 when freeing its inodes.
> 
> So, callers of new_inode() see some random previous i_ino.  Normally
> that's fine, since normally i_ino isn't accessed before being set.
> There can be edge cases where that isn't necessarily true, though.
> 
> The one I've run into is that on ext4, when creating an encrypted file,
> the new file's encryption key has to be set up prior to the jbd2
> transaction, and thus prior to i_ino being set.  If something goes
> wrong, fs/crypto/ may log warning or error messages, which normally
> include i_ino.  So it needs to know whether it is valid to include i_ino
> yet or not.  Also, on some files i_ino needs to be hashed for use in the
> crypto, so fs/crypto/ needs to know whether that can be done yet or not.
> 
> There are ways this could be worked around, either in fs/crypto/ or in
> fs/ext4/.  But, it seems there's no reason not to just fix
> inode_init_always() to do the expected thing and initialize i_ino to 0.
> 
> So, do that, and also remove the initialization in jfs_fill_super() that
> becomes redundant.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  fs/inode.c     | 1 +
>  fs/jfs/super.c | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 9d78c37b00b81..eb001129f157c 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -142,6 +142,7 @@ int inode_init_always(struct super_block *sb, struct inode *inode)
>  	atomic_set(&inode->i_count, 1);
>  	inode->i_op = &empty_iops;
>  	inode->i_fop = &no_open_fops;
> +	inode->i_ino = 0;
>  	inode->__i_nlink = 1;
>  	inode->i_opflags = 0;
>  	if (sb->s_xattr)
> diff --git a/fs/jfs/super.c b/fs/jfs/super.c
> index b2dc4d1f9dcc5..1f0ffabbde566 100644
> --- a/fs/jfs/super.c
> +++ b/fs/jfs/super.c
> @@ -551,7 +551,6 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent)
>  		ret = -ENOMEM;
>  		goto out_unload;
>  	}
> -	inode->i_ino = 0;
>  	inode->i_size = i_size_read(sb->s_bdev->bd_inode);
>  	inode->i_mapping->a_ops = &jfs_metapage_aops;
>  	inode_fake_hash(inode);
> 

Al, any thoughts on this?

- Eric

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0
  2020-10-31  0:44 [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0 Eric Biggers
  2020-11-06 17:52 ` Eric Biggers
@ 2020-11-10 15:55 ` Jeff Layton
  1 sibling, 0 replies; 7+ messages in thread
From: Jeff Layton @ 2020-11-10 15:55 UTC (permalink / raw)
  To: Eric Biggers, linux-fsdevel; +Cc: linux-fscrypt, linux-ext4

On Fri, 2020-10-30 at 17:44 -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Currently inode_init_always() doesn't initialize i_ino to 0.  This is
> unexpected because unlike the other inode fields that aren't initialized
> by inode_init_always(), i_ino isn't guaranteed to end up back at its
> initial value after the inode is freed.  Only one filesystem (XFS)
> actually sets set i_ino back to 0 when freeing its inodes.
> 
> So, callers of new_inode() see some random previous i_ino.  Normally
> that's fine, since normally i_ino isn't accessed before being set.
> There can be edge cases where that isn't necessarily true, though.
> 
> The one I've run into is that on ext4, when creating an encrypted file,
> the new file's encryption key has to be set up prior to the jbd2
> transaction, and thus prior to i_ino being set.  If something goes
> wrong, fs/crypto/ may log warning or error messages, which normally
> include i_ino.  So it needs to know whether it is valid to include i_ino
> yet or not.  Also, on some files i_ino needs to be hashed for use in the
> crypto, so fs/crypto/ needs to know whether that can be done yet or not.
> 
> There are ways this could be worked around, either in fs/crypto/ or in
> fs/ext4/.  But, it seems there's no reason not to just fix
> inode_init_always() to do the expected thing and initialize i_ino to 0.
> 
> So, do that, and also remove the initialization in jfs_fill_super() that
> becomes redundant.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  fs/inode.c     | 1 +
>  fs/jfs/super.c | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 9d78c37b00b81..eb001129f157c 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -142,6 +142,7 @@ int inode_init_always(struct super_block *sb, struct inode *inode)
>  	atomic_set(&inode->i_count, 1);
>  	inode->i_op = &empty_iops;
>  	inode->i_fop = &no_open_fops;
> +	inode->i_ino = 0;
>  	inode->__i_nlink = 1;
>  	inode->i_opflags = 0;
>  	if (sb->s_xattr)
> diff --git a/fs/jfs/super.c b/fs/jfs/super.c
> index b2dc4d1f9dcc5..1f0ffabbde566 100644
> --- a/fs/jfs/super.c
> +++ b/fs/jfs/super.c
> @@ -551,7 +551,6 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent)
>  		ret = -ENOMEM;
>  		goto out_unload;
>  	}
> -	inode->i_ino = 0;
>  	inode->i_size = i_size_read(sb->s_bdev->bd_inode);
>  	inode->i_mapping->a_ops = &jfs_metapage_aops;
>  	inode_fake_hash(inode);
> 
> base-commit: 5fc6b075e165f641fbc366b58b578055762d5f8c

This seems like a reasonable thing to do.

Acked-by: Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0
  2020-11-06 17:52 ` Eric Biggers
@ 2020-11-20 18:50   ` Eric Biggers
  2020-12-02 21:19     ` Eric Biggers
  0 siblings, 1 reply; 7+ messages in thread
From: Eric Biggers @ 2020-11-20 18:50 UTC (permalink / raw)
  To: Alexander Viro, linux-fsdevel; +Cc: linux-fscrypt, linux-ext4

On Fri, Nov 06, 2020 at 09:52:05AM -0800, Eric Biggers wrote:
> On Fri, Oct 30, 2020 at 05:44:20PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Currently inode_init_always() doesn't initialize i_ino to 0.  This is
> > unexpected because unlike the other inode fields that aren't initialized
> > by inode_init_always(), i_ino isn't guaranteed to end up back at its
> > initial value after the inode is freed.  Only one filesystem (XFS)
> > actually sets set i_ino back to 0 when freeing its inodes.
> > 
> > So, callers of new_inode() see some random previous i_ino.  Normally
> > that's fine, since normally i_ino isn't accessed before being set.
> > There can be edge cases where that isn't necessarily true, though.
> > 
> > The one I've run into is that on ext4, when creating an encrypted file,
> > the new file's encryption key has to be set up prior to the jbd2
> > transaction, and thus prior to i_ino being set.  If something goes
> > wrong, fs/crypto/ may log warning or error messages, which normally
> > include i_ino.  So it needs to know whether it is valid to include i_ino
> > yet or not.  Also, on some files i_ino needs to be hashed for use in the
> > crypto, so fs/crypto/ needs to know whether that can be done yet or not.
> > 
> > There are ways this could be worked around, either in fs/crypto/ or in
> > fs/ext4/.  But, it seems there's no reason not to just fix
> > inode_init_always() to do the expected thing and initialize i_ino to 0.
> > 
> > So, do that, and also remove the initialization in jfs_fill_super() that
> > becomes redundant.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > ---
> >  fs/inode.c     | 1 +
> >  fs/jfs/super.c | 1 -
> >  2 files changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/inode.c b/fs/inode.c
> > index 9d78c37b00b81..eb001129f157c 100644
> > --- a/fs/inode.c
> > +++ b/fs/inode.c
> > @@ -142,6 +142,7 @@ int inode_init_always(struct super_block *sb, struct inode *inode)
> >  	atomic_set(&inode->i_count, 1);
> >  	inode->i_op = &empty_iops;
> >  	inode->i_fop = &no_open_fops;
> > +	inode->i_ino = 0;
> >  	inode->__i_nlink = 1;
> >  	inode->i_opflags = 0;
> >  	if (sb->s_xattr)
> > diff --git a/fs/jfs/super.c b/fs/jfs/super.c
> > index b2dc4d1f9dcc5..1f0ffabbde566 100644
> > --- a/fs/jfs/super.c
> > +++ b/fs/jfs/super.c
> > @@ -551,7 +551,6 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent)
> >  		ret = -ENOMEM;
> >  		goto out_unload;
> >  	}
> > -	inode->i_ino = 0;
> >  	inode->i_size = i_size_read(sb->s_bdev->bd_inode);
> >  	inode->i_mapping->a_ops = &jfs_metapage_aops;
> >  	inode_fake_hash(inode);
> > 
> 
> Al, any thoughts on this?
> 

Ping?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0
  2020-11-20 18:50   ` Eric Biggers
@ 2020-12-02 21:19     ` Eric Biggers
  2021-01-04 18:54       ` Eric Biggers
  0 siblings, 1 reply; 7+ messages in thread
From: Eric Biggers @ 2020-12-02 21:19 UTC (permalink / raw)
  To: Alexander Viro, linux-fsdevel; +Cc: linux-fscrypt, linux-ext4

On Fri, Nov 20, 2020 at 10:50:30AM -0800, Eric Biggers wrote:
> On Fri, Nov 06, 2020 at 09:52:05AM -0800, Eric Biggers wrote:
> > On Fri, Oct 30, 2020 at 05:44:20PM -0700, Eric Biggers wrote:
> > > From: Eric Biggers <ebiggers@google.com>
> > > 
> > > Currently inode_init_always() doesn't initialize i_ino to 0.  This is
> > > unexpected because unlike the other inode fields that aren't initialized
> > > by inode_init_always(), i_ino isn't guaranteed to end up back at its
> > > initial value after the inode is freed.  Only one filesystem (XFS)
> > > actually sets set i_ino back to 0 when freeing its inodes.
> > > 
> > > So, callers of new_inode() see some random previous i_ino.  Normally
> > > that's fine, since normally i_ino isn't accessed before being set.
> > > There can be edge cases where that isn't necessarily true, though.
> > > 
> > > The one I've run into is that on ext4, when creating an encrypted file,
> > > the new file's encryption key has to be set up prior to the jbd2
> > > transaction, and thus prior to i_ino being set.  If something goes
> > > wrong, fs/crypto/ may log warning or error messages, which normally
> > > include i_ino.  So it needs to know whether it is valid to include i_ino
> > > yet or not.  Also, on some files i_ino needs to be hashed for use in the
> > > crypto, so fs/crypto/ needs to know whether that can be done yet or not.
> > > 
> > > There are ways this could be worked around, either in fs/crypto/ or in
> > > fs/ext4/.  But, it seems there's no reason not to just fix
> > > inode_init_always() to do the expected thing and initialize i_ino to 0.
> > > 
> > > So, do that, and also remove the initialization in jfs_fill_super() that
> > > becomes redundant.
> > > 
> > > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > > ---
> > >  fs/inode.c     | 1 +
> > >  fs/jfs/super.c | 1 -
> > >  2 files changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/inode.c b/fs/inode.c
> > > index 9d78c37b00b81..eb001129f157c 100644
> > > --- a/fs/inode.c
> > > +++ b/fs/inode.c
> > > @@ -142,6 +142,7 @@ int inode_init_always(struct super_block *sb, struct inode *inode)
> > >  	atomic_set(&inode->i_count, 1);
> > >  	inode->i_op = &empty_iops;
> > >  	inode->i_fop = &no_open_fops;
> > > +	inode->i_ino = 0;
> > >  	inode->__i_nlink = 1;
> > >  	inode->i_opflags = 0;
> > >  	if (sb->s_xattr)
> > > diff --git a/fs/jfs/super.c b/fs/jfs/super.c
> > > index b2dc4d1f9dcc5..1f0ffabbde566 100644
> > > --- a/fs/jfs/super.c
> > > +++ b/fs/jfs/super.c
> > > @@ -551,7 +551,6 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent)
> > >  		ret = -ENOMEM;
> > >  		goto out_unload;
> > >  	}
> > > -	inode->i_ino = 0;
> > >  	inode->i_size = i_size_read(sb->s_bdev->bd_inode);
> > >  	inode->i_mapping->a_ops = &jfs_metapage_aops;
> > >  	inode_fake_hash(inode);
> > > 
> > 
> > Al, any thoughts on this?

Ping.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0
  2020-12-02 21:19     ` Eric Biggers
@ 2021-01-04 18:54       ` Eric Biggers
  2021-01-04 19:10         ` Al Viro
  0 siblings, 1 reply; 7+ messages in thread
From: Eric Biggers @ 2021-01-04 18:54 UTC (permalink / raw)
  To: Alexander Viro, linux-fsdevel; +Cc: linux-fscrypt, linux-ext4

On Wed, Dec 02, 2020 at 01:19:15PM -0800, Eric Biggers wrote:
> On Fri, Nov 20, 2020 at 10:50:30AM -0800, Eric Biggers wrote:
> > On Fri, Nov 06, 2020 at 09:52:05AM -0800, Eric Biggers wrote:
> > > On Fri, Oct 30, 2020 at 05:44:20PM -0700, Eric Biggers wrote:
> > > > From: Eric Biggers <ebiggers@google.com>
> > > > 
> > > > Currently inode_init_always() doesn't initialize i_ino to 0.  This is
> > > > unexpected because unlike the other inode fields that aren't initialized
> > > > by inode_init_always(), i_ino isn't guaranteed to end up back at its
> > > > initial value after the inode is freed.  Only one filesystem (XFS)
> > > > actually sets set i_ino back to 0 when freeing its inodes.
> > > > 
> > > > So, callers of new_inode() see some random previous i_ino.  Normally
> > > > that's fine, since normally i_ino isn't accessed before being set.
> > > > There can be edge cases where that isn't necessarily true, though.
> > > > 
> > > > The one I've run into is that on ext4, when creating an encrypted file,
> > > > the new file's encryption key has to be set up prior to the jbd2
> > > > transaction, and thus prior to i_ino being set.  If something goes
> > > > wrong, fs/crypto/ may log warning or error messages, which normally
> > > > include i_ino.  So it needs to know whether it is valid to include i_ino
> > > > yet or not.  Also, on some files i_ino needs to be hashed for use in the
> > > > crypto, so fs/crypto/ needs to know whether that can be done yet or not.
> > > > 
> > > > There are ways this could be worked around, either in fs/crypto/ or in
> > > > fs/ext4/.  But, it seems there's no reason not to just fix
> > > > inode_init_always() to do the expected thing and initialize i_ino to 0.
> > > > 
> > > > So, do that, and also remove the initialization in jfs_fill_super() that
> > > > becomes redundant.
> > > > 
> > > > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > > > ---
> > > >  fs/inode.c     | 1 +
> > > >  fs/jfs/super.c | 1 -
> > > >  2 files changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/fs/inode.c b/fs/inode.c
> > > > index 9d78c37b00b81..eb001129f157c 100644
> > > > --- a/fs/inode.c
> > > > +++ b/fs/inode.c
> > > > @@ -142,6 +142,7 @@ int inode_init_always(struct super_block *sb, struct inode *inode)
> > > >  	atomic_set(&inode->i_count, 1);
> > > >  	inode->i_op = &empty_iops;
> > > >  	inode->i_fop = &no_open_fops;
> > > > +	inode->i_ino = 0;
> > > >  	inode->__i_nlink = 1;
> > > >  	inode->i_opflags = 0;
> > > >  	if (sb->s_xattr)
> > > > diff --git a/fs/jfs/super.c b/fs/jfs/super.c
> > > > index b2dc4d1f9dcc5..1f0ffabbde566 100644
> > > > --- a/fs/jfs/super.c
> > > > +++ b/fs/jfs/super.c
> > > > @@ -551,7 +551,6 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent)
> > > >  		ret = -ENOMEM;
> > > >  		goto out_unload;
> > > >  	}
> > > > -	inode->i_ino = 0;
> > > >  	inode->i_size = i_size_read(sb->s_bdev->bd_inode);
> > > >  	inode->i_mapping->a_ops = &jfs_metapage_aops;
> > > >  	inode_fake_hash(inode);
> > > > 
> > > 
> > > Al, any thoughts on this?
> 
> Ping.

Ping.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0
  2021-01-04 18:54       ` Eric Biggers
@ 2021-01-04 19:10         ` Al Viro
  0 siblings, 0 replies; 7+ messages in thread
From: Al Viro @ 2021-01-04 19:10 UTC (permalink / raw)
  To: Eric Biggers; +Cc: linux-fsdevel, linux-fscrypt, linux-ext4

On Mon, Jan 04, 2021 at 10:54:02AM -0800, Eric Biggers wrote:
> On Wed, Dec 02, 2020 at 01:19:15PM -0800, Eric Biggers wrote:
> > On Fri, Nov 20, 2020 at 10:50:30AM -0800, Eric Biggers wrote:
> > > On Fri, Nov 06, 2020 at 09:52:05AM -0800, Eric Biggers wrote:
> > > > On Fri, Oct 30, 2020 at 05:44:20PM -0700, Eric Biggers wrote:
> > > > > From: Eric Biggers <ebiggers@google.com>
> > > > > 
> > > > > Currently inode_init_always() doesn't initialize i_ino to 0.  This is
> > > > > unexpected because unlike the other inode fields that aren't initialized
> > > > > by inode_init_always(), i_ino isn't guaranteed to end up back at its
> > > > > initial value after the inode is freed.  Only one filesystem (XFS)
> > > > > actually sets set i_ino back to 0 when freeing its inodes.
> > > > > 
> > > > > So, callers of new_inode() see some random previous i_ino.  Normally
> > > > > that's fine, since normally i_ino isn't accessed before being set.
> > > > > There can be edge cases where that isn't necessarily true, though.
> > > > > 
> > > > > The one I've run into is that on ext4, when creating an encrypted file,
> > > > > the new file's encryption key has to be set up prior to the jbd2
> > > > > transaction, and thus prior to i_ino being set.  If something goes
> > > > > wrong, fs/crypto/ may log warning or error messages, which normally
> > > > > include i_ino.  So it needs to know whether it is valid to include i_ino
> > > > > yet or not.  Also, on some files i_ino needs to be hashed for use in the
> > > > > crypto, so fs/crypto/ needs to know whether that can be done yet or not.
> > > > > 
> > > > > There are ways this could be worked around, either in fs/crypto/ or in
> > > > > fs/ext4/.  But, it seems there's no reason not to just fix
> > > > > inode_init_always() to do the expected thing and initialize i_ino to 0.
> > > > > 
> > > > > So, do that, and also remove the initialization in jfs_fill_super() that
> > > > > becomes redundant.
> > > > > 
> > > > > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > > > > ---
> > > > >  fs/inode.c     | 1 +
> > > > >  fs/jfs/super.c | 1 -
> > > > >  2 files changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/fs/inode.c b/fs/inode.c
> > > > > index 9d78c37b00b81..eb001129f157c 100644
> > > > > --- a/fs/inode.c
> > > > > +++ b/fs/inode.c
> > > > > @@ -142,6 +142,7 @@ int inode_init_always(struct super_block *sb, struct inode *inode)
> > > > >  	atomic_set(&inode->i_count, 1);
> > > > >  	inode->i_op = &empty_iops;
> > > > >  	inode->i_fop = &no_open_fops;
> > > > > +	inode->i_ino = 0;
> > > > >  	inode->__i_nlink = 1;
> > > > >  	inode->i_opflags = 0;
> > > > >  	if (sb->s_xattr)
> > > > > diff --git a/fs/jfs/super.c b/fs/jfs/super.c
> > > > > index b2dc4d1f9dcc5..1f0ffabbde566 100644
> > > > > --- a/fs/jfs/super.c
> > > > > +++ b/fs/jfs/super.c
> > > > > @@ -551,7 +551,6 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent)
> > > > >  		ret = -ENOMEM;
> > > > >  		goto out_unload;
> > > > >  	}
> > > > > -	inode->i_ino = 0;
> > > > >  	inode->i_size = i_size_read(sb->s_bdev->bd_inode);
> > > > >  	inode->i_mapping->a_ops = &jfs_metapage_aops;
> > > > >  	inode_fake_hash(inode);
> > > > > 
> > > > 
> > > > Al, any thoughts on this?
> > 
> > Ping.
> 
> Ping.

Applied.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-01-04 19:11 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-31  0:44 [PATCH] fs/inode.c: make inode_init_always() initialize i_ino to 0 Eric Biggers
2020-11-06 17:52 ` Eric Biggers
2020-11-20 18:50   ` Eric Biggers
2020-12-02 21:19     ` Eric Biggers
2021-01-04 18:54       ` Eric Biggers
2021-01-04 19:10         ` Al Viro
2020-11-10 15:55 ` Jeff Layton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).