Received: by 10.213.65.68 with SMTP id h4csp312992imn; Mon, 12 Mar 2018 14:54:06 -0700 (PDT) X-Google-Smtp-Source: AG47ELtoBmJW5S8lEWIv1RJFSwDrV0u002pt4zwbuat1SeYb9+g/Al5b5tBp3xEq+t8XmMKLT00P X-Received: by 10.98.103.136 with SMTP id t8mr9406167pfj.177.1520891646461; Mon, 12 Mar 2018 14:54:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520891646; cv=none; d=google.com; s=arc-20160816; b=Sk5JT8n/K4fA5pBVSMMXfzVBFm3pNh4WxIuOgns+f6LKmWmkbX7TVWndb3adOB+n4q 63OjOVfYU5z+vXcXp4aRaZbgoZdS5KZG6DFUdZmJic6IuiaLfpAY+qXGB8R93mdhQWxf 4U2LDO9RbYRuhWMiCwybxAeMHMldDpgNsUsEVs6VHFlCVkuXED02FPOts41TQU9m6FMi /yjCxiAFnGe6/z6I95c5wzoXivjOia87ClHjvLN2iLUb2vHOL+q/0ajOsg+veoDj4Fyw /dezPV0f5DqUbumntLFvMsTgefQ/MbUoRGjl8ytX9CgQ0Ei3NH7mJems8mDtmywCn/GB +gPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=9+dBa/S/P7NIgAPGgWXujMyW0HRvmGYHldMWI317DBo=; b=U2BUKJfUx1j2F+EaY5jc5mq04WzCEKqyJApTcANkVHsQV05ba2fNWBlQGrNXjuTHqE GMWeJg85bD/9KhWUrvwbBlKqO4UJG2AjS4ylllNiDpPiSRN6xxb5+U8CRP1oWs5VNu8e wy2Vm8JFZb9sPMKmaZW2h2iV6zmS8TuoXzIgpqJ04oWKNUjUckh1z+SuqUEZuWHf8EGk RdcoMbpCQXN3O0mAztAEu75elrj/ZjQAUyLEZkM/kfpBVkuv4KCeoit2sM+PR8bGSBS4 mYRPdV/EfmoY3eW4b23C+InYHv1k1l53aKHhnpCzPuS0uV0quPwcM+c2J3mKOY1vtDSL 9XCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=tR5OeeSd; dkim=fail header.i=@linux-foundation.org header.s=google header.b=bE+X3cgE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m185si6371211pfc.361.2018.03.12.14.53.49; Mon, 12 Mar 2018 14:54:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=tR5OeeSd; dkim=fail header.i=@linux-foundation.org header.s=google header.b=bE+X3cgE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932447AbeCLVwr (ORCPT + 99 others); Mon, 12 Mar 2018 17:52:47 -0400 Received: from mail-it0-f50.google.com ([209.85.214.50]:50568 "EHLO mail-it0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932265AbeCLVwq (ORCPT ); Mon, 12 Mar 2018 17:52:46 -0400 Received: by mail-it0-f50.google.com with SMTP id d13so13179404itf.0 for ; Mon, 12 Mar 2018 14:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9+dBa/S/P7NIgAPGgWXujMyW0HRvmGYHldMWI317DBo=; b=tR5OeeSdszvkUYjmY+d0x2AWhKHS4+tF/MuyPwZYkbjP1FasZFjrZv788ae2rXj3hT c+GPJZaGY6Q13LMJPqAC3nbIgAdsCPqT0fPb+l7PAzKZ8YAGjrW6EMMQsiC9nuH94ueU lMr8jCRSEkhE0pYXY9EAEbTp7cF+miKA/n+1EX3mYBO2MW6lrJ2gNN5I3V19MvJDu1Fu PDnOq9u2b13zf7CTd0cgHkb1lOvarjCBiDhtye93brWzlwgqLHIrT6arka0WgtTp11fm iG0mNLLJPE8vOefCNexgHE5TAwF+AAJKMwtPfv6zgcWlIjTBgEB3lBsgBn0GZyzqqAX4 Yt8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9+dBa/S/P7NIgAPGgWXujMyW0HRvmGYHldMWI317DBo=; b=bE+X3cgEydLDma1dcxZ6ppZvSFRiI3+YzsHOUxloHO0SShxJJTPm2tjkQl7bjs6iHh l2FbTLYI6IEc3VeMMgUwDpsKhXoYaUqiFa1U3x494LWGKGSE1t6WQR0VrNVk/gsxwPqQ rgrU+3Xg3lIjWZ14n3H7eyoVcTXSTB4aO6UY0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9+dBa/S/P7NIgAPGgWXujMyW0HRvmGYHldMWI317DBo=; b=eAJeoC62mVZ3b8N/+BKRjb1TyyktKyXMdmNzre0RiOu0Fn+foPgXi0hXXuVjaHhyjl xpzpQOjjf/pX0HjtWAHuE37kBDIVjXainfVrx176gINY8FmyaUNt+QP7Oxp4gwxCGRZA UofrIa1S6GiTBwyh0LN5v5nhKA/A48xrNld79/GuJ936a8wczbmMZ68wuvdJIK0eG56V gsFx192C1rPrcC9F4o39wGpOV/iOHIkh38yVHgWvp+/gnIU56dX3jqxNnPSnGK45SVOH F1y6IuYZy3iPbWrGeIjuYeLFGjoP5GAW3X6chR3nDZMfLHdWdbRBPn71wXfefjxrAuPx Z6QQ== X-Gm-Message-State: AElRT7EGMq4lo8zhaqaW33wMSMoY22IG80O6+1IXDNQt8mQLKxqHyqAH 3sdFixKbEvPs7K7ikLWFVnGPNEqmjL8px1PLQSs= X-Received: by 10.36.89.137 with SMTP id p131mr10079365itb.113.1520891565381; Mon, 12 Mar 2018 14:52:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.135.221 with HTTP; Mon, 12 Mar 2018 14:52:44 -0700 (PDT) In-Reply-To: <20180312201022.GA16689@gmail.com> References: <20180312171330.32054-1-christian.brauner@ubuntu.com> <20180312171330.32054-3-christian.brauner@ubuntu.com> <87a7vdf4ve.fsf@xmission.com> <20180312201022.GA16689@gmail.com> From: Linus Torvalds Date: Mon, 12 Mar 2018 14:52:44 -0700 X-Google-Sender-Auth: E9xw32rAvD3lmDAhk1wTSyXcRa8 Message-ID: Subject: Re: [PATCH 2/3 v3] devpts: resolve devpts bind-mounts To: Christian Brauner Cc: "Eric W. Biederman" , Christian Brauner , Al Viro , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 12, 2018 at 1:10 PM, Christian Brauner wrote: >> >> So let's just change the behavior of devpts_mntget error if a mount with >> the pty underneath it can not be found. > > I'm sort of torn but I think I'd prefer changing the behavior too. The > /dev/ptmx, /dev/pts/ptmx schisma is really a special case and I would > like it to be the only one. I really don't want to support bind-mounting > the ptmx character device under the devpts mounts across the system. > That seems like unnecessary complexity that is also unused. So if Linus > is fine with this change as well I don't mind sending a v4. I'm fine with whatever error handling - I cannot imagine that it matters. And if it does, and somebody finds somebody who depends on insane behavior, we can revisit it then, But fundamentally. I think there are only two valid situations: - people use devpts as-is (so the ptmx node is inherently in the same subdirectory as the pts nodes, and is fundamentally the same filesystem) NOTE! In this case, the ptmx node is *never* a bind-mount. It is simply part of the pts directory as exported by devpts. This is the "people actually use /dev/pts/ptmx" case. It's fairly rare, I think. - the parent directory ptmx node is an arbitrary ptmx node (symlink, bind mount, or mknod) NOTE! In this case, the ptmx node is not necessarily associated with the pts directory in any way, and the only thing that matters is that it's the right special character device. Honestly, I personally detest case #1, even if some people think it's the "clean" case. It isn't particularly clean, since it fundamentally is not how /dev/ptmx has traditionally ever worked. It would have been clean had that been how ptmx worked traditionally, but that' ssimply not the case. But if something really odd happens, and we cannot find a pts subdirectory, or there is not a pts node, or not a ptmx node in that subdirectory, I think all bets are pretty much off path-wise. Returning an error is probably better than returning a bogus path. Linus