[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000001417eac34d5-43f9e4c6-661b-4329-ab17-4b8a044922c8-000000@email.amazonses.com>
Date: Thu, 3 Oct 2013 14:15:17 +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:
> 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.
Yes there were some complaints and in discussions about what to do. I
suggested how this could be addressed. But no patches showed up and there
were always other more pressing things. Especially since this is a minor
issue related to CONFIG_PREEMPT which seems to be not in use in the
kernels that I see in HPC, FIS and the industry at large.
> 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.
Not sure what tests you will like to see run and if it is even possible to
test all possible kernel runtime configurations. You seem to have some
setup to do some testing along these lines I believe?
These two patches will allow this testing to be done. And I do not see any
mention of technical issues with the code. Once these patches are merged
then I will post an updated series of patches that use raw_cpu_ops for the
places where this patch triggers and we can then discuss how to address
these issues in each of the cases.
Having these two patches merged will mean that other can join in an
reproduce test as well discover more instances where the preempt checks
trigger. There is no harm in merging these.
--
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/
Powered by blists - more mailing lists