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 42417CCA47F for ; Mon, 4 Jul 2022 20:47:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE0B46B0071; Mon, 4 Jul 2022 16:47:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C90166B0073; Mon, 4 Jul 2022 16:47:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7F5F6B0074; Mon, 4 Jul 2022 16:47:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A87AB6B0071 for ; Mon, 4 Jul 2022 16:47:24 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7C9A633D9A for ; Mon, 4 Jul 2022 20:47:24 +0000 (UTC) X-FDA: 79650602808.19.8E2EB30 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf03.hostedemail.com (Postfix) with ESMTP id 455FA20006 for ; Mon, 4 Jul 2022 20:47:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Q731IdPTtbWT2I3vbiClRvKMIPfhcPeg7PDkz8ljupo=; b=JqCpfM5+ZnF4a2bPP1EP4QyFNP vBpzm4BVvaQCCnYWRX8171Gowyemw8skAK8mPjRXvlzaaGh7Qj2Id0ZiPBjOa1vpVzgMbcuIykFDo qlylUJo63UjcuLdTUuGnkvsrAQc0lbWj0xeYJn9CQoGCE8Oxi4z2sLBwYaAMdqkI/Ns6u2zYuXkks CPoGuTCYI+djgFZEkMKPcsXljk3yzHFHQH5p/Ki60sIk4qTLbL3JC1ynxCUPK4V9PodU/uOMjzQe7 vv4YcJk2eePA/Dj3w3dh29o/KVeQvqvGjXgSWDmlOn9uJ4p1MKO665SwTXHUM0W09dauEtWsVjf1Z MESUVrYg==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.95 #2 (Red Hat Linux)) id 1o8Sxv-0088VZ-0F; Mon, 04 Jul 2022 20:46:43 +0000 Date: Mon, 4 Jul 2022 21:46:42 +0100 From: Al Viro To: Linus Torvalds 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 Subject: Re: [PATCH v4 43/45] namei: initialize parameters passed to step_into() Message-ID: References: <20220701142310.2188015-1-glider@google.com> <20220701142310.2188015-44-glider@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656967643; h=from:from:sender: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=Q731IdPTtbWT2I3vbiClRvKMIPfhcPeg7PDkz8ljupo=; b=opXTAT20VgKAPwLjdbq63VsrjYB91Q+QMkmnVFCNPkEtm2rkSYzVXSAcpOeyqcybL+83WF duamyn3pY8EmCXI3XCpro20yJrQE0Om2NwTprPU3cgUhi+WH8jB9q4ZWqP08dj1aFAQWtq 2xzO0779Pha2oZwx1I12L6CwQujePdk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=JqCpfM5+; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf03.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656967643; a=rsa-sha256; cv=none; b=BJlBjLAiJVmcbdoUqqXBrLnMxt3dWwa/U+5d2z/3FmosiEMDU8dwufZrmy16j0TI8JIKW3 FMITktg3WNPnt9CHA0XTdNhs3aYGGhr3/wTBxojEon//Due+fz0LuhWQWUKX/S6C7VDzQZ udqAzav8ChXMm9wy0toEG4pYmrnAXIw= Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=JqCpfM5+; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf03.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 455FA20006 X-Stat-Signature: 3xrr4xq6s843y857637t3ia3jg51qk38 X-Rspam-User: X-HE-Tag: 1656967643-845032 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 Mon, Jul 04, 2022 at 01:24:48PM -0700, Linus Torvalds wrote: > On Mon, Jul 4, 2022 at 12:55 PM Al Viro wrote: > > > > You are checking the wrong thing here. It's really about mount_lock - > > ->d_seq is *not* bumped when we or attach in some namespace. > > I think we're talking past each other. We might be. > Yes, we need to check the mount sequence lock too, because we're doing > that mount traversal. > > But I think we *also* need to check the dentry sequence count, because > the dentry itself could have been moved to another parent. Why is that a problem? It could have been moved to another parent, but so it could after we'd crossed to the mounted and we wouldn't have noticed (or cared). What the chain of seqcount checks gives us is that with some timings it would be possible to traverse that path, not that it had remained valid through the entire pathwalk. What I'm suggesting is to treat transition from mountpoint to mount as happening instantly, with transition from mount to root sealed by mount_lock check. If that succeeds, there had been possible history in which refwalk would have passed through the same dentry/mount/dentry and arrived to the root dentry when it had the sampled ->d_seq value. Sure, mountpoint might be moved since we'd reached it. And the mount would move with it, so we can pretend that we'd won the race and got into the mount before it had the mountpoint had been moved. Am I missing something fundamental about the things the sequence of sampling and verifications gives us? I'd always thought it's about verifying that resulting history would be possible for a non-RCU pathwalk with the right timings. What am I missing?