From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C490AC64E7A for ; Tue, 1 Dec 2020 15:07:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6DA0F2080A for ; Tue, 1 Dec 2020 15:07:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391334AbgLAPHQ (ORCPT ); Tue, 1 Dec 2020 10:07:16 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:40234 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387462AbgLAPHQ (ORCPT ); Tue, 1 Dec 2020 10:07:16 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kk7Eg-006Kl5-SO; Tue, 01 Dec 2020 08:06:34 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kk7Eg-004AdG-2J; Tue, 01 Dec 2020 08:06:34 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Wen Yang , Alexey Dobriyan , Christian Brauner , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <20201128175850.19484-1-wenyang@linux.alibaba.com> <87zh2yit5u.fsf@x220.int.ebiederm.org> <20201201123556.GB2700@redhat.com> Date: Tue, 01 Dec 2020 09:06:04 -0600 In-Reply-To: <20201201123556.GB2700@redhat.com> (Oleg Nesterov's message of "Tue, 1 Dec 2020 13:35:56 +0100") Message-ID: <87lfehftwj.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1kk7Eg-004AdG-2J;;;mid=<87lfehftwj.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/oeFjxe0NXtD6hi2b0dZgnvFQeZkd65EY= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] proc: add locking checks in proc_inode_is_dead X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Oleg Nesterov writes: > On 11/30, Eric W. Biederman wrote: >> >> Ouch!!!! Oleg I just looked the introduction of proc_inode_is_dead in >> d855a4b79f49 ("proc: don't (ab)use ->group_leader in proc_task_readdir() >> paths") introduced a ``regression''. >> >> Breaking the logic introduced in 7d8952440f40 ("[PATCH] procfs: Fix >> listing of /proc/NOT_A_TGID/task") to keep those directory listings not >> showing up. > > Sorry, I don't understand... > > Do you mean that "ls /proc/pid/task" can see an empty dir? Afaics this > was possible before d855a4b79f49 too. > > Or what? Bah. Brain fart on my part. I read 7d8952440f40 too fast. I thought it was attempting to make it so that "ls /proc/tid/task/" would see an empty dir while "ls /proc/tgid/task/" would see the complete set of threads. Where tgid is the pid of the thread group leader and tid is the pid of some thread in the thread group. But 7d8952440f40 was just attempting to ensure that no thread was listed more than once in "/proc/xxx/task". My apologies for the confusion. Eric