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]
Message-ID: <alpine.LFD.1.10.0806171442210.2907@woody.linux-foundation.org>
Date:	Tue, 17 Jun 2008 14:46:54 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	Bron Gondwana <brong@...tmail.fm>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nick Piggin <npiggin@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rob Mueller <robm@...tmail.fm>, Ingo Molnar <mingo@...e.hu>
Subject: Re: BUG: mmapfile/writev spurious zero bytes (x86_64/not i386,
 bisected, reproducable)



On Tue, 17 Jun 2008, Andi Kleen wrote:
> 
> The patch is wrong because it'll break the other case (in this case
> copy_from_user)

Ok, I'm now putting you in my idiots filter.

No, it will not break the other case. You're an idiot. Loading a value 
without using it will not break anything, quite the reverse. What the 
patch does is to _fix_ copy_from_user(), because if the second load traps, 
then the fact that we did the first load IS IMMATERIAL, because its result 
was never stored!

So the patch _fixes_ copy_from_user(), exactly because it says that even 
if you've loaded 24 bytes, but you faulted on the fourth load, you've 
still _copied_ exactly zero bytes, because you didn't actually store the 
24 bytes you loaded.

And it is a no-op for copy_to_user, since copy_to_user will never fault on 
the load (not the first one, not the second one, not _any_ load), so the 
exception table entries for the loads are unusued.

IOW: 
 - the patch fixes a bug
 - you refuse to acknowledge this
 - I'll put you in my "flamers" filter that goes into another mailbox, 
   because it's not worth my time even arguing with you any more.

Sorry for ever adding you to the cc. I thought it might be a good idea, 
since you were the author of the code. But clearly the bug was not because 
you made a mistake, but because you simply don't seem to understand what 
the function is supposed to return, and you're not even interested in 
learning.

			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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ