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 AEAF3C4167B for ; Mon, 30 Oct 2023 05:37:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229517AbjJ3Fhj (ORCPT ); Mon, 30 Oct 2023 01:37:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231189AbjJ3Fhi (ORCPT ); Mon, 30 Oct 2023 01:37:38 -0400 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9ABABBC; Sun, 29 Oct 2023 22:37:34 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 1235D3200937; Mon, 30 Oct 2023 01:37:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 30 Oct 2023 01:37:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1698644250; x=1698730650; bh=KlwqU26/TGhYg5i9/XVkf+zLh3xMVm+1VcQ XYi/nzIU=; b=bxjFLz7GBjkmMmXRmQYLNY5j/3HDKh5dSWNuahcG7NeEqMKTEwv 9/qDvl+AgqwxTQQKbd93b/Ba91Z3NpKX6eW0IF1IaYlshR0AYQHBCJDkBtuI0Jsd pzKeVCPk8/DuotQIC5pxP5EpDpRtaQ7f0m2Qt6YAfAsaeWgaMBZt6FxB8SsLJRAK c3t69pQuxSFJtt2giTn3oDV+LRxkQuqUhwDCYhbCz18hY+93bPEbG/0F3sQflRSg 0x/E/bfOsl6dpkgaqMRmvwRzGHgwCGqpaeckRLBa/Emk6im0A8U1GWNqVZziMnZc DcYMbEGBAN95jY71+zNKfr25zUpU1VwtZOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1698644250; x=1698730650; bh=KlwqU26/TGhYg5i9/XVkf+zLh3xMVm+1VcQ XYi/nzIU=; b=LSDQuzyZ852n5SdjaR0R0vJHVrHJkmUAG1EOBZazSTv5+J2RjI6 G24gBrLLpWpfRb+hbrVt9qgTzoCzQSTYd/567ySL53FXzsjamMS9Mqi5DAWNwvW2 j1HA2grZ3ecdAy+511jmhJzBw6iIa/jbFb7VN8kL0WELUFL+bd7LVkRllo/5tLqG 0XnSotZZ3rFRUGHKYb8A/Ix9nqsJ+rimXsnkuZwsUb1sG4qE3OBn+/o/SEgwmtJn B21V+cFVsf7wwh5Lx818MriK4apSEpjxFZpRBo4ghyl7KOrjgoqp4eHt48wnhVkC BQsazS/T+49+JHlcJhmv4n0ZFIX/BhE9HNQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleelgdekjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuhffvvehfjggtgfesthekredttdefjeenucfhrhhomhepkfgrnhcu mfgvnhhtuceorhgrvhgvnhesthhhvghmrgifrdhnvghtqeenucggtffrrghtthgvrhhnpe eiveelkefgtdegudefudeftdelteejtedvheeuleevvdeluefhuddtieegveelkeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrrghvvghnse hthhgvmhgrfidrnhgvth X-ME-Proxy: Feedback-ID: i31e841b0:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 30 Oct 2023 01:37:24 -0400 (EDT) Message-ID: Date: Mon, 30 Oct 2023 13:37:18 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v4 2/6] mounts: keep list of mounts in an rbtree From: Ian Kent To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-man@vger.kernel.org, linux-security-module@vger.kernel.org, Karel Zak , David Howells , Linus Torvalds , Al Viro , Christian Brauner , Amir Goldstein , Matthew House , Florian Weimer , Arnd Bergmann References: <20231025140205.3586473-1-mszeredi@redhat.com> <20231025140205.3586473-3-mszeredi@redhat.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: On 28/10/23 09:36, Ian Kent wrote: > On 27/10/23 16:17, Miklos Szeredi wrote: >> On Fri, Oct 27, 2023 at 5:12 AM Ian Kent wrote: >>> On 25/10/23 22:02, Miklos Szeredi wrote: >>>> The mnt.mnt_list is still used to set up the mount tree and for >>>> propagation, but not after the mount has been added to a >>>> namespace.  Hence >>>> mnt_list can live in union with rb_node.  Use MNT_ONRB mount flag to >>>> validate that the mount is on the correct list. >>> Is that accurate, propagation occurs at mount and also at umount. >> When propagating a mount, the new mount's mnt_list is used as a head >> for the new propagated mounts.  These are then moved to the rb tree by >> commit_tree(). >> >> When umounting there's a "to umount" list called tmp_list in >> umount_tree(), this list is used to collect direct umounts and then >> propagated umounts.  The direct umounts are added in umount_tree(), >> the propagated ones umount_one(). >> >> Note: umount_tree() can be called on a not yet finished mount, in that >> case the mounts are still on mnt_list, so umount_tree() needs to deal >> with both. >> >>> IDG how the change to umount_one() works, it looks like umount_list() >>> >>> uses mnt_list. It looks like propagate_umount() is also using mnt_list. >>> >>> >>> Am I missing something obvious? >> So when a mount is part of a namespace (either anonymous or not) it is >> on the rb tree, when not then it can temporarily be on mnt_list. >> MNT_ONRB flag is used to validate that the mount is on the list that >> we expect it to be on, but also to detect the case of the mount setup >> being aborted. >> >> We could handle the second case differently, since we should be able >> to tell when we are removing the mount from a namespace and when we >> are aborting a mount, but this was the least invasive way to do this. > > Thanks for the explanation, what you've said is essentially what I > > understood reading the series. > > > But I still haven't quite got this so I'll need to spend more time > > on this part of the patch series. > > > That's not a problem, ;). After cloning your git tree and looking in there I don't see what I was concerned about so I think I was confused by obscurity by diff rather than seeing a real problem, ;) Still that union worries me a little bit so I'll keep looking at the code for a while. > > > Ian > >> >> Thanks, >> Miklos >> >