public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Hannes Reinecke <hare@suse.de>,
	gregkh@linuxfoundation.org, containers@lists.linux.dev,
	linux-kernel@vger.kernel.org, lkml@metux.net
Subject: Re: device namespaces
Date: Fri, 11 Jun 2021 13:14:42 -0500	[thread overview]
Message-ID: <87v96k1d65.fsf@disp2133> (raw)
In-Reply-To: <20210609080918.ma2klvxkjad4pjrn@wittgenstein> (Christian Brauner's message of "Wed, 9 Jun 2021 10:09:18 +0200")

Christian Brauner <christian.brauner@ubuntu.com> writes:

> On Wed, Jun 09, 2021 at 09:54:05AM +0200, Hannes Reinecke wrote:
>> On 6/9/21 9:21 AM, Christian Brauner wrote:
>> > On Wed, Jun 09, 2021 at 09:02:36AM +0200, Hannes Reinecke wrote:
>> >> On 6/9/21 8:38 AM, Christian Brauner wrote:
>> >>> On Tue, Jun 08, 2021 at 12:16:43PM -0500, Eric W. Biederman wrote:
>> >>>> Hannes Reinecke <hare@suse.de> writes:
>> >>>>
>> >>>>> On 6/8/21 4:29 PM, Christian Brauner wrote:
>> >>>>>> On Tue, Jun 08, 2021 at 04:10:08PM +0200, Hannes Reinecke wrote:
>> >> [ .. ]
>> >>>>> Granted, modifying sysfs layout is not something for the faint-hearted,
>> >>>>> and one really has to look closely to ensure you end up with a
>> >>>>> consistent layout afterwards.
>> >>>>>
>> >>>>> But let's see how things go; might well be that it turns out to be too
>> >>>>> complex to consider. Can't tell yet.
>> >>>>
>> >>>> I would suggest aiming for something like devptsfs without the
>> >>>> complication of /dev/ptmx.
>> >>>>
>> >>>> That is a pseudo filesystem that has a control node and virtual block
>> >>>> devices that were created using that control node.
>> >>>
>> >>> Also see android/binder/binderfs.c
>> >>>
>> >> Ah. Will have a look.
>> > 
>> > I implemented this a few years back and I think it should've made it
>> > onto Android by default now. So that approach does indeed work well, it
>> > seems:
>> > https://chromium.googlesource.com/aosp/platform/system/core/+/master/rootdir/init.rc#257
>> > 
>> > This should be easier to follow than the devpts case because you don't
>> > need to wade through the {t,p}ty layer.
>> > 
>> >>
>> >>>>
>> >>>> That is the cleanest solution I know and is not strictly limited to use
>> >>>> with containers so it can also gain greater traction.  The interaction
>> >>>> with devtmpfs should be simply having devtmpfs create a mount point for
>> >>>> that filesystem.
>> >>>>
>> >>>> This could be a new cleaner api for things like loopback devices.
>> >>>
>> >>> I sent a patchset that implemented this last year.
>> >>>
>> >> Do you have a pointer/commit hash for this?
>> > 
>> > Yes, sure:
>> > https://lore.kernel.org/linux-block/20200424162052.441452-1-christian.brauner@ubuntu.com/
>> > 
>> > You can also just pull my branch. I think it's still based on v5.7 or sm:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=loopfs
>> > 
>> > I'm happy to collaborate on this too.
>> >
>> How _very_ curious. 'kernfs: handle multiple namespace tags' and 'loop:
>> preserve sysfs backwards compability' are essentially the same patches I
>> did for my block namespaces prototyp; I named it 'KOBJ_NS_TYPE_BLK', not
>> 'KOBJ_NS_TYPE_USER', though :-)
>> 
>> Guess we really should cooperate.
>> 
>> Speaking of which: why did you name it 'user' namespace?
>> There already is a generic 'user_namespace' in
>> include/linux/user_namespace.h, serving as a container for all
>> namespaces; as such it probably should include this 'user' namespace,
>> leading to quite some confusion.
>> 
>> Or did I misunderstood something here?
>
> Ah yes, you misunderstand. The KOBJ_NS_TYPE_* tags are namespace tags.
> So KOBJ_NS_TYPE_NET is a network namespace tag. So KOBJ_NS_TYPE_USER is
> a user namespace tag not a completely new namespace. The idea very
> roughly being that devices such as loop devices are ultimately filtered
> by user namespace which is taken from the s_user_ns the loopfs instance
> is mounted in. We should compare notes.

There are two easy possibilities.

- All of the devices on the filesystem show up in sysfs with unique
  major minor numbers.
- None of the devices on the filesystem show up in sysfs.
  (Which I believe is what devpts does).

I favor none of the virtual devices showing up in sysfs.  Maybe existing
userspace needs the devices in sysfs, but if the solution is simply to
skip sysfs for virtual devices that is much simpler.

Eric


  reply	other threads:[~2021-06-11 18:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08  9:38 device namespaces Enrico Weigelt, metux IT consult
2021-06-08 12:30 ` Christian Brauner
2021-06-08 12:41   ` Greg Kroah-Hartman
2021-06-08 14:10     ` Hannes Reinecke
2021-06-08 14:29       ` Christian Brauner
2021-06-08 15:54         ` Hannes Reinecke
2021-06-08 17:16           ` Eric W. Biederman
2021-06-09  6:38             ` Christian Brauner
2021-06-09  7:02               ` Hannes Reinecke
2021-06-09  7:21                 ` Christian Brauner
2021-06-09  7:54                   ` Hannes Reinecke
2021-06-09  8:09                     ` Christian Brauner
2021-06-11 18:14                       ` Eric W. Biederman [this message]
2021-06-14  7:49                         ` Enrico Weigelt, metux IT consult
2021-06-14  8:22                           ` Greg KH
2021-06-14 17:36                           ` Eric W. Biederman
2021-06-15 11:24                             ` Enrico Weigelt, metux IT consult
2021-06-15 11:33                               ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v96k1d65.fsf@disp2133 \
    --to=ebiederm@xmission.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=containers@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@metux.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox