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 4EF02E784A4 for ; Mon, 2 Oct 2023 07:23:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235729AbjJBHXh (ORCPT ); Mon, 2 Oct 2023 03:23:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235696AbjJBHXg (ORCPT ); Mon, 2 Oct 2023 03:23:36 -0400 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB6BD8E for ; Mon, 2 Oct 2023 00:23:33 -0700 (PDT) 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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description; bh=SRXOr9gSjU2laD7D7wii+BuW599f+TtGiurhtWOQKNY=; b=afQKreWSx7HXeT1InmbDhnRKY0 tAOWRkhR1VQ+35YtOz2UNP6wN2tKq2KEtC0EO7Rh9sj35t72jfhpOKJQ6ot4bjmWfV2uXA/wmTNLq tUh8PQ1fWsrX49ON7tcorw5CtfVP9rT08gTXFwpvKRdoNasnc+riCP7c4XNrgCB+6NFnf03A1PUE2 S2y6iiTWQmHc8LeEhxAQ0n0USah42ntunnzL9Zf7gksvpKyxgU9AmhA0UOefkxU/L6Go8QRuD2+ze XoLhrWSxB8aRpILGnMJoek+t+465RPwuNGeYiafGCd6sdSGvwyWEYN9DVnkiDQCWSpDnZaasF9+8X LembeEaQ==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1qnDHA-00EKG1-0U; Mon, 02 Oct 2023 07:23:32 +0000 Date: Mon, 2 Oct 2023 08:23:32 +0100 From: Al Viro To: Amir Goldstein Cc: linux-fsdevel@vger.kernel.org, Christian Brauner , Christoph Hellwig , Linus Torvalds , Namjae Jeon , David Sterba , David Howells , Miklos Szeredi , Trond Myklebust , Bob Peterson , Steve French , Luis Chamberlain Subject: Re: [PATCH 15/15] overlayfs: make use of ->layers safe in rcu pathwalk Message-ID: <20231002072332.GV800259@ZenIV> References: <20231002022815.GQ800259@ZenIV> <20231002022846.GA3389589@ZenIV> <20231002023613.GN3389589@ZenIV> <20231002023643.GO3389589@ZenIV> <20231002023711.GP3389589@ZenIV> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Oct 02, 2023 at 09:40:15AM +0300, Amir Goldstein wrote: > On Mon, Oct 2, 2023 at 5:37 AM Al Viro wrote: > > > > ovl_permission() accesses ->layers[...].mnt; we can't have ->layers > > freed without an RCU delay on fs shutdown. Fortunately, kern_unmount_array() > > used to drop those mounts does include an RCU delay, so freeing is > > delayed; unfortunately, the array passed to kern_unmount_array() is > > formed by mangling ->layers contents and that happens without any > > delays. > > > > Use a separate array instead; local if we have a few layers, > > kmalloc'ed if there's a lot of them. If allocation fails, > > fall back to kern_unmount() for individual mounts; it's > > not a fast path by any stretch of imagination. > > If that is the case, then having 3 different code paths seems > quite an excessive over optimization... > > I think there is a better way - > layout the mounts array linearly in ofs->mounts[] to begin with, > remove .mnt out of ovl_layer and use ofs->mounts[layer->idx] to > get to a layer's mount. > > I can try to write this patch to see how it ends up looking. Fine by me; about the only problem I see is the cache footprint... How many layers do you consider the normal use, actually?