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=-13.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 F35A7C433E0 for ; Fri, 8 Jan 2021 21:21:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C57B123A9B for ; Fri, 8 Jan 2021 21:21:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729809AbhAHVVV (ORCPT ); Fri, 8 Jan 2021 16:21:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729695AbhAHVVT (ORCPT ); Fri, 8 Jan 2021 16:21:19 -0500 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F21C0C061757 for ; Fri, 8 Jan 2021 13:20:38 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id 4so6328090plk.5 for ; Fri, 08 Jan 2021 13:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zj0bwaI1Yg9SJ8+KthhKFiHsft2v7jMXKdNfXLE27cs=; b=ob6U9DHAEvzAi1bufn6CgxcWd8olQiKbbPIAhZYPKeH/oVeN5oyMN2OEI6dmw5TIhh BY5fJgwOqDbjlwpZR1dpmELMl9YbkTUkmEYGQomZszYJXllERB2W7HHSOQvFlJUg0VdA c5ZqNwgBNpbw3LV4lEzN7Jx1Io4TRzpINw14w5im+H0Ga1oMTqybejMcj03ZNDb7Eyn0 9rXONMLgNn1iC2hfEEtPRvQ6wSVwgoq1fNxYHeu+PA8aLdsxGXvaowSJSsNmtj1LdCLm mhTETI6t/NaWlfOQ0PEyDqNtz1GgzGvQRac4UQbqQ9eL5rFt1IBsa3x8Wrg8NvTnrQ9r 0H9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zj0bwaI1Yg9SJ8+KthhKFiHsft2v7jMXKdNfXLE27cs=; b=lK9RHi7abPaS3prd6Yb4OWTiQvLg0ELuHHUq6tz4N6hJOmXXUUEmsA/o5uGURjAA7W 3wRBYo93dDjAqJ8cBXWqrmPG2ckEDWUHdCPP9aV9yfJfzbGPpONtQ3Rypyn34ooftCjU DTbfntQjyLVSZlz9bpjC5hW3gSqU9ejIEgNtu/q5tKsdDFsYZYG7TFnFjOJN4BNyG2nV rp+u57e1xWiofEqnMDbeKe9JDx7CsTtXJKFWRt/S8p2xyBg6CLnJdHMBXHiriH3/cvkn BHgV93lJ/X8zJzjvzPz5TB5ghmxAgWEDA1U506SwbyddG4aEpokzuK3RwydSD0L+E1y4 satw== X-Gm-Message-State: AOAM533reGXp43WBBzRP6c1X+WCoTs7Xm9/U9xpA2xmt13uLZOfW8UBP lJio5r3/v1VJ1rGLmzvEctsH6ySYO0m29oUmK5GV+Q== X-Google-Smtp-Source: ABdhPJw4+Aw9i9bi7y60gChG4h4UFGLR+2cSCCczj94KdWXiDg5keuXXDluFhcCGMaGsn7ykhskIUZLD7FurfLRUKhQ= X-Received: by 2002:a17:90a:31c3:: with SMTP id j3mr5582833pjf.25.1610140838310; Fri, 08 Jan 2021 13:20:38 -0800 (PST) MIME-Version: 1.0 References: <20210106115359.GB26994@C02TD0UTHF1T.local> <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> <20210108092655.GA4031@willie-the-truck> In-Reply-To: From: Nick Desaulniers Date: Fri, 8 Jan 2021 13:20:27 -0800 Message-ID: Subject: Re: Aarch64 EXT4FS inode checksum failures - seems to be weak memory ordering issues To: Arnd Bergmann , Linus Torvalds Cc: Will Deacon , Peter Zijlstra , Russell King - ARM Linux admin , linux-toolchains@vger.kernel.org, Mark Rutland , "Theodore Ts'o" , "linux-kernel@vger.kernel.org" , Andreas Dilger , Ext4 Developers List , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 8, 2021 at 12:34 PM Arnd Bergmann wrote: > > On Fri, Jan 8, 2021 at 9:02 PM Linus Torvalds > wrote: > > On Fri, Jan 8, 2021 at 1:27 AM Will Deacon wrote: > > > > > > On Fri, Jan 08, 2021 at 10:21:54AM +0100, Peter Zijlstra wrote: > > > > On Thu, Jan 07, 2021 at 10:20:38PM +0100, Arnd Bergmann wrote: > > > > > On Thu, Jan 7, 2021 at 2:37 PM Russell King - ARM Linux admin > > > > I appreciate Arnd pointing out "--std=gnu11", though. What are the > > actual relevant language improvements? It's hard to say, since a lot of new language features were already GNU C extensions. The only semantic difference I'm aware of is the semantics of `extern inline` changed 100% from c89 to c99 (so jumping from gnu89 to gnu11 would change that). We already #define inline to __attribute__((__gnu_inline)) (there's also a -fgnu-inline flag), but I worry for places that don't include that header or drop KBUILD_CFLAGS (like every vdso), though `extern inline` is awful (and I should be put in jail for introducing it to the kernel; now we have __attribute__((no_stack_protector)) in both toolchains, and should be using that instead, but we don't have it yet for all supported compiler versions). A quick grep through clang's sources shows mostly parser changes for _Noreturn, _Alignof and friends etc.. New to me are unicode literal strings (u or U suffix or prefix?) and something about loops expected to make forward progress??? Another thing I've been worried about is Makefiles that reset KBUILD_CFLAGS, since that's a constant source of pain/breakage for cross compiling from Clang. That tends to drop -std=gnu89. For instance: $ make LLVM=1 -j71 defconfig $ make LLVM=1 -j71 V=1 &>log.txt $ grep -v std=gnu89 log.txt | grep clang | rev | cut -d ' ' -f 1 | rev | grep -v \\.S arch/x86/realmode/rm/wakemain.c arch/x86/realmode/rm/video-mode.c arch/x86/realmode/rm/regs.c arch/x86/realmode/rm/video-vga.c arch/x86/realmode/rm/video-vesa.c arch/x86/realmode/rm/video-bios.c drivers/firmware/efi/libstub/efi-stub-helper.c drivers/firmware/efi/libstub/gop.c drivers/firmware/efi/libstub/secureboot.c drivers/firmware/efi/libstub/tpm.c drivers/firmware/efi/libstub/file.c drivers/firmware/efi/libstub/mem.c drivers/firmware/efi/libstub/random.c drivers/firmware/efi/libstub/randomalloc.c drivers/firmware/efi/libstub/pci.c drivers/firmware/efi/libstub/skip_spaces.c lib/cmdline.c lib/ctype.c drivers/firmware/efi/libstub/alignedmem.c drivers/firmware/efi/libstub/relocate.c drivers/firmware/efi/libstub/vsprintf.c drivers/firmware/efi/libstub/x86-stub.c arch/x86/boot/a20.c arch/x86/boot/cmdline.c arch/x86/boot/cpuflags.c arch/x86/boot/cpucheck.c arch/x86/boot/early_serial_console.c arch/x86/boot/edd.c arch/x86/boot/main.c arch/x86/boot/memory.c arch/x86/boot/pm.c arch/x86/boot/printf.c arch/x86/boot/regs.c arch/x86/boot/string.c arch/x86/boot/tty.c arch/x86/boot/video.c arch/x86/boot/video-mode.c arch/x86/boot/version.c arch/x86/boot/video-vga.c arch/x86/boot/video-vesa.c arch/x86/boot/video-bios.c arch/x86/boot/cpu.c arch/x86/boot/compressed/string.c arch/x86/boot/compressed/cmdline.c arch/x86/boot/compressed/error.c arch/x86/boot/compressed/cpuflags.c arch/x86/boot/compressed/early_serial_console.c arch/x86/boot/compressed/kaslr.c arch/x86/boot/compressed/ident_map_64.c arch/x86/boot/compressed/idt_64.c arch/x86/boot/compressed/pgtable_64.c arch/x86/boot/compressed/acpi.c arch/x86/boot/compressed/misc.c So it looks like parts of the tree are already built with -std=gnu11 or -std=gnu17, as they rely on the implicit default C language mode when unspecified. Oops? -- Thanks, ~Nick Desaulniers 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_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 BE0DFC433E6 for ; Fri, 8 Jan 2021 21:22:15 +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 8346923A80 for ; Fri, 8 Jan 2021 21:22:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8346923A80 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=WPHo7A6oQ4TlZl9oKwFMVNr73l8e11V+ftBs09nC/M8=; b=jdJ+INcCq0Ob8fVWz1Et1DG8N YF7X9BS4X2aJie6qCTsD/7EVBB3V/2Sn1KiI2rILny9PjzzJKQBEAszXYvPrREZZ0pDXp1nics5Gx 3Nir0nXRZPTxc1ExZrLMkRM05iS0slGONEjLxhqssjLriYN3em2o5Lh5CXVIaATn4fEAsEWq9oUFt Egvu503pZAVkEwrDBLl1L96yhbBbdj8LHddMdePdwnZDQeN1SjG6T6yRe4kx0tkPVfX1NyI9Ssoqg OanrrldPXg/dHRYeTw2kU5FbQ7AV6PFUjvR1thRC89ZM7soQI0N9zudMHI3PNpIjUV8La8FE+iUPc I6dtJKyqA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxzBf-0002nC-I6; Fri, 08 Jan 2021 21:20:47 +0000 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxzBb-0002ly-Nl for linux-arm-kernel@lists.infradead.org; Fri, 08 Jan 2021 21:20:44 +0000 Received: by mail-pl1-x634.google.com with SMTP id be12so6333755plb.4 for ; Fri, 08 Jan 2021 13:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zj0bwaI1Yg9SJ8+KthhKFiHsft2v7jMXKdNfXLE27cs=; b=ob6U9DHAEvzAi1bufn6CgxcWd8olQiKbbPIAhZYPKeH/oVeN5oyMN2OEI6dmw5TIhh BY5fJgwOqDbjlwpZR1dpmELMl9YbkTUkmEYGQomZszYJXllERB2W7HHSOQvFlJUg0VdA c5ZqNwgBNpbw3LV4lEzN7Jx1Io4TRzpINw14w5im+H0Ga1oMTqybejMcj03ZNDb7Eyn0 9rXONMLgNn1iC2hfEEtPRvQ6wSVwgoq1fNxYHeu+PA8aLdsxGXvaowSJSsNmtj1LdCLm mhTETI6t/NaWlfOQ0PEyDqNtz1GgzGvQRac4UQbqQ9eL5rFt1IBsa3x8Wrg8NvTnrQ9r 0H9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zj0bwaI1Yg9SJ8+KthhKFiHsft2v7jMXKdNfXLE27cs=; b=N+0liXMGXWW1C+1zuqx2+udQkbIfVUYJDyzGQO8Oaa/SdD9+6CgBUNQcpxZnWjR1Zz txL3RXeR40sDoB7E6bsvZQ6KE4sbvEsLBGD8uQVlOcyEJVlc4RR0wGm1pPu+wYgVlAOZ ukSXMOdxodAQq5H3P0X+v3VICyyiREHuAKrEN18AXMFIy0nkv/s53d6drLCI+xufp6Vx YXmMMDR9ayynLHx46q4I4Fk/hJHzSqAC7FnNKaTiG4paVMWgCZOiAsqb9T29tz30JZ1U 0f8zho2t6cz41WTmLmMNXW4bdjuGIqD6gsEuc7edQdi6tDbdnB1szeeSktwi/jIOD1dq cSYA== X-Gm-Message-State: AOAM530T5hayt3BVUHXbi/Wb5h9JebqorPxxDs+q+0x9V5Qc3RJcxO/6 aaUGlwZHP3kA+ah4cRSjp5HLwL+VB2ONP6PuX3/mkw== X-Google-Smtp-Source: ABdhPJw4+Aw9i9bi7y60gChG4h4UFGLR+2cSCCczj94KdWXiDg5keuXXDluFhcCGMaGsn7ykhskIUZLD7FurfLRUKhQ= X-Received: by 2002:a17:90a:31c3:: with SMTP id j3mr5582833pjf.25.1610140838310; Fri, 08 Jan 2021 13:20:38 -0800 (PST) MIME-Version: 1.0 References: <20210106115359.GB26994@C02TD0UTHF1T.local> <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> <20210108092655.GA4031@willie-the-truck> In-Reply-To: From: Nick Desaulniers Date: Fri, 8 Jan 2021 13:20:27 -0800 Message-ID: Subject: Re: Aarch64 EXT4FS inode checksum failures - seems to be weak memory ordering issues To: Arnd Bergmann , Linus Torvalds X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210108_162043_818756_DE57C541 X-CRM114-Status: GOOD ( 17.12 ) 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 , Theodore Ts'o , Peter Zijlstra , 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 Fri, Jan 8, 2021 at 12:34 PM Arnd Bergmann wrote: > > On Fri, Jan 8, 2021 at 9:02 PM Linus Torvalds > wrote: > > On Fri, Jan 8, 2021 at 1:27 AM Will Deacon wrote: > > > > > > On Fri, Jan 08, 2021 at 10:21:54AM +0100, Peter Zijlstra wrote: > > > > On Thu, Jan 07, 2021 at 10:20:38PM +0100, Arnd Bergmann wrote: > > > > > On Thu, Jan 7, 2021 at 2:37 PM Russell King - ARM Linux admin > > > > I appreciate Arnd pointing out "--std=gnu11", though. What are the > > actual relevant language improvements? It's hard to say, since a lot of new language features were already GNU C extensions. The only semantic difference I'm aware of is the semantics of `extern inline` changed 100% from c89 to c99 (so jumping from gnu89 to gnu11 would change that). We already #define inline to __attribute__((__gnu_inline)) (there's also a -fgnu-inline flag), but I worry for places that don't include that header or drop KBUILD_CFLAGS (like every vdso), though `extern inline` is awful (and I should be put in jail for introducing it to the kernel; now we have __attribute__((no_stack_protector)) in both toolchains, and should be using that instead, but we don't have it yet for all supported compiler versions). A quick grep through clang's sources shows mostly parser changes for _Noreturn, _Alignof and friends etc.. New to me are unicode literal strings (u or U suffix or prefix?) and something about loops expected to make forward progress??? Another thing I've been worried about is Makefiles that reset KBUILD_CFLAGS, since that's a constant source of pain/breakage for cross compiling from Clang. That tends to drop -std=gnu89. For instance: $ make LLVM=1 -j71 defconfig $ make LLVM=1 -j71 V=1 &>log.txt $ grep -v std=gnu89 log.txt | grep clang | rev | cut -d ' ' -f 1 | rev | grep -v \\.S arch/x86/realmode/rm/wakemain.c arch/x86/realmode/rm/video-mode.c arch/x86/realmode/rm/regs.c arch/x86/realmode/rm/video-vga.c arch/x86/realmode/rm/video-vesa.c arch/x86/realmode/rm/video-bios.c drivers/firmware/efi/libstub/efi-stub-helper.c drivers/firmware/efi/libstub/gop.c drivers/firmware/efi/libstub/secureboot.c drivers/firmware/efi/libstub/tpm.c drivers/firmware/efi/libstub/file.c drivers/firmware/efi/libstub/mem.c drivers/firmware/efi/libstub/random.c drivers/firmware/efi/libstub/randomalloc.c drivers/firmware/efi/libstub/pci.c drivers/firmware/efi/libstub/skip_spaces.c lib/cmdline.c lib/ctype.c drivers/firmware/efi/libstub/alignedmem.c drivers/firmware/efi/libstub/relocate.c drivers/firmware/efi/libstub/vsprintf.c drivers/firmware/efi/libstub/x86-stub.c arch/x86/boot/a20.c arch/x86/boot/cmdline.c arch/x86/boot/cpuflags.c arch/x86/boot/cpucheck.c arch/x86/boot/early_serial_console.c arch/x86/boot/edd.c arch/x86/boot/main.c arch/x86/boot/memory.c arch/x86/boot/pm.c arch/x86/boot/printf.c arch/x86/boot/regs.c arch/x86/boot/string.c arch/x86/boot/tty.c arch/x86/boot/video.c arch/x86/boot/video-mode.c arch/x86/boot/version.c arch/x86/boot/video-vga.c arch/x86/boot/video-vesa.c arch/x86/boot/video-bios.c arch/x86/boot/cpu.c arch/x86/boot/compressed/string.c arch/x86/boot/compressed/cmdline.c arch/x86/boot/compressed/error.c arch/x86/boot/compressed/cpuflags.c arch/x86/boot/compressed/early_serial_console.c arch/x86/boot/compressed/kaslr.c arch/x86/boot/compressed/ident_map_64.c arch/x86/boot/compressed/idt_64.c arch/x86/boot/compressed/pgtable_64.c arch/x86/boot/compressed/acpi.c arch/x86/boot/compressed/misc.c So it looks like parts of the tree are already built with -std=gnu11 or -std=gnu17, as they rely on the implicit default C language mode when unspecified. Oops? -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel