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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 C46B9C388F9 for ; Fri, 23 Oct 2020 13:09:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 34343207FF for ; Fri, 23 Oct 2020 13:09:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JB4V0Zu2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 34343207FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7505D6B0062; Fri, 23 Oct 2020 09:09:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D8F16B0070; Fri, 23 Oct 2020 09:09:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DC106B0071; Fri, 23 Oct 2020 09:09:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0244.hostedemail.com [216.40.44.244]) by kanga.kvack.org (Postfix) with ESMTP id 139006B0062 for ; Fri, 23 Oct 2020 09:09:50 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 98D47181AC9CB for ; Fri, 23 Oct 2020 13:09:49 +0000 (UTC) X-FDA: 77403222498.11.mask64_0014bfd27259 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 78AFD180F8B81 for ; Fri, 23 Oct 2020 13:09:49 +0000 (UTC) X-HE-Tag: mask64_0014bfd27259 X-Filterd-Recvd-Size: 5783 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Fri, 23 Oct 2020 13:09:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603458588; 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=72dx+pFNkJMyRa7xo3pnb+kKjqXwelAsFAb2NVCNc3A=; b=JB4V0Zu2qmEYQ0DNeO5ABOi+jhYvDYq7YBLnmOtxwThxyadBiUGx8EES/MIvVt9vgFH6D4 VxsqJ+u6hYbW64JEZUrcYVv+uYA6NXUWUR15cF7WZbkBYd2UmsQAu549girJ5ZdC9hkdIH On93bLnouhBBJFKvQMT2mNsTkcntwGg= 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-354-Oel3L5QjO_O0-RxNigaJug-1; Fri, 23 Oct 2020 09:09:43 -0400 X-MC-Unique: Oel3L5QjO_O0-RxNigaJug-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 20A3B1882FA0; Fri, 23 Oct 2020 13:09:37 +0000 (UTC) Received: from [10.36.114.18] (ovpn-114-18.ams2.redhat.com [10.36.114.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6AF0A55762; Fri, 23 Oct 2020 13:09:31 +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: <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022104805.GA1503673@kroah.com> <20201022121849.GA1664412@kroah.com> <98d9df88-b7ef-fdfb-7d90-2fa7a9d7bab5@redhat.com> <20201022125759.GA1685526@kroah.com> <20201022135036.GA1787470@kroah.com> <134f162d711d466ebbd88906fae35b33@AcuMS.aculab.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <935f7168-c2f5-dd14-7124-412b284693a2@redhat.com> Date: Fri, 23 Oct 2020 15:09:30 +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: <134f162d711d466ebbd88906fae35b33@AcuMS.aculab.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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 23.10.20 14:46, David Laight wrote: > From: Greg KH >> Sent: 22 October 2020 14:51 > > I've rammed the code into godbolt. > > https://godbolt.org/z/9v5PPW > > Definitely a clang bug. > > Search for [wx]24 in the clang output. > nr_segs comes in as w2 and the initial bound checks are done on w2. > w24 is loaded from w2 - I don't believe this changes the high bits. > There are no references to w24, just x24. > So the kmalloc_array() is passed 'huge' and will fail. > The iov_iter_init also gets the 64bit value. > > Note that the gcc code has a sign-extend copy of w2. Do we have a result from using "unsigned long" in the base function and explicitly masking of the high bits? That should definitely work. Now, I am not a compiler expert, but as I already cited, at least on x86-64 clang expects that the high bits were cleared by the caller - in contrast to gcc. I suspect it's the same on arm64, but again, I am no compiler expert. If what I said and cites for x86-64 is correct, if the function expects an "unsigned int", it will happily use 64bit operations without further checks where valid when assuming high bits are zero. That's why even converting everything to "unsigned int" as proposed by me won't work on clang - it assumes high bits are zero (as indicated by Nick). As I am neither a compiler experts (did I mention that already? ;) ) nor an arm64 experts, I can't tell if this is a compiler BUG or not. Main issue seems to be garbage in high bits as originally suggested by me. -- Thanks, David / dhildenb