linux-kernel - Re: [PATCH 00/10] sysfs tagged directories

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080501031228.GC4911@suse.de>
Date:	Wed, 30 Apr 2008 20:12:28 -0700
From:	Greg KH <gregkh@...e.de>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Benjamin Thery <benjamin.thery@...l.net>,
	linux-kernel@...r.kernel.org, Al Viro <viro@....linux.org.uk>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tejun Heo <htejun@...il.com>,
	Daniel Lezcano <dlezcano@...ibm.com>,
	Pavel Emelyanov <xemul@...nvz.org>, netdev@...r.kernel.org
Subject: Re: [PATCH 00/10] sysfs tagged directories

On Tue, Apr 29, 2008 at 02:34:17PM -0500, Serge E. Hallyn wrote:
> Quoting Greg KH (gregkh@...e.de):
> > On Tue, Apr 29, 2008 at 01:04:45PM -0500, Serge E. Hallyn wrote:
> > > Quoting Greg KH (gregkh@...e.de):
> > > > On Tue, Apr 29, 2008 at 07:10:15PM +0200, Benjamin Thery wrote:
> > > > > Here is the announcement Eric wrote back in December to introduce his 
> > > > > patchset:
> > > > 
> > > > <snip>
> > > > 
> > > > Are the objections that Al Viro made to this patchset when it was last
> > > > sent out addressed in this new series?
> > > > 
> > > > thanks,
> > > > 
> > > > greg k-h
> > > 
> > > Which objections were those?  The last submission which I see by Eric
> > > was http://lkml.org/lkml/2007/12/1/15 this past December.  I see no
> > > response from Al and get the feeling you were ok with them.
> > > 
> > > So my hunch would be that Eric had addressed those before that last
> > > submission, but if not I'm sorry, and please do set me straight.
> > 
> > See the thread from Al starting with:
> > 	Date: Mon, 7 Jan 2008 10:24:17 +0000
> > 	From: Al Viro <viro@...IV.linux.org.uk>
> > 	To: "Eric W. Biederman" <ebiederm@...ssion.com>
> > 	Cc: linux-kernel@...r.kernel.org, htejun@...il.com,
> > 	        linux-fsdevel@...r.kernel.org, gregkh@...e.de
> > 	Subject: [RFC] netns / sysfs interaction
> > 	Message-ID: <20080107072301.GW27894@...IV.linux.org.uk>
> > 
> > He had a lot of questions and objections to this way forward, and I
> > share those objections.
> 
> Ah I see it, thanks.
> 
> All Al's questions appear to be about how a task migration will be handled
> in the face of funky userspace usage of sysfs files.  But it seems clear the
> first use of these will not be for migration but for vservers.  The key
> thing to remember is that we don't (as decided at kernel-summit 06) aim
> to hide from userspace the fact that it's in a vserver, we just give it
> what it needs so that it can pretend.
> 
> As we start implementing checkpoint and restart to effect migration,
> *clearly* if we're trying to restart a task which has cwd or an open fd
> in /sys/class/net/eth42/, but that directory doesn't exist on the target
> machine, then the restart (and hence migrate) fails.
> 
> There was a concern about
> /sys/devices/pci0000\:00/0000\:00\:0a.0/net:eth0.  Since that's a
> symlink to ../../../class/net/eth0, it will either point nowhere or
> point to the virtualized eth0, if veth1 (or vethN) was renamed to eth0
> in the container.  (see below)  If that is the wrong thing to do we
> could try to address it in this patchset, but I suspect it is better
> left until device namespace are implemented.  Does that sounds sane?

I really don't think so, but I'll wait for the reworked patches to
review them and see how badly they mess the code up :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/