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 9D28CC433EF for ; Mon, 4 Jul 2022 19:03:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AEEA6B0071; Mon, 4 Jul 2022 15:03:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9343F6B0073; Mon, 4 Jul 2022 15:03:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B0336B0074; Mon, 4 Jul 2022 15:03:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6496F6B0071 for ; Mon, 4 Jul 2022 15:03:41 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 33F4D604FE for ; Mon, 4 Jul 2022 19:03:41 +0000 (UTC) X-FDA: 79650341442.10.907E63F Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf08.hostedemail.com (Postfix) with ESMTP id 8B93B16000A for ; Mon, 4 Jul 2022 19:03:38 +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=StWcqGItZutY3CkZqZp4EajG2FBl6ewxUbX21EaiIa0=; b=gION5JVUSctjEA3iGVyhgDOwB8 /cIoBlprCjdoAmu+i56RbxnuMuL4IKHr7XgAS37kiaaF4oZ1UP6Cw6APsQOce+xxaXzKDsY66devu sokw+Zjn7Va1VU574s0V9995iYgFWRSsgvDKJYYBEaZM+zFhtFOIEZqa2ed4WycftRArPMeF0UrEC NS3ZibrqrAgjlSoyiT84HEu0f9G07c6zeYA8TeenVF0dYmRU5sfuySzh3JQ3QfHGuHIaEzRGdYXqJ TxAAGr2j4E89bonfbrnO/p8QxTRGrgGkafzSkKhQwMVnXwFLLymD4z2DKEPHZl567ilxQiHg3gQiD yxdElB1Q==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.95 #2 (Red Hat Linux)) id 1o8RLQ-0086lx-NV; Mon, 04 Jul 2022 19:02:52 +0000 Date: Mon, 4 Jul 2022 20:02:52 +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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656961420; a=rsa-sha256; cv=none; b=Dowc5acI50K2YpDB1gXWO0LCI8Uam2CGjw0epwRUrhKt8P6ESHfiunbTqI+07Jj8alCJw6 VHsoEQQs7L79zwH2Yfkg3CRozoc2VaPGz/l0vrG5Zxft5IA1kYDID1A2eR11aEtwgYNImR wybEVUig8XHj05KetfRurtpRQrHqPz0= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=gION5JVU; spf=none (imf08.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; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656961420; 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=StWcqGItZutY3CkZqZp4EajG2FBl6ewxUbX21EaiIa0=; b=sCpxQvIaG61rPaKalnj6L6NmDNN8V47raUcJJzuf7sg0Im8eYRNtg26VmH1uhSO/wdPU8S xBkaSOl3nOpHwEpQCJPiWvaYrB5O7SybIJX8iAvb2bJMq6r54YD7Z2WyS3TYqrQTZoLGYY Yo0L4+7LvVkX1Bdgtcu+TJQ+6t5xFqM= X-Stat-Signature: qoiqeje8z3arzmbuxheqaewd1hmu5k6k X-Rspamd-Queue-Id: 8B93B16000A Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=gION5JVU; spf=none (imf08.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; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1656961418-600301 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 10:36:05AM -0700, Linus Torvalds wrote: > 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. Theoretically it could be a problem. We have /mnt/foo/bar and /mnt/baz/bar. Something's mounted on /mnt/foo, hiding /mnt/foo/bar. We start a pathwalk for /mnt/baz/bar, someone umounts /mnt/foo and swaps /mnt/foo to /mnt/baz before we get there. We are doomed to get -ECHILD from an attempt to legitimize in the end, no matter what. However, we might get a hard error (-ENOENT, for example) before that, if we pick up the old mount that used to be on top of /mnt/foo (now /mnt/baz) and had been detached before the damn thing had become /mnt/baz and notice that there's no "bar" in its root. It used to be impossible (rename would've failed if the target had been non-empty and had we managed to empty it first, well, there's your point when -ENOENT would've been accurate). With exchange... Yes, it's a possible race. Might need to add if (read_seqretry(&mount_lock, nd->m_seq)) return false; in there. And yes, it's a nice demonstration of how subtle and brittle RCU pathwalk is - nobody noticed this bit of fun back when RENAME_EXCHANGE had been added... It got a lot more readable these days, but... > For __follow_mount_rcu it looks like validating the previous sequence > number is left to the caller, which then does try_to_unlazy_next(). Not really - the caller goes there only if we have __follow_mount_rcu() say "it's too tricky for me, get out of RCU mode and deal with it there". Anyway, I've thrown a mount_lock check in there, running xfstests to see how it goes...