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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 95702C7619D for ; Thu, 20 Feb 2020 02:28:02 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 5E13824656 for ; Thu, 20 Feb 2020 02:28:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CKa/REWx"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="HuesXzqr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5E13824656 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4c3ypaGxZ2HCi9sv9zLDPL9tWYvHcc1Ghm/4AHXz1MA=; b=CKa/REWx28/vih AAOXk6kfgswAOJtLAp4/KLNmT+O3bjaNqlNd0nFdv0kfKvQV3UxtxYLOrIDaXDBPbO1EqY29/GN0v 9dwDqJfg71Qr3dpGGXmcGI6+k3rcrNYW7pr+Qrdd38aJcX+7ipVCEC837WlaPBIC+SpF3HaxooXyt ENDNPAtzq9QumXjOjI87JGpy7iENuPc0y5JeRUoSmXjSvPtQotgG5mvccO5dh4vbbdksl6lgvCe8d /Z9uK0+UIx80mcAc2QXoBGKqcrm1rJcOCra8jEwZRAw+MljhE6mbjJYbZ/Lh1le3k/NNx5H0SC5Kk 3jbGnAAmxP0uWT3aCqGA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j4bYz-0007ma-1M; Thu, 20 Feb 2020 02:27:41 +0000 Received: from mail-lf1-x144.google.com ([2a00:1450:4864:20::144]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j4bYv-0007l4-4J for linux-mtd@lists.infradead.org; Thu, 20 Feb 2020 02:27:38 +0000 Received: by mail-lf1-x144.google.com with SMTP id z5so1745641lfd.12 for ; Wed, 19 Feb 2020 18:27:30 -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=WwIYzFDWAGr0VcwC1gNc//7oMzq5gDHIvke5sEqNbKwxgQa5b3z8n2YCUuWacDkUA0 nzSCPvY185dgByEtVvHxN5BDVxUxyPqY0XI2ITpl/JXc8JCWu1YfX6XHq4LVaNfSXoMV DlnVwSapY74Fwk3BQmjziKJB2PDChociTBbG+H6IBFHOnKurToD6Dl99XTOXekiRkLbl ZFvqA/AOvDgOEesuTwd3/ZR81kNnFqwmx1XBuiYYzP9MXFvv2YBAuop/Y53A7ck9qN3D gNMSmpxqdp+PncNwyaVfk9EuD7EOYpv/rBCuXlJf9Ll2HrJhpYb8Abc4dDqPkUE6DVa5 QFGw== X-Gm-Message-State: APjAAAXaoFZGRbXXu8fPkMIfMAZtToGyY5Ef3go5yZQ3aClM30BumkK4 EcARmRbzmSv5PIL0inryvWza417GNmI9htBp4KHteg== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200219_182737_171794_1CB92B37 X-CRM114-Status: GOOD ( 18.34 ) 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: 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, linux-fsdevel@vger.kernel.org, Jaegeuk Kim , linux-ext4@vger.kernel.org, kernel-team@android.com 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, 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 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/