From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [RFC PATCH 0/5] introduce proc_inode->pid_entry Date: Fri, 08 Aug 2014 15:11:16 -0700 Message-ID: <87mwbemy2j.fsf@x220.int.ebiederm.org> References: <20140808185732.GA760@redhat.com> <87d2caod0g.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain Cc: Alexander Viro , Alexey Dobriyan , Andrew Morton , Cyrill Gorcunov , David Howells , "David S. Miller" , "Kirill A. Shutemov" , Peter Zijlstra , Sasha Levin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Oleg Nesterov Return-path: Received: from out02.mta.xmission.com ([166.70.13.232]:35035 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932142AbaHHWPN (ORCPT ); Fri, 8 Aug 2014 18:15:13 -0400 In-Reply-To: <87d2caod0g.fsf@x220.int.ebiederm.org> (Eric W. Biederman's message of "Fri, 08 Aug 2014 15:03:11 -0700") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: ebiederm@xmission.com (Eric W. Biederman) writes: > Oleg Nesterov 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// 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//net because an automount. Similarly /proc/sys/ really needs to become at least a symlink into /proc//sys and quite possibly an automount itself. And arguably it would be nice to split /proc/ 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