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:	Wed, 25 Sep 2013 20:11:46 +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 Tue, 24 Sep 2013, Ingo Molnar wrote:
> 
> > Ok, this variant looks pretty good, modulo testing. I'd do:
> >
> >   s/check_preemption/check_preemption_disabled
> >
> > but that's a minor detail.
> 
> Sure.
> 
> > > +config DEBUG_THIS_CPU_OPERATIONS
> > > +	bool "Debug __this_cpu operations"
> > > +	depends on DEBUG_PREEMPT
> > > +	default n
> > > +	help
> > > +	  Enables preemption checks for __this_cpu macros. These
> > > +	  are macros to generate single instruction operations on
> > > +	  per cpu data. The option only affects the __this_cpu variant
> > > +	  which is used when fallback to multiple instructions without
> > > +	  other synchronization is possible. A verification is then
> > > +	  done to make sure that the thread cannot be preempted.
> >
> > I don't think there's a need to make this a separate preemption debug 
> > option: smp_processor_id() is really just a subset of the checks.
> 
> I think this is necessary since it seems that the discussions on how to 
> do the raw_cpu conversions may take some time. If we enable it by 
> default then there will be numerous new log messages. That way a 
> developer can enable it for working on this.

Note that for these patches to be eligible for upstream merge any extra 
warnings that trigger must be fixed, regardless of the default setting.

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.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ