lkml.org 
[lkml]   [2011]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 0/5] Introduce checks for preemptable code for this_cpu_read/write()
On Tue, 20 Sep 2011, Thomas Gleixner wrote:

> On Mon, 19 Sep 2011, Steven Rostedt wrote:
> > On Mon, 2011-09-19 at 19:20 -0700, Andi Kleen wrote:
> > > Steven Rostedt <rostedt@goodmis.org> writes:
> > >
> > > > I just found out that the this_cpu_*() functions do not perform the
> > > > test to see if the usage is in atomic or not. Thus, the blind
> > > > conversion of the per_cpu(*, smp_processor_id()) and the get_cpu_var()
> > > > code to this_cpu_*() introduce the regression to detect the hard
> > > > to find case where a per cpu variable is used in preempt code that
> > > > migrates and causes bugs.
>
> Just for the record. I added some this_cpu_* debug checks to my
> filesystem eating 2.6.38-rt and guess what: They trigger right away in
> the FS code and without digging deeper I'm 100% sure, that this is the
> root cause of the problems I was hunting for weeks. Thanks for wasting
> my time and racking my nerves.

this_cpu_xx is safe to use in preemptable contexts. So what does this have
to do with your FS problems?

> Can we please put that on the KS agenda? This definitely needs to be
> addressed urgently.

Well yes the misunderstanding of per cpu operations was one reason why I
proposed the discussion on the subject of esoteric kernel synchronization.
I do not think that it was accepted.



\
 
 \ /
  Last update: 2011-09-20 17:05    [W:0.112 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site