Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp1580421pxv; Fri, 16 Jul 2021 12:32:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy80wWXjBI447X6kLR8iKKr9rfd4Aylj8sVseO4iFzpspHEFY1ktf54xRaVO3ffJ5TBk9Ko X-Received: by 2002:aa7:d991:: with SMTP id u17mr16626205eds.240.1626463972164; Fri, 16 Jul 2021 12:32:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626463972; cv=none; d=google.com; s=arc-20160816; b=l5o9dSr0V2DKGFRvXyo8ldSnD0WVyfWWOtQCk7ge6XwktEDD1qgPGQZlZSf5j5tS2U WEnph8CW/ProwsDzf9z7CErgksebnl68GRhEKEszmQ3gcLLiLUSMfRMMhHvO4t2s1ZeA 1TR+oNzm2wr3H1Ee6EJ13tZZAEGx9+G56UWMFE6mXJMGDpiOcpRxJDhkR3ZTYh7xPwSH T4Rfcx1wERehhCz7tLeYeyxtTM3PgUUqmoF87yMio1PfE5XFEi34XILPqX757pKkK5so fz+CFH9MOh/4zBnRNKPlUyc58EcFVzGyVRTgss2K+kWfNU/wh5Tl4SGgF7sjUQqC90pR 7J0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=ymF8ybeEk0d32lRpmE+zE8M1FoML+GUy3KZheoW8rSE=; b=m5wAukV39RTKRDZuix2BAmpcNLj+9Xww9uW7U+VU+WnBxxisv5a1p/Qazz5k8jXKHB /b2ZLmyipTa1Kp8W3cO21xRBU2npMKRzafgfO7koAcSTEg5tpKRGc8P7A0DfEe4/aqVb e6zvujTn1b6O51Qr5NUEMa5gALxQBrL/ddEX5oMEsnE8/KTvgpJBNagNacEZ0L7piPRp eCnxZ9OQ1fz/eE8bQLOTc/01ufxc4/ORl+dBUwoBICBncOnCwuFYnAqNdxyaA/AIBMRO O0eU/2GI5FjiMtBuWjqJHaL5i0SBf029oWoQCFA0GE2s0dvZ+H1xsDEjiVgeL5q3RBjs PtKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dubeyko-com.20150623.gappssmtp.com header.s=20150623 header.b=uQIkkskr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dc19si12249533edb.160.2021.07.16.12.32.28; Fri, 16 Jul 2021 12:32:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@dubeyko-com.20150623.gappssmtp.com header.s=20150623 header.b=uQIkkskr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229611AbhGPTd6 (ORCPT + 99 others); Fri, 16 Jul 2021 15:33:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54488 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230256AbhGPTd4 (ORCPT ); Fri, 16 Jul 2021 15:33:56 -0400 Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73608C06175F for ; Fri, 16 Jul 2021 12:31:01 -0700 (PDT) Received: by mail-oo1-xc2c.google.com with SMTP id r14-20020a4ad4ce0000b029024b4146e2f5so2708487oos.1 for ; Fri, 16 Jul 2021 12:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dubeyko-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ymF8ybeEk0d32lRpmE+zE8M1FoML+GUy3KZheoW8rSE=; b=uQIkkskr46yAVjD9zPIeHiRdmP5fFiiZzZbRdBzZEf5EJW/wvkmlClPVTLTt8agNcx sE2rE1M8xy/LB3hbIU9BNzMiD7140U8Y40lirE1SbYMAC5pCBjVLi+gZMyu/jYBWLYG3 lzMwiWqo9NxLXG2xdeabgYAmCTk701N8wcgBKUodcV2py/sh50RXqTI8L0CLd0nZt/Ml ftEAw/6i0XmzqcDWFY0geujP0EoKtQ6rGkrktzTIFocPxSKjo61YFodRN+PHwxaseWLs QkZGMRD/OFLN960MKyGBDc6HIPydrTwVsoMGTiVLsPw7POrHSnS2Cw/wCxKltEmJn8ZO ykuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ymF8ybeEk0d32lRpmE+zE8M1FoML+GUy3KZheoW8rSE=; b=Aobbc4rXBd1zP5Xmw/lszvlaxw8Tmji9jQxrOha76MiKqqQXS9sZrIVAp2Fy4tUPc2 1pF2EiOR/lFGvInBIsJZdIY5bCbn4TdtaTbDZP6dHPUBHtLRFTJ56WudRI19FdBBtm2w WLgSLOmHOLvOI19/0LKc7KuT8242qOrb0BLm6jOzSvilcFyZQ6NHpWWzaGBq2X4qDURa 9Jgwu4pwAfCkcXWBR2N8dyTHDZJYFP5uZa5GYnXhF2aujuWTWE5emzys6AtdqXwcq1BI qHgTkcztTFsOzD6J5L8Et01vcHU1q0Ilhy+3bVyHCR5aFKj0rBO91pI3XPoNuACuzIOV MyYQ== X-Gm-Message-State: AOAM530oWItJAepqWhQv2Hgfs/CfuZGN1z1xvvYBCGWpEel+uOyR/AYP H1+uBTxPltOLy2eVQ3FAi9Az2w== X-Received: by 2002:a4a:5dc6:: with SMTP id w189mr8872969ooa.1.1626463860763; Fri, 16 Jul 2021 12:31:00 -0700 (PDT) Received: from smtpclient.apple ([2600:1700:42f0:6600:ec90:c991:5957:a3db]) by smtp.gmail.com with ESMTPSA id w2sm603139oon.0.2021.07.16.12.30.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jul 2021 12:30:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: [RESEND PATCH v2] hfsplus: prevent negative dentries when casefolded From: Viacheslav Dubeyko In-Reply-To: <20210716073635.1613671-1-cccheng@synology.com> Date: Fri, 16 Jul 2021 12:30:56 -0700 Cc: Linux FS Devel , LKML , Al Viro , Andrew Morton , gustavoars@kernel.org, gregkh@linuxfoundation.org, keescook@chromium.org, mszeredi@redhat.com Content-Transfer-Encoding: quoted-printable Message-Id: <02B9566C-A78E-42FB-924B-A503E4BC6D2F@dubeyko.com> References: <20210716073635.1613671-1-cccheng@synology.com> To: Chung-Chiang Cheng X-Mailer: Apple Mail (2.3654.100.0.2.22) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jul 16, 2021, at 12:36 AM, Chung-Chiang Cheng = wrote: >=20 > hfsplus uses the case-insensitive filenames by default, but VFS = negative > dentries are incompatible with case-insensitive. For example, the > following instructions will get a cached filename 'aaa' which isn't > expected. There is no such problem in macOS. >=20 > touch aaa > rm aaa > touch AAA >=20 > This patch takes the same approach to drop negative dentires as vfat = does. > The dentry is revalidated without blocking and storing to the dentry, > and should be safe in rcu-walk. >=20 > Signed-off-by: Chung-Chiang Cheng > --- > fs/hfsplus/hfsplus_fs.h | 1 + > fs/hfsplus/inode.c | 1 + > fs/hfsplus/unicode.c | 32 ++++++++++++++++++++++++++++++++ > 3 files changed, 34 insertions(+) >=20 > diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h > index 1798949f269b..4ae7f1ca1584 100644 > --- a/fs/hfsplus/hfsplus_fs.h > +++ b/fs/hfsplus/hfsplus_fs.h > @@ -520,6 +520,7 @@ int hfsplus_asc2uni(struct super_block *sb, struct = hfsplus_unistr *ustr, > int hfsplus_hash_dentry(const struct dentry *dentry, struct qstr = *str); > int hfsplus_compare_dentry(const struct dentry *dentry, unsigned int = len, > const char *str, const struct qstr *name); > +int hfsplus_revalidate_dentry(struct dentry *dentry, unsigned int = flags); >=20 > /* wrapper.c */ > int hfsplus_submit_bio(struct super_block *sb, sector_t sector, void = *buf, > diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c > index 6fef67c2a9f0..4188a0760118 100644 > --- a/fs/hfsplus/inode.c > +++ b/fs/hfsplus/inode.c > @@ -179,6 +179,7 @@ const struct address_space_operations hfsplus_aops = =3D { > const struct dentry_operations hfsplus_dentry_operations =3D { > .d_hash =3D hfsplus_hash_dentry, > .d_compare =3D hfsplus_compare_dentry, > + .d_revalidate =3D hfsplus_revalidate_dentry, > }; >=20 > static void hfsplus_get_perms(struct inode *inode, > diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c > index 73342c925a4b..e336631334eb 100644 > --- a/fs/hfsplus/unicode.c > +++ b/fs/hfsplus/unicode.c > @@ -10,6 +10,7 @@ > */ >=20 > #include > +#include > #include > #include "hfsplus_fs.h" > #include "hfsplus_raw.h" > @@ -518,3 +519,34 @@ int hfsplus_compare_dentry(const struct dentry = *dentry, > return 1; > return 0; > } > + > +int hfsplus_revalidate_dentry(struct dentry *dentry, unsigned int = flags) > +{ What=E2=80=99s about this code? If (flags & LOOKUP_RCU) return -ECHILD; Do we really need to miss it here? Thanks, Slava. > + /* > + * dentries are always valid when disabling casefold. > + */ > + if (!test_bit(HFSPLUS_SB_CASEFOLD, = &HFSPLUS_SB(dentry->d_sb)->flags)) > + return 1; > + > + /* > + * Positive dentries are valid when enabling casefold. > + * > + * Note, rename() to existing directory entry will have = ->d_inode, and > + * will use existing name which isn't specified name by user. > + * > + * We may be able to drop this positive dentry here. But = dropping > + * positive dentry isn't good idea. So it's unsupported like > + * rename("filename", "FILENAME") for now. > + */ > + if (d_really_is_positive(dentry)) > + return 1; > + > + /* > + * Drop the negative dentry, in order to make sure to use the = case > + * sensitive name which is specified by user if this is for = creation. > + */ > + if (flags & (LOOKUP_CREATE | LOOKUP_RENAME_TARGET)) > + return 0; > + > + return 1; > +} > --=20 > 2.25.1 >=20