Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp18952514ybl; Fri, 3 Jan 2020 12:27:06 -0800 (PST) X-Google-Smtp-Source: APXvYqx+UdLRfINtKdGvsjOSf5rv4RRObm1PI0DfjtoXi91Dy06brlbbj5iVJzkCS1vY5mc+sKnv X-Received: by 2002:a9d:6d8f:: with SMTP id x15mr92497727otp.322.1578083226100; Fri, 03 Jan 2020 12:27:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578083226; cv=none; d=google.com; s=arc-20160816; b=kjSDGzKn7ac3iK+zKLxeEWq7KT6J/9mNSiJ7ns8Frg1VRAIo6LB0lfPOQEkgNLgY8o smNn7j+WKdqAM6BhL0a34J6jj0PJLBTofs6yCWh9XV/dhnpMKLwloJx4hX1xiviiOBt8 fTXOa0HuhHiGvAyf9o6Vq42GVJiqrMyyGV+qHcqoDkpitGsT5qR/UmvMk4YInw99bw+j HgrqBH/dcMeuFvrccGZD3TJa1Ae0ft4/9ANWuz+futR1aO/t5mC4Ar3L4eAy0gH4KzpV LrS+KdJPEq4nEhJRZk2OBtEkQoFBdtEW/3MUm28MAuM/ONX97/xbE/3vuYREwjs6vncb 1rTA== 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; bh=j9HvB9oGjIjK8nwMPkEfnnIOl4ZQOletwuHIBp7Ag3I=; b=QbiwXmYNC7wj0cnY1/N/JdlNXEVTTN4AnPKmdC4hHtmF9HU/b8uCauk+8D5Ayd8r7l NU0s0/B6lAd/KjbUOcx3yU72sh/oAE+XjxZyreZYiIq3rVe2mQvm7tKqtkF7Tf+lnJKk OBKDAJTki7CnUobfdQCGVV/nkEZXhBzWmE8Iu6MIjsd5WpyAAfoFBVWrkdF5LUO81b1+ FhLeFcPwTQlSaiiU7XTVw/NaxrpFlNhpQh/r2tYU7fBufNXMuMCL2lwSj9Mont45twTa iTEg8QLJWqlomqv8oZPvdTm4PEpNiU1xBnjwOGcdamuzgu9bd9vWja5VQ6r7C7yXC+qK 5X8g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a64si30867300oii.266.2020.01.03.12.26.54; Fri, 03 Jan 2020 12:27:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728523AbgACU0q (ORCPT + 99 others); Fri, 3 Jan 2020 15:26:46 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:47201 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726050AbgACU0q (ORCPT ); Fri, 3 Jan 2020 15:26:46 -0500 Received: from callcc.thunk.org (guestnat-104-133-0-111.corp.google.com [104.133.0.111] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 003KQ8JY013722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 3 Jan 2020 15:26:09 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 522F24200AF; Fri, 3 Jan 2020 15:26:08 -0500 (EST) Date: Fri, 3 Jan 2020 15:26:08 -0500 From: "Theodore Y. Ts'o" To: Daniel Rosenberg Cc: linux-ext4@vger.kernel.org, Jaegeuk Kim , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Eric Biggers , linux-fscrypt@vger.kernel.org, Alexander Viro , 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 4/8] vfs: Fold casefolding into vfs Message-ID: <20200103202608.GB4253@mit.edu> References: <20191203051049.44573-1-drosen@google.com> <20191203051049.44573-5-drosen@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191203051049.44573-5-drosen@google.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon, Dec 02, 2019 at 09:10:45PM -0800, Daniel Rosenberg wrote: > @@ -228,6 +229,13 @@ static inline int dentry_string_cmp(const unsigned char *cs, const unsigned char > > #endif > > +bool needs_casefold(const struct inode *dir) > +{ > + return IS_CASEFOLDED(dir) && > + (!IS_ENCRYPTED(dir) || fscrypt_has_encryption_key(dir)); > +} > +EXPORT_SYMBOL(needs_casefold); > + I'd suggest adding a check to make sure that dir->i_sb->s_encoding is non-NULL before needs_casefold() returns non-NULL. Otherwise a bug (or a fuzzed file system) which manages to set the S_CASEFOLD flag without having s_encoding be initialized might cause a NULL dereference. Also, maybe make needs_casefold() an inline function which returns 0 if CONFIG_UNICODE is not defined? That way the need for #ifdef CONFIG_UNICODE could be reduced. > @@ -247,7 +255,19 @@ static inline int dentry_cmp(const struct dentry *dentry, const unsigned char *c > * be no NUL in the ct/tcount data) > */ > const unsigned char *cs = READ_ONCE(dentry->d_name.name); > +#ifdef CONFIG_UNICODE > + struct inode *parent = dentry->d_parent->d_inode; > > + if (unlikely(needs_casefold(parent))) { > + const struct qstr n1 = QSTR_INIT(cs, tcount); > + const struct qstr n2 = QSTR_INIT(ct, tcount); > + int result = utf8_strncasecmp(dentry->d_sb->s_encoding, > + &n1, &n2); > + > + if (result >= 0 || sb_has_enc_strict_mode(dentry->d_sb)) > + return result; > + } > +#endif This is an example of how we could drop the #ifdef CONFIG_UNICODE (moving the declaration of 'parent' into the #if statement) if needs_casefold() always returns 0 if !defined(CONFIG_UNICODE). > @@ -2404,7 +2424,22 @@ struct dentry *d_hash_and_lookup(struct dentry *dir, struct qstr *name) > * calculate the standard hash first, as the d_op->d_hash() > * routine may choose to leave the hash value unchanged. > */ > +#ifdef CONFIG_UNICODE > + unsigned char *hname = NULL; > + int hlen = name->len; > + > + if (IS_CASEFOLDED(dir->d_inode)) { > + hname = kmalloc(PATH_MAX, GFP_ATOMIC); > + if (!hname) > + return ERR_PTR(-ENOMEM); > + hlen = utf8_casefold(dir->d_sb->s_encoding, > + name, hname, PATH_MAX); > + } > + name->hash = full_name_hash(dir, hname ?: name->name, hlen); > + kfree(hname); > +#else > name->hash = full_name_hash(dir, name->name, name->len); > +#endif Perhaps this could be refactored out? It's also used in link_path_walk() and lookup_one_len_common(). (Note, there was some strageness in lookup_one_len_common(), where hname is freed twice, the first time using kvfree() which I don't believe is needed. But this can be fixed as part of the refactoring.) - Ted