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 5F64AC55179 for ; Fri, 23 Oct 2020 13:09:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC746221F9 for ; Fri, 23 Oct 2020 13:09:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PEXDHdyQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S464351AbgJWNJu (ORCPT ); Fri, 23 Oct 2020 09:09:50 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:38609 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S464335AbgJWNJt (ORCPT ); Fri, 23 Oct 2020 09:09:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603458587; 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=PEXDHdyQA0G/x8om87hOPE7kIiJHqEAntNKZDDr/XgrqoK7m4dr3mho0tvSdrWtD0saFKy KhYCoR5Wdxuk0RProix5hlCO3y9SAVjowLtvG8rNu8jcxBbIgy+MfwDJUBf86WLNxtXENZ cpMPXDulcPvNc5kgldZq+SoWWMuLukM= 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 Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org 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