linux-kernel - Re: [RFC PATCH 1/3] debugfs: fix automount inode i

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 8 Feb 2016 08:35:27 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Roman Peniaev <r.peniaev@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/3] debugfs: fix automount inode i_nlink references

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@...uxfoundation.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