Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp156596ybv; Wed, 19 Feb 2020 18:27:57 -0800 (PST) X-Google-Smtp-Source: APXvYqwr4cfn3IB8yv+2LL+GLR14U5stoD1LY6gfNYWBVip7XUfSMceS91cZ6mLc5HvMUs1JcfVA X-Received: by 2002:aca:1c09:: with SMTP id c9mr523969oic.85.1582165677094; Wed, 19 Feb 2020 18:27:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582165677; cv=none; d=google.com; s=arc-20160816; b=GemZC7HiNHLSTfKMgwwgON3R+Sif1ihuxH341xJSY3txL0qjv+CNZqYp/FXYO8QL4Y LuaX6wws9OIsaOvT4hZI4kmyfEmoK4BR1knww9qBb8/uyy/FOj/pQRMl72k25F7EoEgK 4eei0+L64L8DdDA1mLsRAgm3VnbPV9QzH5clT7eu0CGdOXpOWCw1ZJCMB6ocgxAdZfJO EZ9MutdE5NFl3v4ntOziIiLVKb8PVxTGDK9xdwLEb2He/FA9VHTNK4nsqgLOD3VTrJ4z YvI32gzsu4P8v4l3jAj8JKZt9tOFUQRwsbqql890HxAihQHyQ+Snqr672JFjVPwROM3A FIPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=6R9oDs43e49OHId2T3Say1GnAm1Sa9Cij9vjtGqns0w=; b=lCJaYqgE09J6UwhBUp76VXa4ictcHrlQsMrtUB4pBGMzVa3N4ogvRwtOPfZvy7iU/Z 61KaDg4hjzcZKOwEf+zdeFvoUm8zcetlGksAx6QIjtH4sW+R7uY90u7q8IFDE8W4Eoq4 e5PsId8xCGNACyQoXd1bqPEn8Y/mkJs0dUF9QzRwBwNme1TAew2VzGujw+iSNpRj75Z6 QPNxAJnydhJORwRt+MD17b47k1UqiNac0MeAFyrDlLuOrDErlRhz0vnMic9+Y63ROPPs 22eAoI2Mk6TPHSykDhZDVrEYt1M4NMKi9KP3gAQQRj1cU3WKx9kJ8Y3Bj189mBSsvACn IB6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=HuesXzqr; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h2si10306078oie.151.2020.02.19.18.27.38; Wed, 19 Feb 2020 18:27:57 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=HuesXzqr; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727211AbgBTC1b (ORCPT + 99 others); Wed, 19 Feb 2020 21:27:31 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:38846 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727291AbgBTC1a (ORCPT ); Wed, 19 Feb 2020 21:27:30 -0500 Received: by mail-lf1-f67.google.com with SMTP id r14so1772718lfm.5 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=cLR85JAMilCUbDsLQh1qgQFHgsy5aCHn4zuy68q43Tz3mXcgdBISuG8/4gswupOkg6 gYumPpVl61zICiK2POmly6/5mexEYu9s7HpyPQgolOmJ+wXVVVQsuRZSaAmsOFWQzAH/ tZ3oxgbc0u6XtgiJnTAz77RayIu/lOmYrw7a8akNirq8l3TORHg7Pkk2zx2SK8gHI9b9 HMSUgg7N7jB4C+5ygsd9iTm1kA1p+EspqRTFUoCo8IDiZ5MgDlYzoMm5DPgmo2A9lObr uYZO3D7/1uMZng8BS1saq3KlYaqlAAeLzBpcLuilLLQz28gsZcMtgr65/PvnaJwMAX1I 5w7w== X-Gm-Message-State: APjAAAV/8KbxJFIDtSg3jNcmeamMK7+nC11VOSkTVWsFvkxPL7Mo7K79 f5lsA8zjZYnhPm+dYQP9331OytV8wNtMND5EvMfMgQ== 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-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@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