Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4015164pxf; Mon, 29 Mar 2021 18:50:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzMNS+l8kNn69r7xXXa6S+xpq1p530keAAUSxDk1ZNVodZC8GGVibRA16hIp/PgFP89Pgfh X-Received: by 2002:aa7:cf17:: with SMTP id a23mr32123308edy.30.1617069009633; Mon, 29 Mar 2021 18:50:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617069009; cv=none; d=google.com; s=arc-20160816; b=iw7zS/KUpeKfCbe7AIeWOtRia1CRrA2ZXyBQOFFADrJlIp2JmdPEqbYcHoe14WEdAW CyMblLy9OaheDIorlvszupdcWbVlzBhcbDeAknno6t90AdS3/VGWagdCtb5oNU+DaoOQ aqapJxIS2spx8nAt5dfvfJGxzV1RXgmXy/G6PdtdFYRy51/BE2rTjkn7I7EJr/nI3R6w 0o6Pc/8TzBEwMIO2KoyozDALktkdu7r4n+I7loAS219g0i4vXXt/ZLaeAUG/fgnPS1pl AU0+w6CAAWYWXmowjhQsNXMjlCsk6AtTQphmSQNTtg42iZ7boCROAG0SuVkGXXZ6hi0t WDog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=3Y1VDQRq1LfrD1XIsfEAJG7MbEKCTChZ0EmxY+Op0AM=; b=X0nUhWFfq1jS2GuhlZlDjoIsQ4aVd1B3q+KprJwGY5e00wnpnlo4/pptFXrXsERLZ8 oah+stHW/vdExDpJ16i0JLE8t7wCB5V5/4oCAmaeunQ7j/UC0wKBEzZbPowZ7ZpGxuGs BGgwS2EALc4uzoglSethntvB7X0ioEFbXcEnQSNotGA79V3Rd0jwLyvu5QEE/2f/c1kM TyCwKZk1DQWyOdTnIdc/W2OfLZZZSzOiHrc8tj/vTmK1enR+klp1wHFBSNhjCerKn8+E 5Y1t4coG5H6exdUozK4zc38GqnuaMh/MrZajWUwBN/34+YbU/zKuIM0F8CbjBJNiDScx jBaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=nDxq7K9t; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u18si13563057edo.335.2021.03.29.18.49.39; Mon, 29 Mar 2021 18:50:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=nDxq7K9t; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230220AbhC3BtG (ORCPT + 99 others); Mon, 29 Mar 2021 21:49:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:41560 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229842AbhC3Bss (ORCPT ); Mon, 29 Mar 2021 21:48:48 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8C49360C41; Tue, 30 Mar 2021 01:48:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617068927; bh=iIeIM/OuGtjaYTjydbbG0UkVMkzGNNchPxEVUAEmnkM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nDxq7K9t7dlImUknG3pZavwpTDgqaPC7F9NdQLDcVbBczilmQZvhCW0eksYB8RuYt WjNUkzadhFtYGdO6BMlWvTRw1NW2eir9qEheqsePkacJsCdS2n/WJYmFgsXweXbnHo 1PT+uC3kAf881vRVcH30ssY4QqHieFaZg+7iVRum4xbCXh6WBWyd4aP52uL34rkcvH rTPtpyumwG13TKR9pY8RmdZsGh7As/NrnVe8LDGtHCGWBLPbo4ro2YhnSCs1MvmKHl KaK/qtyaBcuqUh91ULqym24uAAtps7VmWan4KPhFTY2ueJ92c5xT/nlAI4snicxy2l clT9SDt2FfZaA== Date: Mon, 29 Mar 2021 18:48:46 -0700 From: Eric Biggers To: =?iso-8859-1?Q?Andr=E9?= Almeida Cc: Alexander Viro , Theodore Ts'o , Andreas Dilger , Jaegeuk Kim , Chao Yu , kernel@collabora.com, Daniel Rosenberg , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, krisman@collabora.com Subject: Re: [PATCH 1/3] fs/dcache: Add d_clear_dir_neg_dentries() Message-ID: References: <20210328144356.12866-1-andrealmeid@collabora.com> <20210328144356.12866-2-andrealmeid@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210328144356.12866-2-andrealmeid@collabora.com> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sun, Mar 28, 2021 at 11:43:54AM -0300, Andr? Almeida wrote: > For directories with negative dentries that are becoming case-insensitive > dirs, we need to remove all those negative dentries, otherwise they will > become dangling dentries. During the creation of a new file, if a d_hash > collision happens and the names match in a case-insensitive way, the name > of the file will be the name defined at the negative dentry, that may be > different from the specified by the user. To prevent this from > happening, we need to remove all dentries in a directory. Given that the > directory must be empty before we call this function we are sure that > all dentries there will be negative. > > Create a function to remove all negative dentries from a directory, to > be used as explained above by filesystems that support case-insensitive > lookups. > > Signed-off-by: Andr? Almeida > --- > fs/dcache.c | 27 +++++++++++++++++++++++++++ > include/linux/dcache.h | 1 + > 2 files changed, 28 insertions(+) > > diff --git a/fs/dcache.c b/fs/dcache.c > index 7d24ff7eb206..fafb3016d6fd 100644 > --- a/fs/dcache.c > +++ b/fs/dcache.c > @@ -1723,6 +1723,33 @@ void d_invalidate(struct dentry *dentry) > } > EXPORT_SYMBOL(d_invalidate); > > +/** > + * d_clear_dir_neg_dentries - Remove negative dentries in an inode > + * @dir: Directory to clear negative dentries > + * > + * For directories with negative dentries that are becoming case-insensitive > + * dirs, we need to remove all those negative dentries, otherwise they will > + * become dangling dentries. During the creation of a new file, if a d_hash > + * collision happens and the names match in a case-insensitive, the name of > + * the file will be the name defined at the negative dentry, that can be > + * different from the specified by the user. To prevent this from happening, we > + * need to remove all dentries in a directory. Given that the directory must be > + * empty before we call this function we are sure that all dentries there will > + * be negative. > + */ > +void d_clear_dir_neg_dentries(struct inode *dir) > +{ > + struct dentry *alias, *dentry; > + > + hlist_for_each_entry(alias, &dir->i_dentry, d_u.d_alias) { > + list_for_each_entry(dentry, &alias->d_subdirs, d_child) { > + d_drop(dentry); > + dput(dentry); > + } > + } > +} > +EXPORT_SYMBOL(d_clear_dir_neg_dentries); As Al already pointed out, this doesn't work as intended, for a number of different reasons. Did you consider just using shrink_dcache_parent()? That already does what you are trying to do here, I think. The harder part (which I don't think you've considered) is how to ensure that all negative dentries really get invalidated even if there are lookups of them happening concurrently. Concurrent lookups can take temporary references to the negative dentries, preventing them from being invalidated. - Eric