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