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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1731FA3741 for ; Mon, 31 Oct 2022 19:08:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229692AbiJaTH6 (ORCPT ); Mon, 31 Oct 2022 15:07:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbiJaTH4 (ORCPT ); Mon, 31 Oct 2022 15:07:56 -0400 Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BFDA11C2F for ; Mon, 31 Oct 2022 12:07:55 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id o8so8945233qvw.5 for ; Mon, 31 Oct 2022 12:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RIRCeB57mif3WLLjzHJdENrFUL9U/TfVQ593vGFl6q4=; b=PzRtrjqO02eaWa33Zq3luOuXf6b8F5IN//bl0BoITVBRXmcMh7nbJhnqTYWRRryu5y 8iDxEI/HfGaS1+1tz8lnXx3Ny5EVlFEYhPErbdEJhiUGODUQeS5CyUWmCheYQW971isr K+Mc3Us7oEuRSM2JN/G6i+LXwzXpZEIcmSr+o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RIRCeB57mif3WLLjzHJdENrFUL9U/TfVQ593vGFl6q4=; b=hRo3O1eG0ih4hkXhPYcxJgB/6b8hdHGEWVyQnc/5PTshqGwsKgNPSigsbUifMNnvTx Hk9DMqke7fqCbwBggEEd5dAhH2xt0gY1rvvS1y7ANMY5e4atI7Rquc7GOl9WXxdo4qlN PJ8CjPXW5ENGux8tdiBWLgeiasFtqBhOc12my+8R+KsHxoYAq6BAC1L/4wvgpyGKPAiF 9kr2H2eTN2cYnPgGwCOZod5upXgNVV4eGdm4141hLGTk0npBNJmqjOhuXCbaTYpdyqcb rEFMde6tjcIU81YpL4+DP5nJx7x3ciGRCZvs4xxZyvoA1xB1bazb9omIOXeGVCuVqzHT Q0CA== X-Gm-Message-State: ACrzQf2epp5BQH0hpiw3tnCWdoo5GtHy4nMtsTKvICRpTzD3Uv2US+BE efNd8MwFOfTDPH5GWqfXuFRTJd13kxZFZQ== X-Google-Smtp-Source: AMsMyM4Ee+TZhvFESxifDL5ZbYRMf3zJ0lb6HTgKveEGgF8voG8drknnCpgUM2yOpEkJV7laSI1VRw== X-Received: by 2002:a0c:e18f:0:b0:4bb:5b84:fb2c with SMTP id p15-20020a0ce18f000000b004bb5b84fb2cmr12651354qvl.28.1667243274274; Mon, 31 Oct 2022 12:07:54 -0700 (PDT) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com. [209.85.219.170]) by smtp.gmail.com with ESMTPSA id c17-20020ac853d1000000b0039cc944ebdasm4023765qtq.54.2022.10.31.12.07.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Oct 2022 12:07:53 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id 63so14813677ybq.4 for ; Mon, 31 Oct 2022 12:07:53 -0700 (PDT) X-Received: by 2002:a25:bb02:0:b0:6ca:9345:b2ee with SMTP id z2-20020a25bb02000000b006ca9345b2eemr2992665ybg.362.1667243272872; Mon, 31 Oct 2022 12:07:52 -0700 (PDT) MIME-Version: 1.0 References: <20221031175256.2813280-1-jannh@google.com> In-Reply-To: From: Linus Torvalds Date: Mon, 31 Oct 2022 12:07:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] fs: use acquire ordering in __fget_light() To: Al Viro Cc: Jann Horn , Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Will Deacon Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 31, 2022 at 11:48 AM Al Viro wrote: > > Anyway, it's unrelated to the patch itself. I'm fine with it in the current > form. Will apply for the next merge window, unless Linus wants it in right > now. It doesn't strike me as hugely critical, so I'm fine with it being put in any random pile of "fixes to be applied" as long as it doesn't get lost entirely. But if y ou have a "fixes" branch that may end up coming to me before this release is over, that's not the wrong place either. I would tend to agree with Jann that the re-ordering doesn't look very likely because it's the same cacheline, so even an aggressively out-of-order core really doesn't seem to be very likely to trigger any issues. So you have a really unlikely situation to begin with, and even less reason for it then triggering the re-ordering. The "original situation is unlikely" can probably be made quite likely with an active attack, but that active attacker would then also also have to rely on "that re-ordering looks sketchy", and actively hunt for hardware where it can happen. And said hardware may simply not exist, even if the race is certainly theoretically possible on any weakly ordered CPU. Linus