linux-kernel - Re: [pchecks v2 2/2] percpu: Add preemption checks to __this

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]

Date:	Thu, 3 Oct 2013 09:21:00 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Tejun Heo <tj@...nel.org>, akpm@...uxfoundation.org,
	linux-arch@...r.kernel.org, Steven Rostedt <srostedt@...hat.com>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [pchecks v2 2/2] percpu: Add preemption checks to __this_cpu ops


* Christoph Lameter <cl@...ux.com> wrote:

> On Sat, 28 Sep 2013, Ingo Molnar wrote:
> 
> >
> > * Christoph Lameter <cl@...ux.com> wrote:
> >
> > > > The blind __this_cpu conversions without proper preempt debugging 
> > > > cannot continue without first fixing all the fallout of the 
> > > > missing debug checks to begin with.
> > >
> > > That will take some time as the feedback from the other patchset 
> > > suggests.
> >
> > That's the reason why we insisted on __this_cpu*() primitives growing 
> > these essential debug checks early on - which you resisted. I had to 
> > bring out NAKs for you to see sense and start fixing the mess already 
> > - next time around I'll probably have to NAK your changes earlier to 
> > prevent such mishaps.
> 
> I pointed out the issues that would have to be addressed when the 
> brought up the issue. It seemed that Steven was working on it, I fixed 
> some of the problems that he mentioned and then waited. Seems that 
> nothing was happening on the issue then. Guess it was not that important 
> to you. [...]

It was important to me and other maintainers as well back then and today 
as well, as me and others complained about it out numerous times.

What we didn't do was to outright NAK your naked __this_cpu changes 
straight away and thus prevent them from getting upstream.

I can fix that omission easily: consider all your __this_cpu* patches 
NAK-ed by me until the (trivial) preemption debug checks are upstream 
worthy:

  - tested
  - complete
  - don't produce false warnings when enabled.

Thanks,

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