Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751171AbdHXB0A (ORCPT ); Wed, 23 Aug 2017 21:26:00 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:59079 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750715AbdHXBZ6 (ORCPT ); Wed, 23 Aug 2017 21:25:58 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: Stefan Lippers-Hollmann , Christian Brauner , Christian Brauner , Linux Kernel Mailing List , "Serge E. Hallyn" , Al Viro , Thorsten Leemhuis References: <20170816171211.4021-1-christian.brauner@ubuntu.com> <20170816194805.hnof3aqiqykwki7p@gmail.com> <87pobvruzt.fsf@xmission.com> <87ziazqdfr.fsf@xmission.com> <20170824022436.44adb497@mir> Date: Wed, 23 Aug 2017 20:25:37 -0500 In-Reply-To: (Linus Torvalds's message of "Wed, 23 Aug 2017 17:42:05 -0700") Message-ID: <87378hhi3y.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dkgu6-0000br-Gs;;;mid=<87378hhi3y.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.200.44;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1839UU5A2jtMWWc+zKzPzH30KtcqFPE/p4= X-SA-Exim-Connect-IP: 67.3.200.44 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 5422 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.9 (0.1%), b_tie_ro: 1.98 (0.0%), parse: 1.09 (0.0%), extract_message_metadata: 18 (0.3%), get_uri_detail_list: 2.0 (0.0%), tests_pri_-1000: 5 (0.1%), tests_pri_-950: 1.12 (0.0%), tests_pri_-900: 1.00 (0.0%), tests_pri_-400: 22 (0.4%), check_bayes: 21 (0.4%), b_tokenize: 7 (0.1%), b_tok_get_all: 7 (0.1%), b_comp_prob: 2.3 (0.0%), b_tok_touch_all: 2.8 (0.1%), b_finish: 0.63 (0.0%), tests_pri_0: 215 (4.0%), check_dkim_signature: 0.46 (0.0%), check_dkim_adsp: 10 (0.2%), tests_pri_500: 5153 (95.0%), poll_dns_idle: 5146 (94.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1898 Lines: 50 Linus Torvalds writes: > On Wed, Aug 23, 2017 at 5:24 PM, Stefan Lippers-Hollmann wrote: >> >> This patch[1] as part of 4.13-rc6 (up to, at least, >> v4.13-rc6-45-g6470812e2226) introduces a regression for me when using >> pbuilder 0.228.7[2] (a helper to build Debian packages in a chroot and >> to create and update its chroots) when trying to umount /dev/ptmx (inside >> the chroot) on Debian/ unstable (full log and pbuilder configuration >> file[3] attached). >> >> [...] >> Setting up build-essential (12.3) ... >> Processing triggers for libc-bin (2.24-15) ... >> I: unmounting dev/ptmx filesystem >> W: Could not unmount dev/ptmx: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy > > Yes, that patch definitely keeps a reference to the pts filesystem > around while a pty is open. > > We always used to do that, but we did it differently - we would keep > the 's_active' count elevated so that the superblock never went away, > even after it was unmounted. > > Now it does an actual mntget(), and that makes umount _notice_ that > the filesystem is still busy. > > How annoying. > > Because in a very real sehse the filesystem really is busy, but we > used to hide it (perhaps on purpose - it's possible that people hit > this problem before). > > Let me try to think about alteratives. Clearly this is a regression > and I need to fix it, I just need to figure out _how_. The new behavior is that when we open ptmx we cache a path the slave pty. If instead of caching that path we call devpts_acquire to compute the mount point of the dentry we should be able to skip caching mountpoint in ptmx_open. That should trivially remove the regression. We will have to fail if someone crazy unmounted the devpts filesystem before we ask for the peer file descriptor. But otherwise the behavior should be exactly the same. Eric