From: ebiederm@xmission.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@redhat.com>
Cc: Wen Yang <wenyang@linux.alibaba.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Christian Brauner <christian@brauner.io>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] proc: add locking checks in proc_inode_is_dead
Date: Tue, 01 Dec 2020 09:06:04 -0600 [thread overview]
Message-ID: <87lfehftwj.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20201201123556.GB2700@redhat.com> (Oleg Nesterov's message of "Tue, 1 Dec 2020 13:35:56 +0100")
Oleg Nesterov <oleg@redhat.com> 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
prev parent reply other threads:[~2020-12-01 15:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-28 17:58 [PATCH] proc: add locking checks in proc_inode_is_dead Wen Yang
2020-11-28 19:01 ` Oleg Nesterov
2020-11-30 18:41 ` Eric W. Biederman
2020-12-01 12:35 ` Oleg Nesterov
2020-12-01 15:06 ` Eric W. Biederman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lfehftwj.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=adobriyan@gmail.com \
--cc=christian@brauner.io \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=wenyang@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox