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=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 2F89EC433E1 for ; Wed, 24 Jun 2020 05:57:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 089932088E for ; Wed, 24 Jun 2020 05:57:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592978235; bh=2lsFqyU8P0hr8E82YY+KRZpjYFvt+d061bicFKiQlRc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ozyRtuXn8a54U6aq15lBNkjQpfT8zQwCu7nV0YbzClZs82sgsygZTIdDVlsoJJfli iorODH6d3BANUOJmfUS/6t7xVS9W6OqEfK75w9y8oBnYyjvOComh5kBFkvoNIM1fQg 027OvcDBCLRf0iusX9PsLeN5uPpSbWwwpn/AOdec= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389098AbgFXF5L (ORCPT ); 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 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=-6.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 4EFC0C433E0 for ; Wed, 24 Jun 2020 05:57:19 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 21D012085B for ; Wed, 24 Jun 2020 05:57:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="KCUzYv1t"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="T4S/UfmG"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lbxsf9ik" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 21D012085B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jnyPO-0001uo-Ng; Wed, 24 Jun 2020 05:57:18 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jnyPN-0001uN-7u for linux-f2fs-devel@lists.sourceforge.net; Wed, 24 Jun 2020 05:57:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/23GMzip4Kt9lmgmCCQOvpfWu0Zm9wR0A2TL/GZ2xhw=; b=KCUzYv1t0WndHjpJLwGnzF3mne PPlAYUzdW63Wg5DrydMLMNX91Cwss45qN+2tfy86aFDPp9kE5LAYBG51fJgC+UecBAV+06AKQ14ME j18E4kIgKqjxXC7BRW7lhTNdqLSLTiPwxQn1LLytBCIsBVsZoAcBW0GCmfqrARCElEgk=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=/23GMzip4Kt9lmgmCCQOvpfWu0Zm9wR0A2TL/GZ2xhw=; b=T4S/UfmGOAmojxKKHWuQP0ihUa lsxgu1To5glSk8gaF3ymq0UjNM7vNtScESg+K352e38XmxvOPxfREAfmXmgWLbQ6nvFWb0kZLMEmf VU7a51ePunEzR+V9acJ7t6/CS/VmLGQkuHB1Fc/F9PUmcykEG9s6GGLfbVcdOsZ5Hyfg=; Received: from mail.kernel.org ([198.145.29.99]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1jnyPL-00GCdA-62 for linux-f2fs-devel@lists.sourceforge.net; Wed, 24 Jun 2020 05:57:17 +0000 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 Message-ID: <20200624055707.GG844@sol.localdomain> References: <20200624043341.33364-1-drosen@google.com> <20200624043341.33364-3-drosen@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200624043341.33364-3-drosen@google.com> X-Headers-End: 1jnyPL-00GCdA-62 Subject: Re: [f2fs-dev] [PATCH v9 2/4] fs: Add standard casefolding support X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kernel-team@android.com, Theodore Ts'o , Jonathan Corbet , Richard Weinberger , Andreas Dilger , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, linux-mtd@lists.infradead.org, Alexander Viro , linux-fsdevel@vger.kernel.org, Jaegeuk Kim , linux-ext4@vger.kernel.org, Gabriel Krisman Bertazi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net 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 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel 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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 7DE23C433E0 for ; Wed, 24 Jun 2020 05:58:08 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4A4CD2085B for ; Wed, 24 Jun 2020 05:58:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="D4io2Pf0"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lbxsf9ik" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A4CD2085B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Hblo8S7gfHcgdDvCLruj5ussyOGLUi6Wo2QIQAwJQh8=; b=D4io2Pf0Q5SWiVVXv0vV8u7TG kEtk37sf7rYjO+mIfO7Skrl+w4mludZW9OZkjt3cZj/iZ4BCm/rpua6Hl2U4hB7HIjV1GX5IhVcy3 ZlgJKOPXfI4joiHafveiqPqFKBLQ0KQyXNm/OMHC02kQU11boRii+KzRh+RG2ZMQ9uZQ5BKTFmdlT K89yXou66Ywc2nABp4jpJ9WLdR4Sz5bO0UByxE3s5o17A5gcZm7MaW6u/iH9ZPbRSskmhj1VTGxL5 fFv9O194dciMrWK8GcW6VzRURZuZM7MJ9v78xofPwT0qacxPvhISap5yBsEdnhM7eM2jjFfG1hqAQ bCVjYlJPg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnyPJ-0006Hn-Hn; Wed, 24 Jun 2020 05:57:13 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnyPG-0006Gy-TG for linux-mtd@lists.infradead.org; Wed, 24 Jun 2020 05:57:11 +0000 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 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-Disposition: inline In-Reply-To: <20200624043341.33364-3-drosen@google.com> X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kernel-team@android.com, Theodore Ts'o , Jonathan Corbet , Richard Weinberger , Andreas Dilger , Chao Yu , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, linux-mtd@lists.infradead.org, Alexander Viro , linux-fsdevel@vger.kernel.org, Jaegeuk Kim , linux-ext4@vger.kernel.org, Gabriel Krisman Bertazi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.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 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/