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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 28 Feb 2009 10:52:19 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Arjan van de Ven <arjan@...radead.org>,
	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, Ingo Molnar wrote:
> 
> OTOH, given how draconian non-temporal stores are, i'm leaning 
> towards removing them from the x86 code altogether. If it matter 
> to performance somewhere it can be reintroduced, based on really 
> well backed up numbers.

It would be interesting to see if we could instead base the decision on 
what we really do care about, namely going to do IO.

And the thing is, in this path we _do_ kind of know that. The caller 
(normally generic_perform_write) already does that whole 
balance_dirty_pages_ratelimited() thing.

So rather than passing in the "total_size" thing, we _could_ pass in 
something that is based on

 - are we O_DIRECT? If so: use uncached
 - perhaps: are we really _really_ large? If so: use uncached, we know the 
   caches aren't going to capture it.
 - are we starting writeout due to dirty page balancing: if so, use 
   uncached.

so we could just add a "nocached" flag to that whole 
__copy_from_user[_inatomic]_nocache thing, and we could make 
balance_dirty_pages_ratelimited() return a flag satung whether we're 
starting write-out or not.

Of course, the dirty writeout will always happen to _old_ pages, so we'll 
actually get notified too late, but assuming you have some steady state 
"heavy IO", it would presumably still be a reasonable heuristic.

But on the other hand, I could personally certainly also imagine just not 
doing that whole uncached thing at all. Myself, I tend to care about the 
peformance of the cached case much more than some odd iozone thing. But 
others will have different priorities..

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