linux-kernel - Re: Buggy IPI and MTRR code on low memory

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, 28 Jan 2009 16:23:32 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	mingo@...e.hu, tglx@...utronix.de, peterz@...radead.org,
	arjan@...radead.org, rusty@...tcorp.com.au, jens.axboe@...cle.com
Subject: Re: Buggy IPI and MTRR code on low memory


On Wed, 28 Jan 2009, Andrew Morton wrote:

> On Wed, 28 Jan 2009 13:12:02 -0800
> Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> > Thought: do we need to do the kmalloc at all?  Perhaps we can instead
> > use a statically allocated per-cpu call_single_data local to
> > kernel/smp.c?  It would need a spinlock or something to protect it...
> 
> (not a spinlock - get_cpu_var/put_cpu_var will suffice)

Is that enough?

The calling IPIs may process the data after smp_call_function is made. 
What happens if two smp_call_functions are executed one after the other? 
The second one may corrupt the data if the IPI function has not executed 
yet.

We may still need that "RELEASE" flag for that case.

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