linux-kernel - Re: [RFC PATCH 0/5] introduce proc_inode->pid

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 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:03:11 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	David Howells <dhowells@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Peter Zijlstra <peterz@...radead.org>,
	Sasha Levin <levinsasha928@...il.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/5] introduce proc_inode->pid_entry

Oleg Nesterov <oleg@...hat.com> 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.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/