linux-kernel - Re: [RFC][PATCH 0/5] Introduce checks for preemptable code for this_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1109201000120.8056@router.home>
Date:	Tue, 20 Sep 2011 10:03:18 -0500 (CDT)
From:	Christoph Lameter <cl@...two.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Steven Rostedt <rostedt@...dmis.org>,
	Andi Kleen <andi@...stfloor.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Christoph Lameter <cl@...ux.com>, Tejun Heo <htejun@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
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@...dmis.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.

--
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/