Re: [RFC PATCH 0/5] introduce proc_inode->pid_entry

[Eric W. Biederman]

Oleg Nesterov <oleg@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/