From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DD5AC5DF9D for ; Thu, 22 Oct 2020 12:18:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EF3A924196 for ; Thu, 22 Oct 2020 12:18:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="n8jf6tlU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF3A924196 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 073C56B0068; Thu, 22 Oct 2020 08:18:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF9806B006C; Thu, 22 Oct 2020 08:18:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D98DC6B0068; Thu, 22 Oct 2020 08:18:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0207.hostedemail.com [216.40.44.207]) by kanga.kvack.org (Postfix) with ESMTP id A51F86B006C for ; Thu, 22 Oct 2020 08:18:14 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3A87D180AD807 for ; Thu, 22 Oct 2020 12:18:14 +0000 (UTC) X-FDA: 77399463708.19.duck07_390c2f127250 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id EAEF71AD1B9; Thu, 22 Oct 2020 12:18:13 +0000 (UTC) X-HE-Tag: duck07_390c2f127250 X-Filterd-Recvd-Size: 5277 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf13.hostedemail.com (Postfix) with ESMTP; Thu, 22 Oct 2020 12:18:12 +0000 (UTC) Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1C49F221FB; Thu, 22 Oct 2020 12:18:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603369091; bh=f9fHT6RQINipQR9cdhFI9rs3NSFDci2lYjU5Ip8ZnP0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n8jf6tlUdap5jlr4t0Cg2lsbhvnaH72P2gVCqZLKUuxs8bAAWAClanPfE+zPwidaB ZFmAyLOFo2OtmjN/+QTkr1IWCvNwAi65T2ABP5/m/R1LV/h/GTeY9DsKfGHUUKRGmT qWRzyp9nLifa3lkVAOBlw5wcV0RoEHaGv9ShJ/SY= Date: Thu, 22 Oct 2020 14:18:49 +0200 From: Greg KH To: David Hildenbrand Cc: David Laight , Al Viro , Nick Desaulniers , Christoph Hellwig , "kernel-team@android.com" , Andrew Morton , Jens Axboe , Arnd Bergmann , David Howells , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-s390@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-aio@kvack.org" , "io-uring@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-mm@kvack.org" , "netdev@vger.kernel.org" , "keyrings@vger.kernel.org" , "linux-security-module@vger.kernel.org" Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" Message-ID: <20201022121849.GA1664412@kroah.com> References: <20201022082654.GA1477657@kroah.com> <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> <5d2ecb24db1e415b8ff88261435386ec@AcuMS.aculab.com> <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022104805.GA1503673@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201022104805.GA1503673@kroah.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 22, 2020 at 12:48:05PM +0200, Greg KH wrote: > On Thu, Oct 22, 2020 at 11:36:40AM +0200, David Hildenbrand wrote: > > On 22.10.20 11:32, David Laight wrote: > > > From: David Hildenbrand > > >> Sent: 22 October 2020 10:25 > > > ... > > >> ... especially because I recall that clang and gcc behave slightly > > >> differently: > > >> > > >> https://github.com/hjl-tools/x86-psABI/issues/2 > > >> > > >> "Function args are different: narrow types are sign or zero extended to > > >> 32 bits, depending on their type. clang depends on this for incoming > > >> args, but gcc doesn't make that assumption. But both compilers do it > > >> when calling, so gcc code can call clang code. > > > > > > It really is best to use 'int' (or even 'long') for all numeric > > > arguments (and results) regardless of the domain of the value. > > > > > > Related, I've always worried about 'bool'.... > > > > > >> The upper 32 bits of registers are always undefined garbage for types > > >> smaller than 64 bits." > > > > > > On x86-64 the high bits are zeroed by all 32bit loads. > > > > Yeah, but does not help here. > > > > > > My thinking: if the compiler that calls import_iovec() has garbage in > > the upper 32 bit > > > > a) gcc will zero it out and not rely on it being zero. > > b) clang will not zero it out, assuming it is zero. > > > > But > > > > a) will zero it out when calling the !inlined variant > > b) clang will zero it out when calling the !inlined variant > > > > When inlining, b) strikes. We access garbage. That would mean that we > > have calling code that's not generated by clang/gcc IIUC. > > > > We can test easily by changing the parameters instead of adding an "inline". > > Let me try that as well, as I seem to have a good reproducer, but it > takes a while to run... Ok, that didn't work. And I can't seem to "fix" this by adding noinline to patches further along in the patch series (because this commit's function is no longer present due to later patches.) Will keep digging... greg k-h