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 AE120CCA479 for ; Mon, 4 Jul 2022 17:37:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234725AbiGDRhQ (ORCPT ); Mon, 4 Jul 2022 13:37:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234507AbiGDRg5 (ORCPT ); Mon, 4 Jul 2022 13:36:57 -0400 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E109112AD1 for ; Mon, 4 Jul 2022 10:36:36 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id x10so5158135edd.13 for ; Mon, 04 Jul 2022 10:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YJyesbik3li+nd7lTgRBI8S9OD6JxlDs1GIHpVzW1PQ=; b=fwlp1HglFHpX7O+wTF2XFvDWUo4ymN7/Rg1c4kPC5Eo6huCSyB0caRrsz6TFxUX8uX qHBcGYMvaNyvVCGIUL8QHtTWVIH0IUT+rGAL3vVJRHDlPNjZBZEB7KnXg7NwJI8bS3PZ v4KpFB9uFWPZ7wy3+FjBv+XuIC8U8KIqUqUIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YJyesbik3li+nd7lTgRBI8S9OD6JxlDs1GIHpVzW1PQ=; b=Sb5VgViOBPidOMzFxoYrubt+wv5074lOfJ7bsskJYH1AUAHYjvhG1Z0D8F2pv89rKS px4SYIuV8KyIaHnSRPsrFBgGzpr7T/JDJkfqpYlGqZiGntPB/Nh93hrevIdDjhLz7EGk Hnp1kI3Vg7IHOw6VZtWI5lK3OfcnGDW+tzyU87eCpE31RiNXwZkxmlz7Rpov5ldhzCaD HTQ02YMN3JjJ42GJUe+GEDYVHJpicx0IOmfPO0zMzu/itd0EQRrfFBPkohFYz0AG3YFZ TRqvXWnA9epxX1kKVztH5BUuNrHiHt4PAK9ufPZzXQL9By4CUU5a4J5ykkuiXaFlRfe2 H1JA== X-Gm-Message-State: AJIora99iFtI/FrzNDsUfM7D0EpdIagIdBKNC52QXbs0lWkalmnKZKYA zXalHeCTZEvTyzgqPKNrULey+KiHoGUvajBMLXY= X-Google-Smtp-Source: AGRyM1vaFU3NHq2ggGtNWhbV0/kNGo47u1LzAy62f4rJDSdl5CLV/Qia4e65iPDIRFAw8jmKIHspyw== X-Received: by 2002:aa7:d30b:0:b0:43a:4bea:75c6 with SMTP id p11-20020aa7d30b000000b0043a4bea75c6mr9560244edq.12.1656956195296; Mon, 04 Jul 2022 10:36:35 -0700 (PDT) Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com. [209.85.218.54]) by smtp.gmail.com with ESMTPSA id v8-20020aa7d648000000b004377151dfbdsm18015082edr.50.2022.07.04.10.36.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Jul 2022 10:36:34 -0700 (PDT) Received: by mail-ej1-f54.google.com with SMTP id sb34so17767526ejc.11 for ; Mon, 04 Jul 2022 10:36:32 -0700 (PDT) X-Received: by 2002:a05:6000:1251:b0:21a:efae:6cbe with SMTP id j17-20020a056000125100b0021aefae6cbemr27345923wrx.281.1656956181432; Mon, 04 Jul 2022 10:36:21 -0700 (PDT) MIME-Version: 1.0 References: <20220701142310.2188015-1-glider@google.com> <20220701142310.2188015-44-glider@google.com> In-Reply-To: From: Linus Torvalds Date: Mon, 4 Jul 2022 10:36:05 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 43/45] namei: initialize parameters passed to step_into() To: Al Viro Cc: Alexander Potapenko , Alexei Starovoitov , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Mark Rutland , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev , Linux-MM , linux-arch , Linux Kernel Mailing List , Evgenii Stepanov , Nathan Chancellor , Nick Desaulniers , Segher Boessenkool , Vitaly Buka , linux-toolchains Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 3, 2022 at 7:53 PM Al Viro wrote: > > FWIW, trying to write a coherent documentation had its usual effect... > The thing is, we don't really need to fetch the inode that early. Hmm. I like the patch, but as I was reading through it, I had a question... In particular, I'd like it even more if each step when the sequence number is updated also had a comment about what then protects the previous sequence number up to and over that new sequence point. For example, in __follow_mount_rcu(), when we jump to a new mount point, and that sequence has *seqp = read_seqcount_begin(&dentry->d_seq); to reset the sequence number to the new path we jumped into. But I don't actually see what checks the previous sequence number in that path. We just reset it to the new one. In contrast, in lookup_fast(), we get the new sequence number from __d_lookup_rcu(), and then after getting the new one and before "instantiating" it, we will revalidate the parent sequence number. So lookup_fast() has that "chain of sequence numbers". For __follow_mount_rcu it looks like validating the previous sequence number is left to the caller, which then does try_to_unlazy_next(). So when reading this code, my reaction was that it really would have been much nicer to have that kind of clear "handoff" of one sequence number domain to the next that lookup_fast() has. IOW, I think it would be lovely to clarify the sequence number handoff. I only quickly scanned your second patch for this, it does seem to at least collect it all into try_to_unlazy_next(). So maybe you already looked at exactly this, but it would be good to be quite explicit about the sequence number logic because it's "a bit opaque" to say the least. Linus