Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp302673ybt; Tue, 23 Jun 2020 22:58:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTiyOgzbacLC98alWMFel0Ui5UEr7+SVe33KkGxQdMbGLl0otvZ4mb2O3Of7g/L0KCxv3M X-Received: by 2002:a17:906:1ed2:: with SMTP id m18mr22593742ejj.529.1592978299839; Tue, 23 Jun 2020 22:58:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592978299; cv=none; d=google.com; s=arc-20160816; b=NNWCkcAPV7ao/cfbBZeHWT0xsVeSPl/sQFa8u5JColVU/Lr9x2EXn10E1K71VHXdsk PeIkmnxf0yc8oOFaHU67mBco1KkkU4KotglTaecn2RN6lRadcUMZzzy5/NAaM+6xJjUt nK4eYpL9xEI/8UtbfzXGLWyiCCd0QupzBnI/Npe2/QVWKNtFH5qNvjEBc2Hrj3Lxw2Pk 8DvNOJqjj5sMugWK3ADGnfsAdAWv95Yr1bpzYWBtDV0Q1X5oMU9TvQgg7Zmk9GXFY7Qd 83i4v0+vddOhxN7xpuHe/tTf30Qtpgpcgc6xALn8h0Q4FhgkyfD/f/PtPMcqO9egUdaj yC3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=/23GMzip4Kt9lmgmCCQOvpfWu0Zm9wR0A2TL/GZ2xhw=; b=d9Vdj8WIr/VbUD7L743or0Fl7WhM/wa6SwWtK+Rg4K3+B6Jbw/zlSiJFOVKA9nFPFO W8ReWSyDFaoIVjPiZcpOZ2P8T6LbumN0qIvM/H1GnQOGrmaCXwatz7+AYh2FKhhj0OTu vmfdN71RDXo23e8XWNs2CZSl6bTDZ8HC29cL5TS/g/C1e3KiQwKXAyXd8qI/0GqLfD3I FebvMJKuDGs1DAFCmzHuSeu5pPek1bpesiKbixQ5yp7fUA5UBwKXloFNeIP0XB465phP FzzgR7ew9f67Dieeel8q9ecLaQ27yVbIIbTdkm4qd9SfVF6mSc0lbEJ02DI3jrKFK6I1 wf3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lbxsf9ik; 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 v22si12721369edy.558.2020.06.23.22.57.49; Tue, 23 Jun 2020 22:58:19 -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=default header.b=lbxsf9ik; 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 S2388889AbgFXF5L (ORCPT + 99 others); Wed, 24 Jun 2020 01:57:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:59580 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388724AbgFXF5K (ORCPT ); Wed, 24 Jun 2020 01:57:10 -0400 Received: from sol.localdomain (c-107-3-166-239.hsd1.ca.comcast.net [107.3.166.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4DCC22085B; Wed, 24 Jun 2020 05:57:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592978229; bh=2lsFqyU8P0hr8E82YY+KRZpjYFvt+d061bicFKiQlRc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lbxsf9ik4Ybnb1VNbbAkDP+AkNKZAjMqErfEG+Qv5FJjpqdXBrE0v20o6fKaxGDjU 6IbwyTMIIAryhYBDmhFPRgTRIvcrOwKn8x8VQtZkIfd6G07QWTXk8aEvAPsrzSaFLQ hTu4hRjCUpgjrPNmucpIRCRbHtnLrLbiJjgdLxRY= Date: Tue, 23 Jun 2020 22:57:07 -0700 From: Eric Biggers To: Daniel Rosenberg Cc: Theodore Ts'o , linux-ext4@vger.kernel.org, Jaegeuk Kim , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, Alexander Viro , Richard Weinberger , linux-mtd@lists.infradead.org, Andreas Dilger , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Gabriel Krisman Bertazi , kernel-team@android.com Subject: Re: [PATCH v9 2/4] fs: Add standard casefolding support Message-ID: <20200624055707.GG844@sol.localdomain> References: <20200624043341.33364-1-drosen@google.com> <20200624043341.33364-3-drosen@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200624043341.33364-3-drosen@google.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Jun 23, 2020 at 09:33:39PM -0700, Daniel Rosenberg wrote: > This adds general supporting functions for filesystems that use > utf8 casefolding. It provides standard dentry_operations and adds the > necessary structures in struct super_block to allow this standardization. > > Ext4 and F2fs will switch to these common implementations. > > Signed-off-by: Daniel Rosenberg > --- > fs/libfs.c | 101 +++++++++++++++++++++++++++++++++++++++++++++ > include/linux/fs.h | 22 ++++++++++ > 2 files changed, 123 insertions(+) > > diff --git a/fs/libfs.c b/fs/libfs.c > index 4d08edf19c782..f7345a5ed562f 100644 > --- a/fs/libfs.c > +++ b/fs/libfs.c > @@ -20,6 +20,8 @@ > #include > #include > #include > +#include > +#include > > #include > > @@ -1363,3 +1365,102 @@ bool is_empty_dir_inode(struct inode *inode) > return (inode->i_fop == &empty_dir_operations) && > (inode->i_op == &empty_dir_inode_operations); > } > + > +#ifdef CONFIG_UNICODE > +/** > + * needs_casefold - generic helper to determine if a filename should be casefolded > + * @dir: Parent directory > + * > + * Generic helper for filesystems to use to determine if the name of a dentry > + * should be casefolded. It does not make sense to casefold the no-key token of > + * an encrypted filename. > + * > + * Return: if names will need casefolding > + */ > +bool needs_casefold(const struct inode *dir) > +{ > + return IS_CASEFOLDED(dir) && dir->i_sb->s_encoding && > + (!IS_ENCRYPTED(dir) || fscrypt_has_encryption_key(dir)); > +} > +EXPORT_SYMBOL(needs_casefold); Note that the '!IS_ENCRYPTED(dir) || fscrypt_has_encryption_key(dir)' check can be racy, because a process can be looking up a no-key token in a directory while concurrently another process initializes the directory's ->i_crypt_info, causing fscrypt_has_encryption_key(dir) to suddenly start returning true. In my rework of filename handling in f2fs, I actually ended up removing all calls to needs_casefold(), thus avoiding this race. f2fs now decides whether the name is going to need casefolding early on, in __f2fs_setup_filename(), where it knows in a race-free way whether the filename is a no-key token or not. Perhaps ext4 should work the same way? It did look like there would be some extra complexity due to how the ext4 directory hashing works in comparison to f2fs's, but I haven't had a chance to properly investigate it. - Eric