[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121024182111.GA2340@swordfish>
Date: Wed, 24 Oct 2012 11:21:11 -0700
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Dave Jones <davej@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Serge Hallyn <serge.hallyn@...onical.com>,
linux-kernel@...r.kernel.org
Subject: Re: lots of suspicious RCU traces
On (10/24/12 20:06), Oleg Nesterov wrote:
> On 10/24, Sergey Senozhatsky wrote:
> >
> > small question,
> >
> > ptrace_notify() and forward calls are able to both indirectly and directly call schedule(),
> > /* direct call from ptrace_stop()*/,
> > should, in this case, rcu_user_enter() be called before tracehook_report_syscall_exit(regs, step)
> > and ptrace chain?
>
> Well, I don't really understand this magic... but why?
>
My understanding is (I may be wrong) that we can schedule() from ptrace chain to
some arbitrary task, which will continue its execution from the point where RCU assumes
CPU as not idle, while CPU in fact still in idle state -- no one said rcu_idle_exit()
(or similar) prior to schedule() call.
if so, does the same apply to in_user?
-ss
> Until we return to user-mode this CPU should be in "in_user = false" state.
>
> I am not sure I understand how it is guaranteed that rcu_user_exit() was
> called... probably TIF_NOHZ should trigger the slow path and ensure that
> syscall_trace_enter()->rcu_user_exit() will be called.
>
> Oleg.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists