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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 41663C56201 for ; Thu, 22 Oct 2020 19:25:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F1EAF2465A for ; Thu, 22 Oct 2020 19:25:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S370161AbgJVTZP (ORCPT ); Thu, 22 Oct 2020 15:25:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S370155AbgJVTZP (ORCPT ); Thu, 22 Oct 2020 15:25:15 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81851C0613CE; Thu, 22 Oct 2020 12:25:14 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVgCo-006RRM-M6; Thu, 22 Oct 2020 19:24:58 +0000 Date: Thu, 22 Oct 2020 20:24:58 +0100 From: Al Viro To: Nick Desaulniers Cc: Arnd Bergmann , David Laight , Christoph Hellwig , David Hildenbrand , Greg KH , "kernel-team@android.com" , Andrew Morton , Jens Axboe , 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: <20201022192458.GV3576660@ZenIV.linux.org.uk> References: <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022132342.GB8781@lst.de> <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote: > Passing an `unsigned long` as an `unsigned int` does no such > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > calls, no masking instructions). > So if rw_copy_check_uvector() is inlined into import_iovec() (looking > at the mainline@1028ae406999), then children calls of > `rw_copy_check_uvector()` will be interpreting the `nr_segs` register > unmodified, ie. garbage in the upper 32b. FWIW, void f(unsinged long v) { if (v != 1) printf("failed\n"); } void g(unsigned int v) { f(v); } void h(unsigned long v) { g(v); } main() { h(0x100000001); } must not produce any output on a host with 32bit int and 64bit long, regardless of the inlining, having functions live in different compilation units, etc. Depending upon the calling conventions, compiler might do truncation in caller or in a callee, but it must be done _somewhere_. 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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 0DE0DC388F7 for ; Thu, 22 Oct 2020 19:27:20 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 10ADC24656 for ; Thu, 22 Oct 2020 19:27:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 10ADC24656 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4CHHS32StwzDqx1 for ; Fri, 23 Oct 2020 06:27:15 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=ftp.linux.org.uk (client-ip=2002:c35c:fd02::1; helo=zeniv.linux.org.uk; envelope-from=viro@ftp.linux.org.uk; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4CHHPn0yLvzDqvj for ; Fri, 23 Oct 2020 06:25:16 +1100 (AEDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVgCo-006RRM-M6; Thu, 22 Oct 2020 19:24:58 +0000 Date: Thu, 22 Oct 2020 20:24:58 +0100 From: Al Viro To: Nick Desaulniers Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" Message-ID: <20201022192458.GV3576660@ZenIV.linux.org.uk> References: <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022132342.GB8781@lst.de> <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-aio@kvack.org" , David Hildenbrand , "linux-mips@vger.kernel.org" , David Howells , "linux-mm@kvack.org" , "keyrings@vger.kernel.org" , "sparclinux@vger.kernel.org" , Christoph Hellwig , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "kernel-team@android.com" , Arnd Bergmann , "linux-block@vger.kernel.org" , "io-uring@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Jens Axboe , "linux-parisc@vger.kernel.org" , Greg KH , "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , David Laight , "netdev@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote: > Passing an `unsigned long` as an `unsigned int` does no such > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > calls, no masking instructions). > So if rw_copy_check_uvector() is inlined into import_iovec() (looking > at the mainline@1028ae406999), then children calls of > `rw_copy_check_uvector()` will be interpreting the `nr_segs` register > unmodified, ie. garbage in the upper 32b. FWIW, void f(unsinged long v) { if (v != 1) printf("failed\n"); } void g(unsigned int v) { f(v); } void h(unsigned long v) { g(v); } main() { h(0x100000001); } must not produce any output on a host with 32bit int and 64bit long, regardless of the inlining, having functions live in different compilation units, etc. Depending upon the calling conventions, compiler might do truncation in caller or in a callee, but it must be done _somewhere_. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Date: Thu, 22 Oct 2020 19:24:58 +0000 Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_it Message-Id: <20201022192458.GV3576660@ZenIV.linux.org.uk> List-Id: References: <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022132342.GB8781@lst.de> <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Nick Desaulniers Cc: Arnd Bergmann , David Laight , Christoph Hellwig , David Hildenbrand , Greg KH , "kernel-team@android.com" , Andrew Morton , Jens Axboe , 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" On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote: > Passing an `unsigned long` as an `unsigned int` does no such > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > calls, no masking instructions). > So if rw_copy_check_uvector() is inlined into import_iovec() (looking > at the mainline@1028ae406999), then children calls of > `rw_copy_check_uvector()` will be interpreting the `nr_segs` register > unmodified, ie. garbage in the upper 32b. FWIW, void f(unsinged long v) { if (v != 1) printf("failed\n"); } void g(unsigned int v) { f(v); } void h(unsigned long v) { g(v); } main() { h(0x100000001); } must not produce any output on a host with 32bit int and 64bit long, regardless of the inlining, having functions live in different compilation units, etc. Depending upon the calling conventions, compiler might do truncation in caller or in a callee, but it must be done _somewhere_. 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 E3A59C388F9 for ; Thu, 22 Oct 2020 19:26:54 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5DE3E24656 for ; Thu, 22 Oct 2020 19:26:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Ze9mRz+H" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5DE3E24656 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=re+R66tSqkWrk+yKJWpqDmhBpP4jGATwzA8GuypqgAo=; b=Ze9mRz+H/XEj8SDmXQO38FcI4 rf2+BelfcFFERFOAccAYeQBO5XceiasPy0/Oc9XCzsz0j+OP2yvTGcdNB51mg6Zgv2qnEcD5YKprI 7siAMFFlG28sEppBg4hoe2Bq8JqdcDeqA/k2PXQu6e34iL7Bp+pnJD6374mzAEk8Cgcsx/e2G2lFw 9/WUhgHRyQLDa/f80dZ54aQHNSVY/3uiszkNQvPU78may1pGdgM4mo45WAZr5kkIF3PcW3/TUlokO XYvPPRHsMfRJY1c9j8hg0T1mKFXvBHzClCpEu1yoY6Jj+WrG9yjJldLJT1TMwRyFD+fm7s9CKpYYE 5meADHrkw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVgD5-0003w3-HH; Thu, 22 Oct 2020 19:25:15 +0000 Received: from [2002:c35c:fd02::1] (helo=ZenIV.linux.org.uk) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVgD1-0003vZ-V7 for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 19:25:12 +0000 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVgCo-006RRM-M6; Thu, 22 Oct 2020 19:24:58 +0000 Date: Thu, 22 Oct 2020 20:24:58 +0100 From: Al Viro To: Nick Desaulniers Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" Message-ID: <20201022192458.GV3576660@ZenIV.linux.org.uk> References: <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022132342.GB8781@lst.de> <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_152512_134760_84C60E33 X-CRM114-Status: GOOD ( 11.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-aio@kvack.org" , David Hildenbrand , "linux-mips@vger.kernel.org" , David Howells , "linux-mm@kvack.org" , "keyrings@vger.kernel.org" , "sparclinux@vger.kernel.org" , Christoph Hellwig , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "kernel-team@android.com" , Arnd Bergmann , "linux-block@vger.kernel.org" , "io-uring@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Jens Axboe , "linux-parisc@vger.kernel.org" , Greg KH , "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , David Laight , "netdev@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote: > Passing an `unsigned long` as an `unsigned int` does no such > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > calls, no masking instructions). > So if rw_copy_check_uvector() is inlined into import_iovec() (looking > at the mainline@1028ae406999), then children calls of > `rw_copy_check_uvector()` will be interpreting the `nr_segs` register > unmodified, ie. garbage in the upper 32b. FWIW, void f(unsinged long v) { if (v != 1) printf("failed\n"); } void g(unsigned int v) { f(v); } void h(unsigned long v) { g(v); } main() { h(0x100000001); } must not produce any output on a host with 32bit int and 64bit long, regardless of the inlining, having functions live in different compilation units, etc. Depending upon the calling conventions, compiler might do truncation in caller or in a callee, but it must be done _somewhere_. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel