Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753078AbbEHOm6 (ORCPT ); Fri, 8 May 2015 10:42:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53209 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752821AbbEHOmz (ORCPT ); Fri, 8 May 2015 10:42:55 -0400 Date: Fri, 8 May 2015 10:42:50 -0400 From: Richard Guy Briggs To: "Eric W. Biederman" Cc: containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, pmoore@redhat.com, linux-audit@redhat.com, eparis@parisplace.org, sgrubb@redhat.com, zohar@linux.vnet.ibm.com Subject: Re: [PATCH V6 00/10] namespaces: log namespaces per task Message-ID: <20150508144250.GE20713@madcap2.tricolour.ca> References: <87vbgqw163.fsf@x220.int.ebiederm.org> <20150423030751.GA6712@madcap2.tricolour.ca> <20150423204429.GA25794@madcap2.tricolour.ca> <87bnid9v4f.fsf@x220.int.ebiederm.org> <20150428020555.GB20713@madcap2.tricolour.ca> <87zj5tgfpb.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zj5tgfpb.fsf@x220.int.ebiederm.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3796 Lines: 83 On 15/04/27, Eric W. Biederman wrote: > Richard Guy Briggs writes: > > On 15/04/24, Eric W. Biederman wrote: > >> Richard Guy Briggs writes: > >> > On 15/04/22, Richard Guy Briggs wrote: > >> >> On 15/04/20, Eric W. Biederman wrote: > >> >> > Richard Guy Briggs writes: > >> > Do I even need to report the device number anymore since I am concluding > >> > s_dev is never set (or always zero) in the nsfs filesystem by > >> > mount_pseudo() and isn't even mountable? > >> > >> We still need the dev. We do have a device number get_anon_bdev fills it in. > > > > Fine, it has a device number. There appears to be only one of these > > allocated per kernel. I can get it from &nsfs->fs_supers (and take the > > first instance given by hlist_for_each_entry and verify there are no > > others). Why do I need it, again? > > Because if we have to preserve the inode number over a migration event I > want to preserve the fact that we are talking about inode numbers from a > superblock with a device number. > > Otherwise known as I am allergic to kernel global identifiers, because > they can be major pains. I don't want to have to go back and implement > a namespace for namespaces. Alright, I'll change the device over to that... We can figure out how to select the correct device number of nsfs instances if it increases beyond one. > >> >> They are all covered: > >> >> sys_unshare > unshare_userns > create_user_ns > >> >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_mnt_ns > >> >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_utsname > clone_uts_ns > >> >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_ipcs > get_ipc_ns > >> >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_pid_ns > create_pid_namespace > >> >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_net_ns > >> > >> Then why the special change to fork? That was not reflected on > >> the unshare path as far as I could see. > > > > Fork can specify more than one CLONE flag at once, so collecting them > > all in one statementn seemed helpful. setns can only set one at a time. > > unshare can also specify more than one CLONE flag at once. > I just pointed that out becase that seemed really unsymmetrical. Ah sorry, my mistake, I was thinking setns... I've added a call in sys_unshare(). > > Ok, understood, we can't just punt this one to a higher layer... > > > > So this comes back to a question above, which is how do we determine > > which device it is from? Sounds like we need something added to > > ns_common or one of the 6 namespace types structs. > > Or we can just hard code reading it off of the appropriate magic > filesystem. Probably what we want is a well named helper function that > does the job. There is a bit of overhead to read that, so I've added a dev_t member to ns_common. Simplest way I found was to call iterate_supers() since struct file_system_type *nsfs isn't exposed. > I just care that when we talk about these things we are talking about > inode numbers from a superblock that is associated with a given device > number. That way I don't have nightmares about dealing with a namespace > for namespaces. > > Eric - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/