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  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:	Fri, 08 Aug 2014 15:11:16 -0700
From: (Eric W. Biederman)
To:	Oleg Nesterov <>
Cc:	Alexander Viro <>,
	Alexey Dobriyan <>,
	Andrew Morton <>,
	Cyrill Gorcunov <>,
	David Howells <>,
	"David S. Miller" <>,
	"Kirill A. Shutemov" <>,
	Peter Zijlstra <>,
	Sasha Levin <>,,
Subject: Re: [RFC PATCH 0/5] introduce proc_inode->pid_entry (Eric W. Biederman) writes:

> Oleg Nesterov <> writes:
>> Hello,
>> Obviously not for inclusion. The patches are horrible, break task_nommu.c,
>> untested, etc. Only to explain what I mean and discuss the intent, at least.
>> On top of recent /proc/pid/*maps* cleanups I sent.
>> To me it looks a bit annoying that task_mmu.c needs 6 seq_operations's and
>> 6 file_operations's to handle /proc/pid/*maps*. And _only_ because ->show()
>> differs.
>> Eric, et al, what do you think? At least something like 1-3 looks like a
>> good cleanup imho. And afaics we can do more cleanups on top.
> I see where you are getting annoyed.
> Taking a quick look at task_mmu.c  It looks like the tgid vs pid logic
> to decided which stack or stacks to display is simply incorrect.
> tgid vs pid is all about do we perform the per thread group rollups or
> not.  Because we have /proc/<tid>/ directories that need the rollups
> but are per thread.
> At a practical level moving pid_entry into the proc inode is ugly
> especially for the hack that is is_tgid_pid_entry.
> That test could be implemented more easily by looking at the parent
> directories inode operations and seeing if they are
> proc_root_inode_operations.
> Similarly you can get the names out of the dentry, although comparing
> on the dentry name feels like a real hack.
> Given where you are starting I think tack_mmu.c code that decides
> when/which stack deserves a serious audit.

On a slightly larger scale it is probably about time to step back
and look at /proc and see what structural cleanups can be done.

Since last time I was looking deeply a bunch of work has been done in
the automount area, and it would be ever so nice if /proc/<pid>/net
because an automount.

Similarly /proc/sys/ really needs to become at least a symlink into
/proc/<pid>/sys and quite possibly an automount itself.

And arguably it would be nice to split /proc/<pid> from /proc generic,
so we would actually have a pure proc.

Shrug. At least if those are ideas worth thinking about and some of them
have the potential to cleanup some nasty interactions with the vfs.


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