Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1291508 > unrolled thread

Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance Peter Hurley <peter@hurleysoftware.com> - 2015-12-14 20:50 +0100
    Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance "H. Peter Anvin" <hpa@zytor.com> - 2015-12-14 21:00 +0100
    Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance ebiederm@xmission.com (Eric W. Biederman) - 2015-12-19 22:30 +0100
      Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance ebiederm@xmission.com (Eric W. Biederman) - 2015-12-20 05:30 +0100
        Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance "H. Peter Anvin" <hpa@zytor.com> - 2015-12-20 05:40 +0100
          Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance ebiederm@xmission.com (Eric W. Biederman) - 2015-12-20 11:00 +0100
            Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance ebiederm@xmission.com (Eric W. Biederman) - 2015-12-21 23:20 +0100
              Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-21 23:30 +0100

#1291508 — Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance

On 12/11/2015 11:40 AM, Eric W. Biederman wrote:
> Forcing newinstance for every mount of the devpts filesystem actually
> requires the association between /dev/ptmx and the currently mounted
> instance of devpts at /dev/pts.  Simply remembering the first mount of
> the devpts filesystem and associating that with /dev/ptmx is not
> enough.  I am aware of at least one instance where an initramfs mounts
> devpts before the main system instance of devpts is mounted.

Can you point me to that usage please?

I ask because there's a patch to move devpts init from module initcall
up to fs initcall (neither devpts nor the pty driver is actually built
as a module anyway), and I'd like to look at what the consequences
might be for that userspace configuration.


> In that system ptys simply did not work after boot when I tested
> associating /dev/ptmx with the first mount of the devpts filesystem.

Assuming userspace isn't broken by that patch, is a fixed association
with first mount otherwise an acceptable solution for magic /dev/ptmx
(where /dev/ptmx is not a symlink to /dev/pts/ptmx)?

Regards,
Peter Hurley

--
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/

[toc] | [next] | [standalone]

#1291514

On 12/14/15 11:47, Peter Hurley wrote:
> On 12/11/2015 11:40 AM, Eric W. Biederman wrote:
>> Forcing newinstance for every mount of the devpts filesystem actually
>> requires the association between /dev/ptmx and the currently mounted
>> instance of devpts at /dev/pts.  Simply remembering the first mount of
>> the devpts filesystem and associating that with /dev/ptmx is not
>> enough.  I am aware of at least one instance where an initramfs mounts
>> devpts before the main system instance of devpts is mounted.
> 
> Can you point me to that usage please?
> 
> I ask because there's a patch to move devpts init from module initcall
> up to fs initcall (neither devpts nor the pty driver is actually built
> as a module anyway), and I'd like to look at what the consequences
> might be for that userspace configuration.
> 
> 
>> In that system ptys simply did not work after boot when I tested
>> associating /dev/ptmx with the first mount of the devpts filesystem.
> 
> Assuming userspace isn't broken by that patch, is a fixed association
> with first mount otherwise an acceptable solution for magic /dev/ptmx
> (where /dev/ptmx is not a symlink to /dev/pts/ptmx)?
> 

The problem is containers, I would think, if they create a new /dev/ptmx
and then mount a separate devpts instance instead of doing a bind mount.

	-hpa


--
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/

[toc] | [prev] | [next] | [standalone]

#1295473

Peter Hurley <peter@hurleysoftware.com> writes:

> On 12/11/2015 11:40 AM, Eric W. Biederman wrote:
>> Forcing newinstance for every mount of the devpts filesystem actually
>> requires the association between /dev/ptmx and the currently mounted
>> instance of devpts at /dev/pts.  Simply remembering the first mount of
>> the devpts filesystem and associating that with /dev/ptmx is not
>> enough.  I am aware of at least one instance where an initramfs mounts
>> devpts before the main system instance of devpts is mounted.
>
> Can you point me to that usage please?

I have found that the Dracut versions in CentOS5 and CentOS6 generates
initial ramdisks that mount devpts before the primary OS mount of devpts
on /dev/pts.  I have also found that openwrt-15.05 without an initial
ramdisk does something strange during startup and boots devpts twice as
well.

I have looked but I haven't seen that pattern elsewhere but my search
space of 15ish distros is small compared to what is out there.  Given
that mounting devpts multiple times has been implemented at least twice
independently I would not be surprised if mounting devpts multiple times
during boot shows up somewhere else.

> I ask because there's a patch to move devpts init from module initcall
> up to fs initcall (neither devpts nor the pty driver is actually built
> as a module anyway), and I'd like to look at what the consequences
> might be for that userspace configuration.

I don't expect there are any.  As all of this happens before userspace
initializes anyway.    We have enough variation in the kernel anyway
that the device number the first devpts is mounted on varies between
kernels already.

>> In that system ptys simply did not work after boot when I tested
>> associating /dev/ptmx with the first mount of the devpts filesystem.
>
> Assuming userspace isn't broken by that patch, is a fixed association
> with first mount otherwise an acceptable solution for magic /dev/ptmx
> (where /dev/ptmx is not a symlink to /dev/pts/ptmx)?

I do not believe a fixed association with the first mount is an
acceptable solution for implementing  /dev/ptmx in association with
a change to cause mount of devpts to be an independent filesystem.
Such an association fails to be backwards compatible with existing
userspace, and it is extremely fragile.

If the association between the device node and the filesystem in the
mount namespace is insufficient for backwards compatibility I do not
believe full backwards compatibility is acheivable with a magic version
of /dev/ptmx.

On the flip side the consequences of a ptmx symlink in devpts pointing
to pts/ptmx look extremely minor.  Of my test cases only openwrt-15.05
and CentOS5 fail, as they don't use devtmpfs.  While debian-6.0.2,
debian-7.9, debian-8.2, CentOS6, CentOS7, fedora32, magia-5, mint-17.3,
opensuse-42.1, slackware-14.1, unbuntu-14.04.3 and ubuntu-15.10 all
work.

By making the change in behavior controlled by a kernel command line
option (devpts.newinstance is what I have been testing with) that allows
me to build a single kernel that works on everything.  Which is enough
backwards compatibility for me.

I still have not quite reached the point of testing what the real world
consequences for programs such as lxc that currently use the newinstance
option are.  There is a possibility that if someone is bind mounting
/dev/pts/ptmx over /dev/ptmx they might break.  Similarly there may be a
few cases do "mknod ptmx c 5 2" and that will start failing.

I don't expect running into weird userspace cases that fail will change
my opinion on a path forward, but it will be good to know what the
consequences are of flipping the option.  As so far everything thing
looks like it will just work.

Right now having a nano-flag day and putting a symlink in devtmps looks
a whole lot cleaner in both implementation, maintenance and use than a
magic /dev/ptmx.

Eric
--
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/

[toc] | [prev] | [next] | [standalone]

#1295518

ebiederm@xmission.com (Eric W. Biederman) writes:

>>> In that system ptys simply did not work after boot when I tested
>>> associating /dev/ptmx with the first mount of the devpts filesystem.
>>
>> Assuming userspace isn't broken by that patch, is a fixed association
>> with first mount otherwise an acceptable solution for magic /dev/ptmx
>> (where /dev/ptmx is not a symlink to /dev/pts/ptmx)?
>
> I do not believe a fixed association with the first mount is an
> acceptable solution for implementing  /dev/ptmx in association with
> a change to cause mount of devpts to be an independent filesystem.
> Such an association fails to be backwards compatible with existing
> userspace, and it is extremely fragile.

Ugh.  After reviewing the userspace code that mounts devpts we have
to do use a magic /dev/ptmx to solve the issue we are trying to solve.

The fragility of detecting the primary system devpts seems solvable.

CentOS5 and openwrt-15.05 mount devpts, unmount devpts,
then mount devpts again.  So a rule of mouting the internal devpts if it
isn't mounted would work for those.

CentOS6 uses switch_root and moves it's early mount of devpts onto the
primary root, and then because devpts is also in /etc/fstab tries and
fails to mount devpts once more at the same location.  Implying
newinstance will make that mounting devpts twice.  That sounds solvable
but I don't see a clean way of detecting that case yet.

Ugh.

I am going to pound my head up against what is needed to find the
primary system mount of devpts for a bit more and see if I can solve
that.  Otherwise this exercise is pointless.

Eric

--
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/

[toc] | [prev] | [next] | [standalone]

#1295519

On December 19, 2015 8:11:50 PM PST, ebiederm@xmission.com wrote:
>ebiederm@xmission.com (Eric W. Biederman) writes:
>
>>>> In that system ptys simply did not work after boot when I tested
>>>> associating /dev/ptmx with the first mount of the devpts
>filesystem.
>>>
>>> Assuming userspace isn't broken by that patch, is a fixed
>association
>>> with first mount otherwise an acceptable solution for magic
>/dev/ptmx
>>> (where /dev/ptmx is not a symlink to /dev/pts/ptmx)?
>>
>> I do not believe a fixed association with the first mount is an
>> acceptable solution for implementing  /dev/ptmx in association with
>> a change to cause mount of devpts to be an independent filesystem.
>> Such an association fails to be backwards compatible with existing
>> userspace, and it is extremely fragile.
>
>Ugh.  After reviewing the userspace code that mounts devpts we have
>to do use a magic /dev/ptmx to solve the issue we are trying to solve.
>
>The fragility of detecting the primary system devpts seems solvable.
>
>CentOS5 and openwrt-15.05 mount devpts, unmount devpts,
>then mount devpts again.  So a rule of mouting the internal devpts if
>it
>isn't mounted would work for those.
>
>CentOS6 uses switch_root and moves it's early mount of devpts onto the
>primary root, and then because devpts is also in /etc/fstab tries and
>fails to mount devpts once more at the same location.  Implying
>newinstance will make that mounting devpts twice.  That sounds solvable
>but I don't see a clean way of detecting that case yet.
>
>Ugh.
>
>I am going to pound my head up against what is needed to find the
>primary system mount of devpts for a bit more and see if I can solve
>that.  Otherwise this exercise is pointless.
>
>Eric

Does it matter if it mounts devpts twice?  It seems like a waste of a minuscule amount of memory, and nothing else.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
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/

[toc] | [prev] | [next] | [standalone]

#1295549

"H. Peter Anvin" <hpa@zytor.com> writes:

> Does it matter if it mounts devpts twice?  It seems like a waste of a
> minuscule amount of memory, and nothing else.

It breaks system("mknod /tmp/ptmx c 5 2"); open("/tmp/ptmx");

As it opens a pty in an inaccessible instance of devpts.  When
previously the instance of devpts was accessible.  So backwards
compatibility is broken.

It doubly matters as we have evidence that b0rken userspace actually
does that things like that.

I will probably get a grumble or two but it turns out it isn't
particularly hard to deal with the overmounting that happens in CentOS6,
and the mounting then unmounting then mounting again that happens in
CentOS5, and openwrt.

For the cases I know to test for I have something that works now.    I
am going to  sleep on it and then see if I can find think of other
things to test before I push out a patch.

Eric

--
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/

[toc] | [prev] | [next] | [standalone]

#1296253

ebiederm@xmission.com (Eric W. Biederman) writes:

> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> Does it matter if it mounts devpts twice?  It seems like a waste of a
>> minuscule amount of memory, and nothing else.

> It breaks system("mknod /tmp/ptmx c 5 2"); open("/tmp/ptmx");

Correction.

It does break the above but that isn't the real reason we need to
support that.  We only have evidence of pople doing:
"mkdir -p dev/pts; mknod c dev/ptmx 5 2; mount -t devpts dev/pts/"
Where the relatives paths would work.

What actually breaks is "echo NNN > /proc/sys/kernel/pty/reserve"
Which allows the primary instance of devpts to have access to more
ptys than any other instance.

Ultimately if we are going to be backwards compatible we need to
preserve as much of the current behavior as possible so we don't forget
something in the analysis and break something we don't intend to break
by accident.

Eric
--
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/

[toc] | [prev] | [next] | [standalone]

#1296261

On Mon, Dec 21, 2015 at 2:03 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> What actually breaks is "echo NNN > /proc/sys/kernel/pty/reserve"
> Which allows the primary instance of devpts to have access to more
> ptys than any other instance.

Ok. We'll probably need to fix that similarly (make it look up
/dev/pts to figure out *which* pty reserve to fix), but I think that's
entirely separate from the ptmx issue for now.

                 Linus
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web