All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: linux-kernel@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Michal Hocko <mhocko@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Elena Reshetova <elena.reshetova@intel.com>,
	Christian Kellner <christian@kellner.me>,
	Roman Gushchin <guro@fb.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Aleksa Sarai <cyphar@cyphar.com>,
	"Dmitry V. Levin" <ldv@altlinux.org>,
	linux-kselftest@vger.kernel.org, Jann Horn <jannh@google.com>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH 1/2] pidfd: verify task is alive when printing fdinfo
Date: Tue, 15 Oct 2019 16:56:47 +0200	[thread overview]
Message-ID: <20191015145646.72eqrw6j52ehvfn2@wittgenstein> (raw)
In-Reply-To: <20191015144356.GA16978@redhat.com>

On Tue, Oct 15, 2019 at 04:43:57PM +0200, Oleg Nesterov wrote:
> On 10/15, Christian Brauner wrote:
> >
> > +static inline bool task_alive(struct pid *pid)
> > +{
> > +	bool alive = true;
> > +
> > +	rcu_read_lock();
> > +	if (!pid_task(pid, PIDTYPE_PID))
> > +		alive = false;
> > +	rcu_read_unlock();
> > +
> > +	return alive;
> > +}
> 
> Well, the usage of rcu_read_lock/unlock looks confusing to me...
> 
> I mean, this helper does not need rcu lock at all. Except
> rcu_dereference_check() will complain.

Yep, I think we have another codepath were the rcu locks might be purely
cosmetic so I thought it's not a big deal (see below).

> 
> 	static inline bool task_alive(struct pid *pid)
> 	{
> 		bool alive;
> 
> 		/* shut up rcu_dereference_check() */
> 		rcu_lock_acquire(&rcu_lock_map);
> 		alive = !!pid_task(pid, PIDTYPE_PID));
> 		rcu_lock_release(&rcu_lock_map);
> 
> 		return alive;
> 	}
> 
> looks more clear imo.
> 
> But in fact I'd suggest to simply use !hlist_empty(&pid->tasks[PIDTYPE_PID])
> in pidfd_show_fdinfo() and do not add a new helper.

Sounds good to me. But can't we then just do something similar just with
!hlist_empty(&pid->tasks[PIDTYPE_TGID])

in v5.4-rc3:kernel/pid.c:pidfd_open():514-517 ?

or would this be problematic because of de_thread()?

Thanks!
Christian

  reply	other threads:[~2019-10-15 14:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-15 14:13 [PATCH 1/2] pidfd: verify task is alive when printing fdinfo Christian Brauner
2019-10-15 14:13 ` [PATCH 2/2] test: verify fdinfo for pidfd of reaped process Christian Brauner
2019-10-16 12:07   ` Christian Kellner
2019-10-15 14:43 ` [PATCH 1/2] pidfd: verify task is alive when printing fdinfo Oleg Nesterov
2019-10-15 14:56   ` Christian Brauner [this message]
2019-10-15 15:43     ` Oleg Nesterov
2019-10-16 15:36 ` [PATCH v2 1/5] " Christian Brauner
2019-10-16 15:36   ` [PATCH v2 2/5] test: verify fdinfo for pidfd of reaped process Christian Brauner
2019-10-16 15:36   ` [PATCH v2 3/5] pid: use task_alive() in __change_pid() Christian Brauner
2019-10-16 15:36   ` [PATCH v2 4/5] exit: use task_alive() in do_wait() Christian Brauner
2019-10-16 15:36   ` [PATCH v2 5/5] pid: use task_alive() in pidfd_open() Christian Brauner
2019-10-16 16:24   ` [PATCH v2 1/5] pidfd: verify task is alive when printing fdinfo Oleg Nesterov
2019-10-16 16:31     ` Christian Brauner
2019-10-17  8:54       ` Oleg Nesterov
2019-10-17 10:18   ` [PATCH v3 1/5] pidfd: check pid has attached task in fdinfo Christian Brauner
2019-10-17 10:18     ` [PATCH v3 2/5] test: verify fdinfo for pidfd of reaped process Christian Brauner
2019-10-17 10:18     ` [PATCH v3 3/5] pid: use pid_has_task() in __change_pid() Christian Brauner
2019-10-17 10:18     ` [PATCH v3 4/5] exit: use pid_has_task() in do_wait() Christian Brauner
2019-10-17 10:18     ` [PATCH v3 5/5] pid: use pid_has_task() in pidfd_open() Christian Brauner
2019-10-18 15:05     ` [PATCH v3 1/5] pidfd: check pid has attached task in fdinfo Christian Brauner

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=20191015145646.72eqrw6j52ehvfn2@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=christian@kellner.me \
    --cc=cyphar@cyphar.com \
    --cc=elena.reshetova@intel.com \
    --cc=guro@fb.com \
    --cc=jannh@google.com \
    --cc=ldv@altlinux.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    /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.