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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
