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]

Date:	Tue, 20 Sep 2011 14:03:05 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Christoph Lameter <cl@...two.org>, Valdis.Kletnieks@...edu,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][PATCH 0/5] Introduce checks for preemptable code for
 this_cpu_read/write()

On Tue, 2011-09-20 at 13:25 -0400, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@...dmis.org) wrote:
> > On Tue, 2011-09-20 at 19:09 +0200, Peter Zijlstra wrote:
> > > On Tue, 2011-09-20 at 12:56 -0400, Steven Rostedt wrote:
> > > > random_cpu_*()    // Thomas's idea
> > > 
> > > I like this one best..
> > 
> > I like it too, but not really the most appropriate.
> > 
> > > 
> > > But you forgot do deal with the irqsafe_cpu() crap, that's the same
> > > brainfart as this_cpu() but more expensive because it frobs IRQ state.
> > 
> > But irqsafe_cpu_*() doesn't really have any real meaning to me. That is
> > something when I see it, I go and read the comments about it. It doesn't
> > contain "this_cpu" which is something that seems to explain what it is,
> > even though the obvious is not what it is.
> 
> Throwing ideas from the IRC discussion into the mix (Paul McKenney and I
> came up with it at the same time):
> 
> preempt_protected_percpu_*()
> irq_protected_percpu_*()
> 
> Seems to be quite self-explanatory.
> 

For use where the per_cpu data is protected with preemption disabled?
But isn't that the default case? Why make it hard to type for when you
should use it in the normal case.

It should be hard to type when it is a hack. As I recommended on IRC, we
probably should have it as:

use_this_if_you_really_do_not_care_what_cpu_you_are_on_but_are_anal_about_performance_cpu_*()

1) it is very self descriptive.
2) it would limit the usage as people wont like to have it in their
code ;)

-- Steve


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