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 56A94C41535 for ; Mon, 30 Oct 2023 05:45:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230477AbjJ3Fpq (ORCPT ); Mon, 30 Oct 2023 01:45:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229829AbjJ3Fpq (ORCPT ); Mon, 30 Oct 2023 01:45:46 -0400 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C00D9BC; Sun, 29 Oct 2023 22:45:43 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 01D4C3200988; Mon, 30 Oct 2023 01:45:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 30 Oct 2023 01:45:43 -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= 1698644741; x=1698731141; bh=jaTWG66pDHoMbCEBoC0gkbfu5n/wvjRGKKr 6RONugiw=; b=kH1PljIwB4mx8xnaIGjwZChPF+ytCawKcocvOonU1W80TSZWp7A mlndkyy1y+v/Pp5M1Ti83zkcRGcpZEX8qlYgTYvlWUISmO7ywFth8lvMO1TOM1PW ESUBADIRp9beHdJ5/jRCsesd1tHJIl9C2+xvZtsLgEH51g1M0AsnI0UsqfBb+9rM 46Cyet41GCFc5y01IQJpT62gHDNEp8coBIY66tx86nQbOxtedlnqHFoWxaKYsW6M 7NBSWFS4kgLFziprja2mK1e0I7mfD/w5NfmRN7XI1jp93GE1UVTgUeG3BLSn5Pvd s9F8Tx74suf3yQcN4y6tEb9ZiVtxjAaLvVQ== 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= 1698644741; x=1698731141; bh=jaTWG66pDHoMbCEBoC0gkbfu5n/wvjRGKKr 6RONugiw=; b=lU/j/+GsBZjBEEfDrgUzeheIxy92PUsVQwlz9VpHBPNkyGeJuEp Ie4cXb1MwbbxAZXN8YU+ms/igcfooRHZBD/kJqX3qsI3j4GlAs4O6qv8qVOqO9Jf Q7AecRB79YnnBiICaFAAmthF6J1Hs3YGSG3DTxQZtOaAWsGTnI/fdiO2Xjr1wLc8 ASaFSONgTCewvWzr2QWqnM1/6YTeGbWt1AaNniaLvZr6NF3BE5EpiDfxGO3XArfY n6vYrs47fmcxnPdnwueK8nerYpL3BgGYFf6euhUHPZFk6Fu0FSaI8Z09EG6Tqiqv Q+Roqn/VyaZwP+74u0rJyQfLkxDneCowbRw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleelgdekkecutefuodetggdotefrodftvf 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:45:35 -0400 (EDT) Message-ID: Date: Mon, 30 Oct 2023 13:45:33 +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 Content-Language: en-US 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: On 30/10/23 13:37, Ian Kent wrote: > 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. Is fs/namespace.c:iterate_mounts() a problem? It's called from: 1) ./kernel/audit_tree.c:709: if (iterate_mounts(compare_root, 2) ./kernel/audit_tree.c:839:    err = iterate_mounts(tag_mount, tree, mnt); 3) ./kernel/audit_tree.c:917:        failed = iterate_mounts(tag_mount, tree, tagged); From functions 1) audit_trim_trees(), 2) audit_add_tree_rule() and 3) audit_tag_tree(). > > >> >> >> Ian >> >>> >>> Thanks, >>> Miklos >>> >> >