linux-kernel - Re: [RFC][PATCH 2/5] mm: Switch mod_state() to __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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 Sep 2011 09:51:06 -0500 (CDT)
From:	Christoph Lameter <cl@...two.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Christoph Lameter <cl@...ux.com>, Tejun Heo <htejun@...il.com>
Subject: Re: [RFC][PATCH 2/5] mm: Switch mod_state() to __this_cpu_read()

On Tue, 20 Sep 2011, Thomas Gleixner wrote:

> > Why would there be a warning triggered? this_cpu_read should take care of
> > disabling preemption for the read if needed. In fact the fallback case
> > does do exactly that.
>
> And what exactly is the purpose of having a preempt_disable()/enable()
> pair in this_cpu_read()?

It avoids a read from one cpu of another processors per cpu area. In the
fallback case the processor has to calculate the per cpu address and then
retrieve data from the calculated address. The process can be migrated
between calculation of the address and the actual fetch.

The more severe cases are the RMV operations like this_cpu_inc.

> functions we should add a more sensible debug interface like:
>
>   debug_check_percpu_access()
>
> and the per cpu sections which require protection over a series (1
> .. N) of this_cpu_* operations want to have
>
>   this_cpu_start()
>   this_cpu_end()
>
> or similar annotations around them.
>
> This allows us to do proper analysis of this_cpu usage and makes the
> code understandable.

Not sure what you want to check in this_cpu_xx operations. Why could
there be issues with this_cpu_xx operations?

I see that __this_cpu_xx operations may not work as intended in
preemptable contexts and there we could have more changes.

this_cpu ops are single instructions that do not guarantee any consistency
with other this_cpu_ops. If you want consistency (same per cpu area data)
then preemption needs to be disabled.

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