linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	eric.dumazet@gmail.com, shaohua.li@intel.com, ak@linux.intel.com,
	mhocko@suse.cz, alex.shi@intel.com, efault@gmx.de,
	linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL rcu/next] RCU commits for 3.1
Date: Sat, 29 Oct 2011 11:27:10 -0700	[thread overview]
Message-ID: <20111029182710.GG6160@linux.vnet.ibm.com> (raw)
In-Reply-To: <4EAA14A1.5060204@cn.fujitsu.com>

On Fri, Oct 28, 2011 at 10:34:09AM +0800, Li Zefan wrote:
> >>>>
> >>>> And I cannot reproduce after merging into 3.1.  :-(
> >>>
> >>> Here's another one i just got with latest -tip:
> >>>
> >>> PM: Adding info for No Bus:vcsa2
> >>>
> >>> ===============================
> >>> [ INFO: suspicious RCU usage. ]
> >>> -------------------------------
> >>> include/linux/cgroup.h:548 suspicious rcu_dereference_check() usage!
> >>>
> >>> other info that might help us debug this:
> >>>
> >>>
> >>> rcu_scheduler_active = 1, debug_locks = 0
> >>> 1 lock held by true/655:
> >>>  #0:  (&sig->cred_guard_mutex){+.+.+.}, at: [<810d1bd7>] prepare_bprm_creds+0x27/0x70
> >>>
> >>> stack backtrace:
> >>> Pid: 655, comm: true Not tainted 3.1.0-tip-01868-g1271bd2-dirty #161079
> >>> Call Trace:
> >>>  [<81abe239>] ? printk+0x18/0x1a
> >>>  [<81064920>] lockdep_rcu_suspicious+0xc0/0xd0
> >>>  [<8108aa02>] perf_event_enable_on_exec+0x1d2/0x1e0
> >>>  [<81063764>] ? __lock_release+0x54/0xb0
> >>>  [<8108cca8>] perf_event_comm+0x18/0x60
> >>>  [<810d1abd>] ? set_task_comm+0x5d/0x80
> 
> void set_task_comm(struct task_struct *tsk, char *buf)
> {
>         task_lock(tsk);
> 	...
>         task_unlock(tsk);
>         perf_event_comm(tsk);
> }
> 
> see, perf_event_comm() is called after releasing task_lock.
> 
> perf_event_comm()
>   perf_event_enable_on_exec()
>     perf_cgroup_sched_out()
>       perf_cgroup_from_task()
>         task_subsys_state()
> 
> No proper lock is held, hence the warning.

Thank you for the analysis.  Does the following patch fix this problem?

							Thanx, Paul

------------------------------------------------------------------------

fs: Add RCU protection in set_task_comm()

Running "perf stat true" results in the following RCU-lockdep splat:

===============================
[ INFO: suspicious RCU usage. ]
-------------------------------
include/linux/cgroup.h:548 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
1 lock held by true/655:
#0:  (&sig->cred_guard_mutex){+.+.+.}, at: [<810d1bd7>] prepare_bprm_creds+0x27/0x70

stack backtrace:
Pid: 655, comm: true Not tainted 3.1.0-tip-01868-g1271bd2-dirty #161079
Call Trace:
[<81abe239>] ? printk+0x18/0x1a
[<81064920>] lockdep_rcu_suspicious+0xc0/0xd0
[<8108aa02>] perf_event_enable_on_exec+0x1d2/0x1e0
[<81063764>] ? __lock_release+0x54/0xb0
[<8108cca8>] perf_event_comm+0x18/0x60
[<810d1abd>] ? set_task_comm+0x5d/0x80
[<81af622d>] ? _raw_spin_unlock+0x1d/0x40
[<810d1ac4>] set_task_comm+0x64/0x80
[<810d25fd>] setup_new_exec+0xbd/0x1d0
[<810d1b61>] ? flush_old_exec+0x81/0xa0
[<8110753e>] load_elf_binary+0x28e/0xa00
[<810d2101>] ? search_binary_handler+0xd1/0x1d0
[<81063764>] ? __lock_release+0x54/0xb0
[<811072b0>] ? load_elf_library+0x260/0x260
[<810d2108>] search_binary_handler+0xd8/0x1d0
[<810d2060>] ? search_binary_handler+0x30/0x1d0
[<810d242f>] do_execve_common+0x22f/0x2a0
[<810d24b2>] do_execve+0x12/0x20
[<81009592>] sys_execve+0x32/0x70
[<81af7752>] ptregs_execve+0x12/0x20
[<81af76d4>] ? sysenter_do_call+0x12/0x36

Li Zefan noted that this is due to set_task_comm() dropping the task
lock before invoking perf_event_comm(), which could in fact result in
the task being freed up before perf_event_comm() completed tracing in
the case where one task invokes set_task_comm() on another task -- which
actually does occur via comm_write(), which can be invoked via /proc.

This commit fixes this problem by entering an RCU read-side critical
section before acquiring the task lock and exiting this critical section
after perf_event_comm() returns.

Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/fs/exec.c b/fs/exec.c
index 25dcbe5..fb928d3 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1056,6 +1056,7 @@ EXPORT_SYMBOL_GPL(get_task_comm);
 
 void set_task_comm(struct task_struct *tsk, char *buf)
 {
+	rcu_read_lock(); /* protect task pointer through tracing. */
 	task_lock(tsk);
 
 	/*
@@ -1069,6 +1070,7 @@ void set_task_comm(struct task_struct *tsk, char *buf)
 	strlcpy(tsk->comm, buf, sizeof(tsk->comm));
 	task_unlock(tsk);
 	perf_event_comm(tsk);
+	rcu_read_unlock();
 }
 
 int flush_old_exec(struct linux_binprm * bprm)


  reply	other threads:[~2011-10-30  8:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110930204503.GA32687@linux.vnet.ibm.com>
     [not found] ` <20111001152514.GA16930@elte.hu>
     [not found]   ` <20111003055302.GA23527@elte.hu>
     [not found]     ` <20111003161335.GA2403@linux.vnet.ibm.com>
2011-10-04  7:46       ` [GIT PULL rcu/next] RCU commits for 3.1 Ingo Molnar
2011-10-24 10:05         ` Paul E. McKenney
2011-10-24 11:48           ` Paul E. McKenney
2011-10-26 20:30             ` Ingo Molnar
2011-10-27  7:59               ` Paul E. McKenney
2011-10-27  8:00                 ` Ingo Molnar
2011-10-28  2:34                   ` Li Zefan
2011-10-29 18:27                     ` Paul E. McKenney [this message]
2011-10-31  8:09                       ` Li Zefan
2011-10-31  9:32                         ` Paul E. McKenney
2011-11-01  2:37                           ` Li Zefan
2011-11-02 19:23                             ` Paul E. McKenney
2011-11-02 19:55                               ` Stephane Eranian
2011-11-03 12:50                             ` Stephane Eranian
2011-11-04  8:44                               ` Li Zefan
2011-11-04  9:02                                 ` Stephane Eranian
2011-11-07 14:24                                   ` Stephane Eranian
2011-11-07 14:41                                     ` Eric Dumazet
2011-11-07 14:44                                       ` Stephane Eranian
2011-11-07 15:15                             ` Peter Zijlstra
2011-11-07 16:16                               ` Stephane Eranian
2011-11-07 16:35                                 ` Peter Zijlstra
2011-11-07 16:56                                   ` Paul E. McKenney
2011-11-07 17:09                                     ` Peter Zijlstra
2011-11-07 17:55                                       ` Paul E. McKenney
2011-11-08 13:10                                         ` Stephane Eranian
2011-11-07 17:11                                     ` Peter Zijlstra
2011-11-07 17:12                                     ` Stephane Eranian
2011-11-07 17:26                                       ` Peter Zijlstra
2011-11-07 17:50                                         ` Stephane Eranian
2011-11-07 17:53                                         ` Paul E. McKenney
2011-11-07 17:53                                       ` Paul E. McKenney

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=20111029182710.GG6160@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=ak@linux.intel.com \
    --cc=alex.shi@intel.com \
    --cc=efault@gmx.de \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mhocko@suse.cz \
    --cc=mingo@elte.hu \
    --cc=shaohua.li@intel.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;
as well as URLs for NNTP newsgroup(s).