linux-kernel - Re: [patch] x86, mm: pass in 'total' to __copy_from_user

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]

Message-ID: <20090228092450.3ded2db5@infradead.org>
Date:	Sat, 28 Feb 2009 09:24:50 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Nick Piggin <nickpiggin@...oo.com.au>,
	Salman Qazi <sqazi@...gle.com>, davem@...emloft.net,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>
Subject: Re: [patch] x86, mm: pass in 'total' to __copy_from_user_*nocache()

On Sat, 28 Feb 2009 09:16:21 -0800 (PST)
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> 
> 
> On Sat, 28 Feb 2009, Ingo Molnar wrote:
> > 
> > Can you suggest some other workload that should show sensitivity 
> > to this detail too? Like a simple write() loop of non-4K-sized 
> > files or so?
> 
> I bet you can find it, but I also suspect that it will depend quite a
> bit on the microarchitecture. What does 'movntq' actually _do_ on
> different CPU's (bypass L1 or L2 or just turn the L1 cache policy to
> "write through and invalidate")? 

Afaik it's like a cache flush followed by the equivalent of a WC store

> How expensive is the sfence when
> there are still stores in the write buffer? Does 'movqnt' even use
> the write buffer for cached stores, or is doing some special path the
> the last-level cache?

it's usually like a WC store
>
> If you want to be really subtle, ask questions like what are the 
> implications for last-level caches that are inclusive? The last-level 
> cache would take not just the new write, but it also has logic to
> make sure that it's a superset of the inner caches, so what does that
> do to replacement policy for that cache? Or does it cause
> invalidations in the inner caches?

it invalidates all caches in the hierarchy

afaik this is what Intel cpus do; but I also thought this behavior was
quite architectural as well...


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/