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 11:46:10 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Christoph Lameter <cl@...two.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC][PATCH 0/5] Introduce checks for preemptable code for
	this_cpu_read/write()

* Steven Rostedt (rostedt@...dmis.org) wrote:
> [ Added Mathieu as I've been discussing this with him on IRC ]
[...]
> My suggestion is to nuke the __this_cpu*() functions and have them
> called this_cpu*(). And change the locations that allow for preemption
> enabled to be called preemptsafe_cpu_*() just like the irqsafe_cpu*()
> are used.
> 
> Thoughts?

I fully agreed with this proposal.

this_cpu_*() should be a sane default, which is cases that require
preemption to be disabled. Warning about use without preemption disabled
is important, because most users will _assume_ that they stay on the
same CPU across multiple calls.

preemptsafe_cpu_*() is an optimisation made for those who know that
they don't care about having consistent view of the variables across
multiple operations, e.g. statistics, or deal with this explicitly, like
SLUB. Typical use require either add_return or cmpxchg for validation.

In the past, we used to have something like raw_smp_processor_id()
though, for sites where racy use does not matter. So probably having a
raw_this_cpu_*() that behaves like "this_cpu_*()" proposed here, but
does not check for preemption disabled would also be useful.

Best regards,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/