Messages in this thread | | | Date | Tue, 20 Sep 2011 10:03:18 -0500 (CDT) | From | Christoph Lameter <> | Subject | Re: [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.
| |