Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752523AbdHPWFh (ORCPT ); Wed, 16 Aug 2017 18:05:37 -0400 Received: from mail-ua0-f170.google.com ([209.85.217.170]:33019 "EHLO mail-ua0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752266AbdHPWFg (ORCPT ); Wed, 16 Aug 2017 18:05:36 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170816171211.4021-1-christian.brauner@ubuntu.com> <20170816194805.hnof3aqiqykwki7p@gmail.com> From: Christian Brauner Date: Thu, 17 Aug 2017 00:05:34 +0200 Message-ID: Subject: Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name To: Linus Torvalds Cc: Christian Brauner , Linux Kernel Mailing List , "Serge E. Hallyn" , Al Viro Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v7GM5hTe015468 Content-Length: 1571 Lines: 33 On Wed, Aug 16, 2017 at 11:55 PM, Linus Torvalds wrote: > On Wed, Aug 16, 2017 at 2:45 PM, Linus Torvalds > wrote: >> >> But it would be good to just test this in general too, and make sure I >> didn't screw up some reference count or something. The patch *looks* >> obviously correct, but ... > > Side note: I suspect it should be marked for stable, but it's going to > be basically impossible to back-port this any further than 4.7 or > something where we made each pts mount its own proper filesystem. The > code before that was a mess, and this is never going to work right in > old kernels. Yeah, it would be nice if this could make it into stable at least and of course into 4.13 but I take it that's a given anyway. > > Of course, TIOCGPTPEER itself is much more recent than that and was > done in this merge window, so hopefully you haven't backported it and > expect this all to work in some older kernel? No, I haven't backported anything and we never intended to. Serge, Stéphane, and I were very careful to not blindly rely on anything that recent and - imho - security sensitive in our api. I see this more as a "tech-preview" until this has seen some decent userspace testing. Even if the kernel side seems fine now a lot of the userspace pty api is currently using path-based operations instead of operations on the pty fds themselves. This is tricky and error-prone when sending around pty fds between different namespaces as one can see from the ttyname{_r}() example above. Christian