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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F9C0C2BB53 for ; Mon, 15 Mar 2021 14:25:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2C8CE650A9 for ; Mon, 15 Mar 2021 14:25:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234011AbhCOOY3 (ORCPT ); Mon, 15 Mar 2021 10:24:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238251AbhCOOW7 (ORCPT ); Mon, 15 Mar 2021 10:22:59 -0400 Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C124FC06175F for ; Mon, 15 Mar 2021 07:22:58 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id a12so16416342vsd.3 for ; Mon, 15 Mar 2021 07:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8GX6YPqUCABnjYLSFPPUAEp9Fl0OXx9Bs7VEy7wBMuA=; b=fOFqWfoTqTvWH20gm5Qsm3Zqkw7ZWL185o17OFNTuL4W3gA1hPwHjQL59LgC5oah8r q1HgmHMD0gBAjo358LTDMyZLzbMaYUQe53lp+fEzhAzkqEkTcm+0PBgw2XCL6+hcpOzs foGVwNBMx9Q3nFMcPGcVFVcygEhwDmbybkRwo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8GX6YPqUCABnjYLSFPPUAEp9Fl0OXx9Bs7VEy7wBMuA=; b=KonoSWSZXGQqmJFFY2YFX2/+zvMgGVDod9gJ5DkC4EzJGvJLEiyKLsnI/Pg3RRO/Dq 5F3VAbFwvTxUskzSxtVnU5ku1aPcSPQDqopj9fDxvllG++9u0HCCV26hsyLRnmasknAH pgIG1IiUC8YQW9frt6to9tEyVOQuuNRHWGLHoCt5iNNdrmuO9NSYcmojUn7uDi8DhQCO JYPzba6L+ygGpSF1APm/UyHTKmw9Q+2L7J6BD1jnfFwDZWvJom6AmC+f2FEYMqSp3V/b vZtaKLV3oUucPE50LH8zWT4yBekqT3eXNVxrhXtK9soFgvJRXs40wncApAAIJk5G64zM bWsQ== X-Gm-Message-State: AOAM5305Y8a+02PewHMLZ1YAHNBAEc69dudTGWwTQw+TrLl5kUKLS1J+ GFbpDjSO9hS3iv1VVz3inOGhbQUoTGoetNTnWh50cQ== X-Google-Smtp-Source: ABdhPJy80S62TYH446SnI2LZQ/PxsdsXi7v+ge/cuIc0NExNcBR2+/ZqSTd3t4NhH+ijehYn2r4eD89vp/0rhfRO3eg= X-Received: by 2002:a67:f7d2:: with SMTP id a18mr10097003vsp.21.1615818177919; Mon, 15 Mar 2021 07:22:57 -0700 (PDT) MIME-Version: 1.0 References: <161581005972.2850696.12854461380574304411.stgit@warthog.procyon.org.uk> <2857440.1615815708@warthog.procyon.org.uk> In-Reply-To: <2857440.1615815708@warthog.procyon.org.uk> From: Miklos Szeredi Date: Mon, 15 Mar 2021 15:22:47 +0100 Message-ID: Subject: Re: [RFC][PATCH 0/3] vfs: Use an xarray instead of inserted bookmarks to scan mount list To: David Howells Cc: Alexander Viro , Matthew Wilcox , Ian Kent , Linus Torvalds , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Mar 15, 2021 at 2:41 PM David Howells wrote: > > Miklos Szeredi wrote: > > > > (2) We can use the file position to represent the mnt_id and can jump to > > > it directly - ie. using seek() to jump to a mount object by its ID. > > > > What happens if the mount at the current position is removed? > > umount_tree() requires the namespace_sem to be writelocked, so that should be > fine as the patches currently read-lock that whilst doing /proc/*/mount* > > I'm assuming that kern_unmount() won't be a problem as it is there to deal > with mounts made by kern_mount() which don't get added to the mount list > (mnt_ns is MNT_NS_INTERNAL). kern_unmount_array() seems to be the same > because overlayfs gives it mounts generated by clone_private_mount(). It > might be worth putting a WARN_ON() in kern_unmount() to require this. > > When reading through proc, m_start() calls xas_find() which returns the entry > at the starting index or, if not present, the next higher entry. This will break the property of new mounts always being added to the end of the list. That's likely a regression for nerural based parsers (i.e. people), probably less so for machine parsers. Thanks, Miklos > > David >