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]

Message-ID: <000001417f0b7a11-76e469b6-2d0c-4726-8611-27a2ada3e3ec-000000@email.amazonses.com>
Date:	Thu, 3 Oct 2013 15:59:22 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Ingo Molnar <mingo@...nel.org>
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

On Thu, 3 Oct 2013, Ingo Molnar wrote:

> _You_ added the facility with broken (== non-existent) preemption
> debugging for __this_cpu ops, _you_ caused Peter Zijstra and others to
> waste time due to you ignoring those requests to add debugging. Everyone
> rightfully expected _you_ to fix the problem you introduced.

Oh what __this_cpu ops was doing was clearly documented at the time it was
merged.

> And now you blame the victims of your sloppiness, that they should have
> fixed the problem you introduced?

I fix problems that others introduce into my subsystems as well. If there
is a problem then usually someone shows up with patches to address these.

> People wasting time and the kernel becoming less robust is not a minor
> issue at all.

Well then I would have expected someone to show up with patches following
through on what was discussed. I am no expert on preemption.

> As a starting point it would be fine if you tested it on your own systems
> with all relevant debugging enabled...

Ok done that.

> > These two patches will allow this testing to be done. And I do not see
> > any mention of technical issues with the code. [...]
>
> Here's the list of open technical problems:
>
>  - Lack of testing - you have not stated it whether any warnings trigger
>    with those two patches applied and debugging enabled, on your systems.

I have posted an earlier patchset which includes fixes for the warnings
that were triggered. It described the testing that was done.

>  - I pointed out in detail how your last submission was broken in several
>    places which show lack of time and care on the patch series.

This is regarding the garbled subject line in your inbox? So you want me
to fix the quilt tool now? I can just make this a single patch if that
helps?

>  - Your statement in the discussion that warnings will trigger with the
>    debug option enabled points to an obvious technical problem as well -
>    all warnings known to trigger by you should be fixed by you, as part of
>    the series.

The problem is that you raised more issues related to the fixes that I
posted. I dont think this can be handled in one patchset.
--
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/