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=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable 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 747A4C5517A for ; Thu, 22 Oct 2020 09:36:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 109912417D for ; Thu, 22 Oct 2020 09:36:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="VMLvYiWB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2895810AbgJVJg5 (ORCPT ); Thu, 22 Oct 2020 05:36:57 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:52877 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2895812AbgJVJg4 (ORCPT ); Thu, 22 Oct 2020 05:36:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603359415; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DC+3OwmtjhrVCpfk4sXvCEkgbYjM3Mk+x26MXzYFx48=; b=VMLvYiWBWMQ8BdmpBnQeU65MkER6Womd4xJdO54glA3t/92ZkYXsTYq1nUygAYE8r7fHoJ VgCH5M1VDUAcntGU/mdWH31g0jLaaceEeQfPMxf0koDQMbNQ9meQSM/seFb5+cOHaUP3NR yWNVcXHNeqU07Xr7fsFTmP86uBEG6MA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-481-oXTdLQjNMMegK_tfwCZIGg-1; Thu, 22 Oct 2020 05:36:50 -0400 X-MC-Unique: oXTdLQjNMMegK_tfwCZIGg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6A2D364152; Thu, 22 Oct 2020 09:36:46 +0000 (UTC) Received: from [10.36.113.152] (ovpn-113-152.ams2.redhat.com [10.36.113.152]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7E9B810013D0; Thu, 22 Oct 2020 09:36:41 +0000 (UTC) Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" To: David Laight , Greg KH Cc: 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" References: <20200925045146.1283714-1-hch@lst.de> <20200925045146.1283714-3-hch@lst.de> <20201021161301.GA1196312@kroah.com> <20201021233914.GR3576660@ZenIV.linux.org.uk> <20201022082654.GA1477657@kroah.com> <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> <5d2ecb24db1e415b8ff88261435386ec@AcuMS.aculab.com> <20201022090155.GA1483166@kroah.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> Date: Thu, 22 Oct 2020 11:36:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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". -- Thanks, David / dhildenb From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:44001 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2509549AbgJVJgy (ORCPT ); Thu, 22 Oct 2020 05:36:54 -0400 Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" References: <20200925045146.1283714-1-hch@lst.de> <20200925045146.1283714-3-hch@lst.de> <20201021161301.GA1196312@kroah.com> <20201021233914.GR3576660@ZenIV.linux.org.uk> <20201022082654.GA1477657@kroah.com> <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> <5d2ecb24db1e415b8ff88261435386ec@AcuMS.aculab.com> <20201022090155.GA1483166@kroah.com> From: David Hildenbrand Message-ID: <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> Date: Thu, 22 Oct 2020 11:36:40 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-ID: To: David Laight , Greg KH Cc: 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" 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". -- Thanks, David / dhildenb From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Date: Thu, 22 Oct 2020 09:36:40 +0000 Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_it Message-Id: <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> List-Id: References: <20200925045146.1283714-1-hch@lst.de> <20200925045146.1283714-3-hch@lst.de> <20201021161301.GA1196312@kroah.com> <20201021233914.GR3576660@ZenIV.linux.org.uk> <20201022082654.GA1477657@kroah.com> <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> <5d2ecb24db1e415b8ff88261435386ec@AcuMS.aculab.com> <20201022090155.GA1483166@kroah.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Laight , Greg KH Cc: 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" 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". -- Thanks, David / dhildenb 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=-10.2 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 CC1A0C388F2 for ; Thu, 22 Oct 2020 09:41:37 +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 23BEE223C7 for ; Thu, 22 Oct 2020 09:41:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="biLXmQ2N"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="R8rluKHP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 23BEE223C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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 4CH2SH03HFzDr0r for ; Thu, 22 Oct 2020 20:41:35 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=216.205.24.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=david@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=biLXmQ2N; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=R8rluKHP; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4CH2Lw3SndzDqDQ for ; Thu, 22 Oct 2020 20:36:56 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603359413; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DC+3OwmtjhrVCpfk4sXvCEkgbYjM3Mk+x26MXzYFx48=; b=biLXmQ2NeYOLL4VKEDNJ+AZj53AWtqsuGgIYSYsusTxAJJv2xXrMqoTdym5hgrQdGDQPkv HNgbTaJlNv9s5j5+wMGe6Ws1ruHSuvYcwwuT1ndYZbX8Oj/u4Glq1GQzvfIXxn7eEg/pTw TsB/+k22bbK3VI2lrTjzq9oK/1JdLJM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603359414; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DC+3OwmtjhrVCpfk4sXvCEkgbYjM3Mk+x26MXzYFx48=; b=R8rluKHPUS/kC3hqs3oHR6Pf7aoDfriGUGV7TDIfN+yuN6lmbamnzX65tRoHWUReCcQt8D KiBHBo574gq0CF6QOe0R690uPYdSv81IOD2GYy1MdBkhGzmrnDeWhAvZeZo2i39Rs2jqzF X1mUQl1VPJ6A5DrgNINf6uJj7cQMjSo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-481-oXTdLQjNMMegK_tfwCZIGg-1; Thu, 22 Oct 2020 05:36:50 -0400 X-MC-Unique: oXTdLQjNMMegK_tfwCZIGg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6A2D364152; Thu, 22 Oct 2020 09:36:46 +0000 (UTC) Received: from [10.36.113.152] (ovpn-113-152.ams2.redhat.com [10.36.113.152]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7E9B810013D0; Thu, 22 Oct 2020 09:36:41 +0000 (UTC) Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" To: David Laight , Greg KH References: <20200925045146.1283714-1-hch@lst.de> <20200925045146.1283714-3-hch@lst.de> <20201021161301.GA1196312@kroah.com> <20201021233914.GR3576660@ZenIV.linux.org.uk> <20201022082654.GA1477657@kroah.com> <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> <5d2ecb24db1e415b8ff88261435386ec@AcuMS.aculab.com> <20201022090155.GA1483166@kroah.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> Date: Thu, 22 Oct 2020 11:36:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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" , "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" , Al Viro , "io-uring@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Jens Axboe , "linux-parisc@vger.kernel.org" , "netdev@vger.kernel.org" , Nick Desaulniers , "linux-kernel@vger.kernel.org" , "linux-security-module@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 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". -- Thanks, David / dhildenb 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=-10.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 70CF9C388F7 for ; Thu, 22 Oct 2020 09:38:43 +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 EE020223BF for ; Thu, 22 Oct 2020 09:38:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cwN8lyCs"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="VMLvYiWB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE020223BF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9p2T5FqoNAn1OGt83zach5AhzGIoQdDB+HxoZ1+iKio=; b=cwN8lyCsoI+4vmxQv4Dh0f2Zr vDZrUWhv/phjKhOJcfWe0h8o9f9J+4TAchjaLE14XcFbSBXzlx3F5q59PHyCT+P7USNm3tIGMlw/j GvljfKy+mzjqkaZUVRfhs0B4hpEzwahZ6qFL+zXGAUZkj5UTXgoRtm88WhuS8nKK69kACguFvfev7 jrC9kMSmcL30ko6nanqmtw7YCu2DXBLtdG513158FDvSMN9M5XjbPkQGQUOIjdlTo0y3LARiqslvw XkL74Pp4RGEvlyVNjuOB9rgzelPsAQazl61qmPWdOOdDLvMvTt9u+JdY5aGxiJ2xvGyOs+++akDQz F5XBJPppg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVX1n-0005qp-9l; Thu, 22 Oct 2020 09:36:59 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVX1j-0005oq-N0 for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 09:36:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603359415; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DC+3OwmtjhrVCpfk4sXvCEkgbYjM3Mk+x26MXzYFx48=; b=VMLvYiWBWMQ8BdmpBnQeU65MkER6Womd4xJdO54glA3t/92ZkYXsTYq1nUygAYE8r7fHoJ VgCH5M1VDUAcntGU/mdWH31g0jLaaceEeQfPMxf0koDQMbNQ9meQSM/seFb5+cOHaUP3NR yWNVcXHNeqU07Xr7fsFTmP86uBEG6MA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-481-oXTdLQjNMMegK_tfwCZIGg-1; Thu, 22 Oct 2020 05:36:50 -0400 X-MC-Unique: oXTdLQjNMMegK_tfwCZIGg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6A2D364152; Thu, 22 Oct 2020 09:36:46 +0000 (UTC) Received: from [10.36.113.152] (ovpn-113-152.ams2.redhat.com [10.36.113.152]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7E9B810013D0; Thu, 22 Oct 2020 09:36:41 +0000 (UTC) Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" To: David Laight , Greg KH References: <20200925045146.1283714-1-hch@lst.de> <20200925045146.1283714-3-hch@lst.de> <20201021161301.GA1196312@kroah.com> <20201021233914.GR3576660@ZenIV.linux.org.uk> <20201022082654.GA1477657@kroah.com> <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> <5d2ecb24db1e415b8ff88261435386ec@AcuMS.aculab.com> <20201022090155.GA1483166@kroah.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> Date: Thu, 22 Oct 2020 11:36:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_053656_198577_AC53054A X-CRM114-Status: GOOD ( 19.16 ) 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" , "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" , Al Viro , "io-uring@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Jens Axboe , "linux-parisc@vger.kernel.org" , "netdev@vger.kernel.org" , Nick Desaulniers , "linux-kernel@vger.kernel.org" , "linux-security-module@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 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". -- Thanks, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel