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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FC0AC433EF for ; Mon, 4 Jul 2022 17:36:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA5266B0072; Mon, 4 Jul 2022 13:36:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D54BA6B0073; Mon, 4 Jul 2022 13:36:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1C6D6B0074; Mon, 4 Jul 2022 13:36:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B17BE6B0072 for ; Mon, 4 Jul 2022 13:36:37 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6D388347F0 for ; Mon, 4 Jul 2022 17:36:37 +0000 (UTC) X-FDA: 79650122034.25.2D9E452 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf04.hostedemail.com (Postfix) with ESMTP id D17F240002 for ; Mon, 4 Jul 2022 17:36:36 +0000 (UTC) Received: by mail-lj1-f170.google.com with SMTP id u14so11857167ljh.2 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=W/AJIyEDbr1ToW1iTFP9FBQj4bOXKVgTjmC4E4HpbpI2bCZTsNUOfqkhbx8ZrYLCIg tzgXrjkES0FwZCM/FcTMkqY5gkvpnzjU7psXeLElKejgILBu1NpuHMiwv7pLrEk7yAkX +UDBIfYqIu9i9HPv26GK+GEcTuqEKCT21xMnwLT74//Nq65qKeaTZ5atURHG8aBw62/Z x69Smxu9q+1U2WwXxAUvj+FLTUDcd972BMZwvzugouq5n7tMRo4Rpghz6/fXO5Tggmyt HeV4h3XVgyfIwxOd5h/KftWOhqS5qyree1OKMk6jptYZIHI/+1086A2CZz02ViFWQz3p 6GUA== X-Gm-Message-State: AJIora/SfD4X19hO3jqDXHXUBNnKbIDiK0Cc7n4Kvtq5wPaKaKZ+RMG5 E9BZjIM7OyxP2M2TB5CFggdL4gxY3cZiUsNMBzI= X-Google-Smtp-Source: AGRyM1v/ydUxKOJ/aU4LZKAwY0gI0kNOHCCzRAWx9oY3usSsydhwRD6LLzJeAPB+wri6+pN8zl2iKg== X-Received: by 2002:a05:651c:14e:b0:25b:bd40:33a2 with SMTP id c14-20020a05651c014e00b0025bbd4033a2mr16919219ljd.414.1656956195093; Mon, 04 Jul 2022 10:36:35 -0700 (PDT) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com. [209.85.208.171]) by smtp.gmail.com with ESMTPSA id w20-20020a05651234d400b0047f7bd03943sm5225934lfr.264.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:33 -0700 (PDT) Received: by mail-lj1-f171.google.com with SMTP id l7so11089362ljj.4 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" ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=fwlp1Hgl; dmarc=none; spf=pass (imf04.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.170 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656956197; a=rsa-sha256; cv=none; b=27wssKFkJISZhHV4SeFrY62CWkyfhrPxBWpKyDGxti1TEf0FpzHi/BqonKJ5QSojkJY3u+ Wl7eGRvsMs7kD4woyeONePCwBztDQBEjP9+3c1mAVg7x61gnIVc+o5fIoG3SOqZdI8dWAi lR5duCPimJsYPKflstcTlGeZYU2SxFo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656956197; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YJyesbik3li+nd7lTgRBI8S9OD6JxlDs1GIHpVzW1PQ=; b=OqCl6xhsd/rD6A0DUvKaFwe+piQ1eN0yncUxDQYirgiAYfmJpXcoT1JNSMNL5ABCoWpr5A jORD829w6iTp2/dp8ZaoAk4KS4m4UulUkgWg8VBZsS4fv1Xo/0MB0FMRPsT/FLfID9JH9Q M8KZjuoyc6tNKW1NCinQ2s/HxXUsm+g= Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=fwlp1Hgl; dmarc=none; spf=pass (imf04.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.170 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: t446gz8fdypxsztgszks36toxp5x8ysx X-Rspamd-Queue-Id: D17F240002 X-HE-Tag: 1656956196-705157 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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