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:	Sat, 1 Nov 2014 08:38:04 +0000
From:	Al Viro <>
To:	"Eric W. Biederman" <>
Cc:	Linus Torvalds <>,,
Subject: Re: [RFC] dealing with proc_ns_follow_link() and "namespace" dentries

On Mon, Oct 13, 2014 at 03:42:28PM -0700, Eric W. Biederman wrote:

> >From looking at your proposed code that doesn't look like it will be
> any more difficult to maintain from the namespace side.  So I have no
> objects with moving the code in that direction. 
> > 	It's obviously a project for the next cycle and it'll require
> > some cooperation between vfs and userns trees, but not too much of it -
> > all we really need is a never-changed commit embedding that structure into
> > all ...ns and passing _that_ to proc_{alloc,free}_inum() replacements
> > Merged both into vfs.git #for-next and usern one.  We can do that right
> > after -rc1.  Incidentally, it might make sense to move refcount into that
> > common piece as well, but that's independent from the stuff above.
> That sounds like a reasonable direction to go.  I think your schedule
> may be a tad optimistic time-wise, if for no other reason that code
> reviews take time, but that plan should work.

OK, interim branch (_completely_ untested, and there's quite a bit of
work remaining) is in vfs.git#nsfs.  It will be refactored; moreover,
most of that stuff will move out from fs/proc/namespaces.c - either into
fs/nsfs.c or into kernel/nsproxy.c.  And purely VFS followups are not even
touched yet - I know what I want to do, and I think there's no obstacles
left, but that's a separate story.  "Filesystem for ns dentries/inodes"
part is done, though (modulo debugging and moving it out of fs/proc).

I wonder if we would be better off not using proc_alloc_inum() there -
it's not hard to do a separate allocator, especially since there's no
requirements re non-intersecting sets of inumbers for procfs and for this.
That's the last part shared with procfs...

Anyway, I'm going down right now (nearly 5am here), so further fun will have
to wait a bit...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists