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=-4.0 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,UNPARSEABLE_RELAY,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 9FD5CC433E0 for ; Thu, 7 Jan 2021 23:55:52 +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 4C27C235DD for ; Thu, 7 Jan 2021 23:55:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C27C235DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.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: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=iL2fXT4jClgcymkYEHFPH7a7EvcLAEAyGUtp9a++SA4=; b=K0zwgQYOvQF6KbvpEq+oHD4S6 z52WMZrlpyxuhmZwYSGHMFK6+k/oLHVkZmUelcXzVTUQSAqcz6O3y8h39f8+5skqQkt/3TnOQCavJ fmLBq1WtLK5v/uktThQceXAHTHR02aeP22QcOIUUZXvjZpdlZI1E9VGVin6HOAFRFvFsS4DG0CqZG E8tqB2p9LChDOLW5EvuexEEBjdnaiTF1qKDio7Ds01HgGABjnzTjnDC0RZHE/KCeqFbI8lNzT9Edx amXJj94NgnZ5vtMBrxqbpkKnZEG3nQFfv8Ssa65kTy3OrBL3D5rUqQqtTvy3+28/4qBUKTpwHEwWJ Da+muM/Ug==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxf6Y-0001FS-LF; Thu, 07 Jan 2021 23:54:10 +0000 Received: from userp2130.oracle.com ([156.151.31.86]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxf6V-0001EP-8i for linux-arm-kernel@lists.infradead.org; Thu, 07 Jan 2021 23:54:08 +0000 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 107NrfIo142252; Thu, 7 Jan 2021 23:53:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2020-01-29; bh=XmsIp9Zfga5rvuoJrqoBPasGOnyJ8zj0Web421dIPCw=; b=Bfq+C6lyaVF40FuIrCCO1zwWV+lWbh9cH9DbPqcm+elzaJ4M6/24+9I1/f8L6Ll4YbYb 9jBnpv1cqVikgPrEUALeI3gwbkMLQGCgy/i5y7m17vwizSAK2tvC5MMDeE04cAPqkAXC NPFkZAoZdhVhN6GSiu3zSTDNlfiRwpk4Oigf80GyS17H2tcb4x6GfR14bazuEgtSfPjT U9lby2T1KDcMMxDC3Uv+639IMaQf7daHnKROqR43dONIMZ1F30Z9xWeOO3zGsJO8h/f/ gZU+GDmPJQ8oHQqKeHtC0793SWcWOzHYTQZdghxURdkpwODzmQV5P5gczPbCtruTTiTr Gg== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 35wftxegs2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 07 Jan 2021 23:53:41 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 107NaUEB129484; Thu, 7 Jan 2021 23:53:32 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 35w3quga70-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 07 Jan 2021 23:53:32 +0000 Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 107NrUWe004278; Thu, 7 Jan 2021 23:53:30 GMT Received: from localhost (/10.159.138.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Jan 2021 23:53:30 +0000 Date: Thu, 7 Jan 2021 15:53:28 -0800 From: "Darrick J. Wong" To: Eric Biggers Subject: Re: Aarch64 EXT4FS inode checksum failures - seems to be weak memory ordering issues Message-ID: <20210107235328.GI6908@magnolia> References: <20210106135253.GJ1551@shell.armlinux.org.uk> <20210106172033.GA2165@willie-the-truck> <20210106223223.GM1551@shell.armlinux.org.uk> <20210107111841.GN1551@shell.armlinux.org.uk> <20210107124506.GO1551@shell.armlinux.org.uk> <20210107133747.GP1551@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9857 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0 spamscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101070132 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9857 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 mlxscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 clxscore=1011 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101070133 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210107_185407_449689_34DA2F76 X-CRM114-Status: GOOD ( 34.52 ) 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: Mark Rutland , Arnd Bergmann , Theodore Ts'o , Russell King - ARM Linux admin , "linux-kernel@vger.kernel.org" , Andreas Dilger , linux-toolchains@vger.kernel.org, Ext4 Developers List , Will Deacon , Linux ARM 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, Jan 07, 2021 at 02:27:51PM -0800, Eric Biggers wrote: > On Thu, Jan 07, 2021 at 10:48:05PM +0100, Arnd Bergmann wrote: > > On Thu, Jan 7, 2021 at 5:27 PM Theodore Ts'o wrote: > > > > > > On Thu, Jan 07, 2021 at 01:37:47PM +0000, Russell King - ARM Linux admin wrote: > > > > > The gcc bugzilla mentions backports into gcc-linaro, but I do not see > > > > > them in my git history. > > > > > > > > So, do we raise the minimum gcc version for the kernel as a whole to 5.1 > > > > or just for aarch64? > > > > > > Russell, Arnd, thanks so much for tracking down the root cause of the > > > bug! > > > > There is one more thing that I wondered about when looking through > > the ext4 code: Should it just call the crc32c_le() function directly > > instead of going through the crypto layer? It seems that with Ard's > > rework from 2018, that can just call the underlying architecture specific > > implementation anyway. > > > > It looks like that would work, although note that crc32c_le() uses the shash API > too, so it isn't any more "direct" than what ext4 does now. Yes. > Also, a potential issue is that the implementation of crc32c that crc32c_le() > uses might be chosen too early if the architecture-specific implementation of > crc32c is compiled as a module (e.g. crc32c-intel.ko). This was the primary reason I chose to do it this way for ext4. The other is that ext4 didn't use crc32c before metadata_csum, so there's no point in pulling in the crypto layer if you're only going to use older ext2 or ext3 filesystems. That was 2010, maybe people have stopped doing that? > There are two ways this > could be fixed -- either by making it a proper library API like blake2s() that > can call the architecture-specific code directly, or by reconfiguring things > when a new crypto module is loaded (like what lib/crc-t10dif.c does). Though I would like to see the library functions gain the ability to use whatever is the fastest mechanism available once we can be reasonably certain that all the platform-specific drivers have been loaded. That said, IIRC most distros compile all of them into their (increasingly large) vmlinuz files so maybe this isn't much of practical concern? --D > > Until one of those is done, switching to crc32c_le() might cause performance > regressions. > > - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel