Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758799AbYFQV1D (ORCPT ); Tue, 17 Jun 2008 17:27:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754257AbYFQV0y (ORCPT ); Tue, 17 Jun 2008 17:26:54 -0400 Received: from one.firstfloor.org ([213.235.205.2]:39506 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752803AbYFQV0x (ORCPT ); Tue, 17 Jun 2008 17:26:53 -0400 Message-ID: <48582C18.4090900@firstfloor.org> Date: Tue, 17 Jun 2008 23:26:48 +0200 From: Andi Kleen User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Linus Torvalds CC: Bron Gondwana , Linux Kernel Mailing List , Nick Piggin , Andrew Morton , Rob Mueller , Ingo Molnar Subject: Re: BUG: mmapfile/writev spurious zero bytes (x86_64/not i386, bisected, reproducable) References: <1213682410.13174.1258837181@webmail.messagingengine.com> <1213682570.13708.1258839317@webmail.messagingengine.com> <87od5zwzh2.fsf@basil.nowhere.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1326 Lines: 40 Linus Torvalds wrote: > > On Tue, 17 Jun 2008, Andi Kleen wrote: >> The x86-64 copy_*_user functions were always designed to return errors >> both ways (as in both for load and for store). > > That's not the problem, Andi. > > The problem is that it returns THE WRONG VALUE! > > If the fault happened on the second load, Loads are not supposed to fault in copy_to_user(). Only stores are. The way it works is that it assumes that either loads fault (when used as copy_from_user) or stores (copy_to_user), but never both. > but the first load was never > actually paired up with a store (because of unrolling the loop), then YOU > MUST NOT CLAIM THAT YOU DID A 8-BYTE COPY! Because you have copied exactly > _zero_ bytes, even though you _loaded_ 8 bytes successfully! > > See? > > Claiming that you copied 8 bytes when you didn't do anything at all is > WRONG. It's so incredibly wrong that it is scary. If your patch fixes something then the main wrong thing is the caller who passes a faulting source address. And again it always breaks the other case. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/