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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 80D75C5ACC4 for ; Thu, 20 Feb 2020 02:27:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 585CC24676 for ; Thu, 20 Feb 2020 02:27:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="HuesXzqr" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727402AbgBTC1b (ORCPT ); Wed, 19 Feb 2020 21:27:31 -0500 Received: from mail-lf1-f66.google.com ([209.85.167.66]:36018 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727211AbgBTC1a (ORCPT ); Wed, 19 Feb 2020 21:27:30 -0500 Received: by mail-lf1-f66.google.com with SMTP id f24so1793250lfh.3 for ; Wed, 19 Feb 2020 18:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6R9oDs43e49OHId2T3Say1GnAm1Sa9Cij9vjtGqns0w=; b=HuesXzqrMwl5FNOeLlSDpflwNsgmCskzweQrWPKSAAxSCw7lHW66AFscJTMdsIwTfM jGiq6RpnOPaB5Oyh2lOyEHyuTv6NINI8z9tC0O74kkXNN/1S0DYEYEQUa8h2V/dm0VDo keHC2RRk+b6r2swD/RwtYXIMxjyjo6GlOu9gB+dUg2p6qefC+T1P4UZIm91Uo85LA+Rv 8G03jtGxUTJfvgq8RG9MYFoubld2O9BsSsn+sfVhyCNC5XE59suWdHa3oI9hlsR9Dp3B GPuDBZymMhE77jVkDqjzwPoCAdP4mi7yBzI9bHOB2pq77Qnr4eN2rvsvew1j0jZvfkPA bB7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6R9oDs43e49OHId2T3Say1GnAm1Sa9Cij9vjtGqns0w=; b=dGo304yI3IEKpTk/mtppY39UWHJJx55aHVEey3qE5AXh7eDQ2ExAwHajg6iMvvFszX pu8GllW5M26HRufDsPgwazB/siXXjusKuj7BjiMtRajanMln7ShaUAW/92PrSUPYruhs lHjcOGs1BZ/vLV8iLeTMlmyd3UtpxPnrEpcXVzYw8qBw/puHpdVizhbyHg7nLwIngDNN fiMJytXAfsTxJQX6yJv7x2UQPMZH3uzrJ1YGeL5Mg9Zb0wn9MSSFWwO90JOCIWGGJXEp z9IEDmi/ieseX1+RGgYxITjOHn7vwUng0AwV/Sf15ifwFrzjNW3f8af1Ev/BTq8bE4/0 VuBw== X-Gm-Message-State: APjAAAVgBdCZYBfaMrS6Pj5IYZwW1qd4js3j6EibL7wQyuQ3t/ld9fif x5o6YCJpZ/vef6p9b1zrDONqS6EeIOng5JfmhHHgGw== X-Google-Smtp-Source: APXvYqxXpLX+dEvOT5j7tpgmTqUeHQ8fFVlo3960ntu34jaP3dDFM5jPLMUuGTmSmVlcfqf9AGyYlOtPMi7izdaPUmg= X-Received: by 2002:ac2:5979:: with SMTP id h25mr15671398lfp.203.1582165648799; Wed, 19 Feb 2020 18:27:28 -0800 (PST) MIME-Version: 1.0 References: <20200208013552.241832-1-drosen@google.com> <20200208013552.241832-3-drosen@google.com> <20200208021216.GE23230@ZenIV.linux.org.uk> <20200210234207.GJ23230@ZenIV.linux.org.uk> <20200212063440.GL870@sol.localdomain> <20200212065734.GA157327@sol.localdomain> In-Reply-To: <20200212065734.GA157327@sol.localdomain> From: Daniel Rosenberg Date: Wed, 19 Feb 2020 18:27:17 -0800 Message-ID: Subject: Re: [PATCH v7 2/8] fs: Add standard casefolding support To: Eric Biggers , Al Viro , Gabriel Krisman Bertazi Cc: "Theodore Ts'o" , linux-ext4@vger.kernel.org, Jaegeuk Kim , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, linux-fscrypt@vger.kernel.org, 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, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org On Tue, Feb 11, 2020 at 10:57 PM Eric Biggers wrote: > > Or (just throwing another idea out there) the dentry's name could be copied to a > temporary buffer in ->d_compare(). The simplest version would be: > > u8 _name[NAME_MAX]; > > memcpy(_name, name, len); > name = _name; > > Though, 255 bytes is a bit large for a stack buffer (so for long names it may > need kmalloc with GFP_ATOMIC), and technically it would need a special version > of memcpy() to be guaranteed safe from compiler optimizations (though I expect > this would work in practice). > > Alternatively, take_dentry_name_snapshot() kind of does this already, except > that it takes a dentry and not a (name, len) pair. > > - Eric If we want to use take_dentry_name_snapshot, we'd need to do it before calling the dentry op, since we get the dentry as a const. It would do exactly what we want, in that it either takes a reference on the long name, or copies the short name, although it does so under a spinlock. I'm guessing we don't want to add that overhead for all d_compare/d_hash's. I suppose it could just take a snapshot if it falls under needs_casefold, but that feels a bit silly to me. i don't think utf8cursor/utf8byte could be modified to be RCU safe apart from a copy. As part of normalization there's some sorting that goes on to ensure that different encodings of the same characters can be matched, and I think those can technically be arbitrarily long, so we'd possibly end up needing the copy anyways. So, I see two possible fixes. 1. Use take_dentry_name_snapshot along the RCU paths to calling d_hash and d_compare, at least when needs_casefold is true. 2. Within d_hash/d_compare, create a copy of the name if it is a short name. For 1, it adds some overhead in general, which I'm sure we'd want to avoid. For 2, I don't think we know we're in RCU mode, so we'd need to always copy short filenames. I'm also unsure if it's valid to assume that name given is stable if it is not the same as dentry->d_iname. If it is, we only need to worry about copying DNAME_INLINE_LEN bytes at max there. For memcpy, is there a different version that we'd want to use for option 2? -Daniel