public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Steven Rostedt <srostedt@redhat.com>,
	containers@lists.osdl.org, Ingo Molnar <mingo@elte.hu>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/3] ftrace: use struct pid
Date: Thu, 04 Dec 2008 07:12:27 -0800	[thread overview]
Message-ID: <1228403547.13111.73.camel@nimitz> (raw)
In-Reply-To: <m1prk8t5xr.fsf@frodo.ebiederm.org>

On Thu, 2008-12-04 at 05:40 -0800, Eric W. Biederman wrote:
> Dave Hansen <dave@linux.vnet.ibm.com> writes:
> > On Thu, 2008-12-04 at 04:56 -0800, Dave Hansen wrote:
> >> On Thu, 2008-12-04 at 04:42 -0800, Eric W. Biederman wrote:
> >> > 
> >> > > +static void clear_ftrace_pid_task(struct pid **pid)
> >> > > +{
> >> > > +     struct task_struct *p;
> >> > > +
> >> >         rcu_read_lock();
> >> > 
> >> > > +     do_each_pid_task(*pid, PIDTYPE_PID, p) {
> >> > > +             clear_tsk_trace_trace(p);
> >> > > +     } while_each_pid_task(*pid, PIDTYPE_PID, p);
> >> >         rcu_read_unlock()
> >> > 
> >> > > +     put_pid(*pid);
> >> > > +
> >> > > +     *pid = NULL;
> >> > > +}
> >> 
> >> Could we get away with sticking the rcu_read_{un}lock() inside those
> >> macros?  Those are going to get used in pretty high level code and we're
> >> allowed to nest rcu_read_lock().  No danger of deadlocks or lock
> >> inversions.
> >
> > Why don't any of the other users of do_each_pid_task() use
> > rcu_read_lock()?  They all seem to be under read_lock(&tasklist_lock)
> > (except one is under a write lock of the same).
> 
> We probably should.  Historically read_lock(&tasklist_lock) implies
> rcu_read_lock().

You mean because the current task can't go through a quiescent period
until it hits userspace, and we can't go to userspace while holding
read_lock()?  Nah, that's not subtle. ;)

> And the tasklist lock is what we hold when it is safe.
> 
> But if you look at find_vpid we should be holding just the rcu lock there.

Yup, I see it there.

So, any reason not to do this?  Brown-bag compile tested.

Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>

---

 linux-2.6.git-dave/include/linux/pid.h |    2 ++
 1 file changed, 2 insertions(+)

diff -puN include/linux/pid.h~put-rcu-ops-in-do_each_pid_task include/linux/pid.h
--- linux-2.6.git/include/linux/pid.h~put-rcu-ops-in-do_each_pid_task	2008-12-04 06:03:09.000000000 -0800
+++ linux-2.6.git-dave/include/linux/pid.h	2008-12-04 06:19:35.000000000 -0800
@@ -147,6 +147,7 @@ pid_t pid_vnr(struct pid *pid);
 #define do_each_pid_task(pid, type, task)				\
 	do {								\
 		struct hlist_node *pos___;				\
+		rcu_read_lock();					\
 		if (pid != NULL)					\
 			hlist_for_each_entry_rcu((task), pos___,	\
 				&pid->tasks[type], pids[type].node) {
@@ -159,6 +160,7 @@ pid_t pid_vnr(struct pid *pid);
 				if (type == PIDTYPE_PID)		\
 					break;				\
 			}						\
+		rcu_read_unlock();					\
 	} while (0)
 
 #define do_each_pid_thread(pid, type, task)				\
_

-- Dave


  reply	other threads:[~2008-12-04 15:13 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-04  5:26 [PATCH 0/3] ftrace: clean ups for tip Steven Rostedt
2008-12-04  5:26 ` [PATCH 1/3] fix the do_each_pid_task macro Steven Rostedt
2008-12-04  5:26 ` [PATCH 2/3] ftrace: use struct pid Steven Rostedt
2008-12-04 12:42   ` Eric W. Biederman
2008-12-04 12:56     ` Dave Hansen
2008-12-04 13:07       ` Dave Hansen
2008-12-04 13:40         ` Eric W. Biederman
2008-12-04 15:12           ` Dave Hansen [this message]
2008-12-04 15:35             ` Steven Rostedt
2008-12-04 15:41           ` Dave Hansen
2008-12-04 15:44             ` Steven Rostedt
2008-12-04 14:29         ` Steven Rostedt
2008-12-05  3:17         ` Dipankar Sarma
2008-12-04 12:55   ` Eric W. Biederman
2008-12-04 14:23     ` Steven Rostedt
2008-12-04 14:32       ` Eric W. Biederman
2008-12-04 16:22         ` Sukadev Bhattiprolu
2008-12-04  5:26 ` [PATCH 3/3] ftrace: add ability to only trace swapper tasks Steven Rostedt
2008-12-04  5:34   ` Wang Liming
2008-12-04  5:50     ` Wang Liming
2008-12-04  8:06   ` Ingo Molnar
2008-12-04  8:18   ` Andrew Morton
2008-12-04  9:10     ` Ingo Molnar
2008-12-04 12:59       ` Eric W. Biederman
2008-12-04 14:46         ` Steven Rostedt
2008-12-04 20:41           ` Eric W. Biederman
2008-12-04 20:57             ` Steven Rostedt
2008-12-04 21:43               ` Eric W. Biederman
2008-12-04 21:56                 ` Steven Rostedt
2008-12-05  7:43                   ` Eric W. Biederman
2008-12-05 12:23                     ` Steven Rostedt
2008-12-05 16:35                       ` Eric W. Biederman
2008-12-05  4:30                 ` [PATCH] ftrace: use init_struct_pid as swapper pid Steven Rostedt
2008-12-05 13:51                   ` Ingo Molnar
2008-12-04 15:36         ` [PATCH 3/3] ftrace: add ability to only trace swapper tasks Ingo Molnar
2008-12-04 15:47           ` Steven Rostedt
2008-12-04 13:12     ` Steven Rostedt
2008-12-04 13:52       ` Eric W. Biederman
2008-12-04 12:54   ` Eric W. Biederman
2008-12-04 14:57     ` Steven Rostedt
2008-12-04  8:10 ` [PATCH 0/3] ftrace: clean ups for tip Ingo Molnar
2008-12-04  8:30   ` [PATCH] tracing: fix typo Ingo Molnar
2008-12-04  8:34     ` [PATCH] tracing: fix typo and missing inline function Ingo Molnar
2008-12-04 13:16       ` Steven Rostedt
2008-12-04 15:35         ` Ingo Molnar

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=1228403547.13111.73.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=srostedt@redhat.com \
    --cc=sukadev@linux.vnet.ibm.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