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.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,SIGNED_OFF_BY,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 A8C0CC4363A for ; Thu, 22 Oct 2020 08:35:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 39EF921775 for ; Thu, 22 Oct 2020 08:35:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="K8giwg38" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2503377AbgJVIfe (ORCPT ); Thu, 22 Oct 2020 04:35:34 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:55317 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2503117AbgJVIfe (ORCPT ); Thu, 22 Oct 2020 04:35:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603355733; 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=AfHzVZ9ARVJM/ygIfC1QZ398dtBlt7YNWVKjnVzurTM=; b=K8giwg38TJRZ5WNJ9cNl/PvlBgwicNESLKdctOTDLe+E30XITkXOPzHtow3hgTbLHqQWf7 pL2lv59FemnaWIw0rsKdZVDj42UnYhMjW1hjqIEiftuSCIU4ZO+G7kzMU5RUcRT77McVCO s3IXCqpR0R19VNqhbjlB5yToOswdWkI= 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-548-2Rope0bHNb6JPkcxydWrHA-1; Thu, 22 Oct 2020 04:35:30 -0400 X-MC-Unique: 2Rope0bHNb6JPkcxydWrHA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 28CE7879517; Thu, 22 Oct 2020 08:35:27 +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 5EA8D5D9DD; Thu, 22 Oct 2020 08:35:21 +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: Greg KH , Al Viro , Nick Desaulniers Cc: Christoph Hellwig , kernel-team@android.com, Andrew Morton , Jens Axboe , Arnd Bergmann , David Howells , David Laight , 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> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> Date: Thu, 22 Oct 2020 10:35:20 +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: <20201022082654.GA1477657@kroah.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.14 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 22.10.20 10:26, Greg KH wrote: > On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: >> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: >>> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: >>>> From: David Laight >>>> >>>> This lets the compiler inline it into import_iovec() generating >>>> much better code. >>>> >>>> Signed-off-by: David Laight >>>> Signed-off-by: Christoph Hellwig >>>> --- >>>> fs/read_write.c | 179 ------------------------------------------------ >>>> lib/iov_iter.c | 176 +++++++++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 176 insertions(+), 179 deletions(-) >>> >>> Strangely, this commit causes a regression in Linus's tree right now. >>> >>> I can't really figure out what the regression is, only that this commit >>> triggers a "large Android system binary" from working properly. There's >>> no kernel log messages anywhere, and I don't have any way to strace the >>> thing in the testing framework, so any hints that people can provide >>> would be most appreciated. >> >> It's a pure move - modulo changed line breaks in the argument lists >> the functions involved are identical before and after that (just checked >> that directly, by checking out the trees before and after, extracting two >> functions in question from fs/read_write.c and lib/iov_iter.c (before and >> after, resp.) and checking the diff between those. >> >> How certain is your bisection? > > The bisection is very reproducable. > > But, this looks now to be a compiler bug. I'm using the latest version > of clang and if I put "noinline" at the front of the function, > everything works. Well, the compiler can do more invasive optimizations when inlining. If you have buggy code that relies on some unspecified behavior, inlining can change the behavior ... but going over that code, there isn't too much action going on. At least nothing screamed at me. -- Thanks, David / dhildenb From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Date: Thu, 22 Oct 2020 08:35:20 +0000 Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_it Message-Id: <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@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> In-Reply-To: <20201022082654.GA1477657@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Greg KH , Al Viro , Nick Desaulniers Cc: Christoph Hellwig , kernel-team@android.com, Andrew Morton , Jens Axboe , Arnd Bergmann , David Howells , David Laight , 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 10:26, Greg KH wrote: > On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: >> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: >>> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: >>>> From: David Laight >>>> >>>> This lets the compiler inline it into import_iovec() generating >>>> much better code. >>>> >>>> Signed-off-by: David Laight >>>> Signed-off-by: Christoph Hellwig >>>> --- >>>> fs/read_write.c | 179 ------------------------------------------------ >>>> lib/iov_iter.c | 176 +++++++++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 176 insertions(+), 179 deletions(-) >>> >>> Strangely, this commit causes a regression in Linus's tree right now. >>> >>> I can't really figure out what the regression is, only that this commit >>> triggers a "large Android system binary" from working properly. There's >>> no kernel log messages anywhere, and I don't have any way to strace the >>> thing in the testing framework, so any hints that people can provide >>> would be most appreciated. >> >> It's a pure move - modulo changed line breaks in the argument lists >> the functions involved are identical before and after that (just checked >> that directly, by checking out the trees before and after, extracting two >> functions in question from fs/read_write.c and lib/iov_iter.c (before and >> after, resp.) and checking the diff between those. >> >> How certain is your bisection? > > The bisection is very reproducable. > > But, this looks now to be a compiler bug. I'm using the latest version > of clang and if I put "noinline" at the front of the function, > everything works. Well, the compiler can do more invasive optimizations when inlining. If you have buggy code that relies on some unspecified behavior, inlining can change the behavior ... but going over that code, there isn't too much action going on. At least nothing screamed at me. -- 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=-8.2 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 E8F69C4363A for ; Thu, 22 Oct 2020 08:38:01 +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 BF5FA2168B for ; Thu, 22 Oct 2020 08:38:00 +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="K8giwg38"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Bj+mtY1z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF5FA2168B 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 4CH12s4YcszDqkP for ; Thu, 22 Oct 2020 19:37:57 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=63.128.21.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=K8giwg38; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Bj+mtY1z; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.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 4CH10L0SPyzDqNB for ; Thu, 22 Oct 2020 19:35:38 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603355733; 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=AfHzVZ9ARVJM/ygIfC1QZ398dtBlt7YNWVKjnVzurTM=; b=K8giwg38TJRZ5WNJ9cNl/PvlBgwicNESLKdctOTDLe+E30XITkXOPzHtow3hgTbLHqQWf7 pL2lv59FemnaWIw0rsKdZVDj42UnYhMjW1hjqIEiftuSCIU4ZO+G7kzMU5RUcRT77McVCO s3IXCqpR0R19VNqhbjlB5yToOswdWkI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603355734; 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=AfHzVZ9ARVJM/ygIfC1QZ398dtBlt7YNWVKjnVzurTM=; b=Bj+mtY1z58kc35Q1C6mra2hXTimCQULk0Lx+IPOvzsS9KdG9UxT7ZLBprHqmvKV8GImhoF I0Jjo/ZgQ4RmUlvqhPmJtf/4CHhb7i6XOhc+CRwpdmEywmxNNZJbGVwwhUT0IQOJ4t+Qx8 fuXErwC982T9wk4RRRbGl/96K+9drmg= 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-548-2Rope0bHNb6JPkcxydWrHA-1; Thu, 22 Oct 2020 04:35:30 -0400 X-MC-Unique: 2Rope0bHNb6JPkcxydWrHA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 28CE7879517; Thu, 22 Oct 2020 08:35:27 +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 5EA8D5D9DD; Thu, 22 Oct 2020 08:35:21 +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: Greg KH , Al Viro , Nick Desaulniers 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> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> Date: Thu, 22 Oct 2020 10:35:20 +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: <20201022082654.GA1477657@kroah.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.14 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, io-uring@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jens Axboe , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, David Laight , 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 10:26, Greg KH wrote: > On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: >> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: >>> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: >>>> From: David Laight >>>> >>>> This lets the compiler inline it into import_iovec() generating >>>> much better code. >>>> >>>> Signed-off-by: David Laight >>>> Signed-off-by: Christoph Hellwig >>>> --- >>>> fs/read_write.c | 179 ------------------------------------------------ >>>> lib/iov_iter.c | 176 +++++++++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 176 insertions(+), 179 deletions(-) >>> >>> Strangely, this commit causes a regression in Linus's tree right now. >>> >>> I can't really figure out what the regression is, only that this commit >>> triggers a "large Android system binary" from working properly. There's >>> no kernel log messages anywhere, and I don't have any way to strace the >>> thing in the testing framework, so any hints that people can provide >>> would be most appreciated. >> >> It's a pure move - modulo changed line breaks in the argument lists >> the functions involved are identical before and after that (just checked >> that directly, by checking out the trees before and after, extracting two >> functions in question from fs/read_write.c and lib/iov_iter.c (before and >> after, resp.) and checking the diff between those. >> >> How certain is your bisection? > > The bisection is very reproducable. > > But, this looks now to be a compiler bug. I'm using the latest version > of clang and if I put "noinline" at the front of the function, > everything works. Well, the compiler can do more invasive optimizations when inlining. If you have buggy code that relies on some unspecified behavior, inlining can change the behavior ... but going over that code, there isn't too much action going on. At least nothing screamed at me. -- 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=-8.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SIGNED_OFF_BY,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 B4E20C4363A for ; Thu, 22 Oct 2020 08:36:58 +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 28AB721775 for ; Thu, 22 Oct 2020 08:36:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="vbq662va"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="K8giwg38" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 28AB721775 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=OkYkr9VHJCdYovrmAU+SoQgCQeQJwiJ9jD2ksbZ0CZc=; b=vbq662va7EOfeNvOTypgRe+31 AJRWnteVxjIQHvm/jb5GZgNCCTqb2ZIkuwHD4xDammn6OfVCFH9DdNHRROQpAnJQjoO5cbHuAUW6M gC3Q6b/QAfZT2HiLhoa5T5VzH74ITs+HU3KRPmwIuvCIVW/VZ4e0qhGeGtUWNCFtjRYxteA3AzsJU lJNpBL+Q9cIBvRGPsgp2SVkxhQn/bV4jTN27k+mxIncsX1AMFYW/wu+WUKnTNqyyaWueyoVZrA5ZQ z+hRoTu5vZgKYeTXETsQQc8ImCbFIDmhRWB+yT1g1zG0KF3H02dFdXSRzThY41dYL8ID1pLfcLGy8 jFtAl2C+g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVW4P-0003yi-HJ; Thu, 22 Oct 2020 08:35:37 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVW4M-0003xo-5f for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 08:35:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603355733; 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=AfHzVZ9ARVJM/ygIfC1QZ398dtBlt7YNWVKjnVzurTM=; b=K8giwg38TJRZ5WNJ9cNl/PvlBgwicNESLKdctOTDLe+E30XITkXOPzHtow3hgTbLHqQWf7 pL2lv59FemnaWIw0rsKdZVDj42UnYhMjW1hjqIEiftuSCIU4ZO+G7kzMU5RUcRT77McVCO s3IXCqpR0R19VNqhbjlB5yToOswdWkI= 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-548-2Rope0bHNb6JPkcxydWrHA-1; Thu, 22 Oct 2020 04:35:30 -0400 X-MC-Unique: 2Rope0bHNb6JPkcxydWrHA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 28CE7879517; Thu, 22 Oct 2020 08:35:27 +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 5EA8D5D9DD; Thu, 22 Oct 2020 08:35:21 +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: Greg KH , Al Viro , Nick Desaulniers 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> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> Date: Thu, 22 Oct 2020 10:35:20 +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: <20201022082654.GA1477657@kroah.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_043534_239227_71EBAB5D X-CRM114-Status: GOOD ( 26.20 ) 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, io-uring@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jens Axboe , linux-parisc@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, David Laight , 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 10:26, Greg KH wrote: > On Thu, Oct 22, 2020 at 12:39:14AM +0100, Al Viro wrote: >> On Wed, Oct 21, 2020 at 06:13:01PM +0200, Greg KH wrote: >>> On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: >>>> From: David Laight >>>> >>>> This lets the compiler inline it into import_iovec() generating >>>> much better code. >>>> >>>> Signed-off-by: David Laight >>>> Signed-off-by: Christoph Hellwig >>>> --- >>>> fs/read_write.c | 179 ------------------------------------------------ >>>> lib/iov_iter.c | 176 +++++++++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 176 insertions(+), 179 deletions(-) >>> >>> Strangely, this commit causes a regression in Linus's tree right now. >>> >>> I can't really figure out what the regression is, only that this commit >>> triggers a "large Android system binary" from working properly. There's >>> no kernel log messages anywhere, and I don't have any way to strace the >>> thing in the testing framework, so any hints that people can provide >>> would be most appreciated. >> >> It's a pure move - modulo changed line breaks in the argument lists >> the functions involved are identical before and after that (just checked >> that directly, by checking out the trees before and after, extracting two >> functions in question from fs/read_write.c and lib/iov_iter.c (before and >> after, resp.) and checking the diff between those. >> >> How certain is your bisection? > > The bisection is very reproducable. > > But, this looks now to be a compiler bug. I'm using the latest version > of clang and if I put "noinline" at the front of the function, > everything works. Well, the compiler can do more invasive optimizations when inlining. If you have buggy code that relies on some unspecified behavior, inlining can change the behavior ... but going over that code, there isn't too much action going on. At least nothing screamed at me. -- Thanks, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel