From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Michal Hocko <mhocko@suse.cz>, Sergey Dyasly <dserrg@gmail.com>,
Sha Zhengju <handai.szj@taobao.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] proc: simplify proc_task_readdir/first_tid paths
Date: Wed, 29 May 2013 15:39:30 +0200 [thread overview]
Message-ID: <20130529133930.GB5741@redhat.com> (raw)
In-Reply-To: <87ppwa1jn0.fsf@xmission.com>
On 05/28, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > proc_task_readdir() does not really need "leader", first_tid()
> > has to revalidate it anyway. Just pass proc_pid(inode) to
> > first_tid() instead, it can do pid_task(PIDTYPE_PID) itself
> > and read ->group_leader only if necessary.
> >
> > Note: I am not sure proc_task_readdir() really needs the initial
> > -ENOENT check, but this is what the current code does.
>
> This looks like a nice cleanup.
>
> We would need either -ENOENT or a return of 0 and an empty directory at
> the least. We need the check so that empty directories don't have "."
> and ".." entries.
And this is not clear to me...
Why the empty "." + ".." dir is bad if the task(s) has gone away after
opendir?
> > if (tid && (nr > 0)) {
> > pos = find_task_by_pid_ns(tid, ns);
> > - if (pos && (pos->group_leader == leader))
> > + if (pos && same_thread_group(pos, task))
>
> Sigh this reminds me we need to figure out how to kill task->pid and
> task->tgid,
Yeah.
> which I assume means fixing same_thread_group.
Now that ->signal can't go away before task_struct, we can make it
static inline
int same_thread_group(struct task_struct *p1, struct task_struct *p2)
{
return p1->signal == p2->signal;
}
> > + if (!pid_task(proc_pid(inode), PIDTYPE_PID))
> > + return -ENOENT;
>
> Strictly speaking this call to pid_task needs to be in a rcu critical
> section.
Argh, thanks.
we do not really need rcu, we are not going to dereference this pointer,
but we should make __rcu_dereference_check() happy...
I'll change this... but once again, can't we simply remove this check?
While you are here. Could you explain the ->d_inode check in
proc_fill_cache() ? The code _looks_ wrong,
if (!child || IS_ERR(child) || !child->d_inode)
goto end_instantiate;
If d_inode == NULL, who does dput() ?
OTOH, if we ensure d_inode != NULL, why do we check "if (inode)" after
inode = child->d_inode ?
IOW, it seems that this check should be simply removed?
Oleg.
next prev parent reply other threads:[~2013-05-29 13:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-27 20:27 [PATCH 0/3] proc: first_tid() fix/cleanup Oleg Nesterov
2013-05-27 20:28 ` [PATCH 1/3] proc: first_tid: fix the potential use-after-free Oleg Nesterov
2013-05-29 4:08 ` Eric W. Biederman
2013-05-29 12:30 ` Oleg Nesterov
2013-05-27 20:28 ` [PATCH 2/3] proc: change first_tid() to use while_each_thread() Oleg Nesterov
2013-05-27 20:28 ` [PATCH 3/3] proc: simplify proc_task_readdir/first_tid paths Oleg Nesterov
2013-05-29 4:42 ` Eric W. Biederman
2013-05-29 13:39 ` Oleg Nesterov [this message]
2013-05-29 20:38 ` Eric W. Biederman
2013-05-31 16:38 ` Oleg Nesterov
2013-05-31 18:12 ` Eric W. Biederman
2013-05-31 18:34 ` Oleg Nesterov
2013-05-29 5:22 ` [PATCH 0/3] proc: first_tid() fix/cleanup Eric W. Biederman
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=20130529133930.GB5741@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dserrg@gmail.com \
--cc=ebiederm@xmission.com \
--cc=handai.szj@taobao.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.cz \
--cc=rientjes@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.