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

[Eric W. Biederman]

ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes:

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

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.

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/