Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1328791 > unrolled thread

Re: [RFC PATCH 1/3] debugfs: fix automount inode i_nlink references

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH 1/3] debugfs: fix automount inode i_nlink references Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-02-08 07:40 +0100
    Re: [RFC PATCH 1/3] debugfs: fix automount inode i_nlink references Roman Peniaev <r.peniaev@gmail.com> - 2016-02-08 11:30 +0100
      Re: [RFC PATCH 1/3] debugfs: fix automount inode i_nlink references Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-02-08 17:40 +0100

#1328791 — Re: [RFC PATCH 1/3] debugfs: fix automount inode i_nlink references

On Thu, Dec 10, 2015 at 01:47:12PM +0100, Roman Pen wrote:
> Directory inodes should start off with i_nlink == 2 (for "." entry).
> Of course the same rule should be applied to automount dentries for
> child and parent inodes as well.
> 
> Also now automount dentry does fsnotify_mkdir.
> 
> Without this patch kernel complains when sees i_nlink == 0:

How can the kernel see this?  What did you do to trigger this?

thanks,

greg k-h

[toc] | [next] | [standalone]

#1328889

On Mon, Feb 8, 2016 at 7:38 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Dec 10, 2015 at 01:47:12PM +0100, Roman Pen wrote:
>> Directory inodes should start off with i_nlink == 2 (for "." entry).
>> Of course the same rule should be applied to automount dentries for
>> child and parent inodes as well.
>>
>> Also now automount dentry does fsnotify_mkdir.
>>
>> Without this patch kernel complains when sees i_nlink == 0:
>
> How can the kernel see this?  What did you do to trigger this?

Yes, sorry, I had to be more precise on this.
That happens on unlinking of automount dentry.

Easily can be reproduced:

    autom = debugfs_create_automount("automount", parentd, vfsmount_cb, data);
    BUG_ON(IS_ERR_OR_NULL(autom));
    debugfs_remove(autom);

You will immediately see one warning on attempt to drop_nlink() (which is zero)
for automount dentry.

The second warning happens when you unlink 'parentd', because
debugfs_create_automount() did not increase the nlink for parent
inode.

Do I need to resend this patch with more precise description?

--
Roman

>
> thanks,
>
> greg k-h

[toc] | [prev] | [next] | [standalone]

#1329294

On Mon, Feb 08, 2016 at 11:28:52AM +0100, Roman Peniaev wrote:
> On Mon, Feb 8, 2016 at 7:38 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Thu, Dec 10, 2015 at 01:47:12PM +0100, Roman Pen wrote:
> >> Directory inodes should start off with i_nlink == 2 (for "." entry).
> >> Of course the same rule should be applied to automount dentries for
> >> child and parent inodes as well.
> >>
> >> Also now automount dentry does fsnotify_mkdir.
> >>
> >> Without this patch kernel complains when sees i_nlink == 0:
> >
> > How can the kernel see this?  What did you do to trigger this?
> 
> Yes, sorry, I had to be more precise on this.
> That happens on unlinking of automount dentry.
> 
> Easily can be reproduced:
> 
>     autom = debugfs_create_automount("automount", parentd, vfsmount_cb, data);
>     BUG_ON(IS_ERR_OR_NULL(autom));
>     debugfs_remove(autom);
> 
> You will immediately see one warning on attempt to drop_nlink() (which is zero)
> for automount dentry.

Why don't we see this "in the wild" today with the one user of this
function?

> The second warning happens when you unlink 'parentd', because
> debugfs_create_automount() did not increase the nlink for parent
> inode.
> 
> Do I need to resend this patch with more precise description?

Yes, please fix up and resend as a stand-alone patch, as it is
independant of your other proposal.

And take off the "RFC" marking, I can never apply a patch with that type
of marking as you obviously don't think it is good enough to be merged,
so why would I?  :)

thanks,

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web