Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3517095pxv; Mon, 19 Jul 2021 02:04:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKfiN6+UA8ShdQg11t7TdEazOP1PFPa6CR6UezTAA8r6w68UgZA2VUynpdOYEaImaJPTly X-Received: by 2002:a92:2a10:: with SMTP id r16mr15744066ile.223.1626685468595; Mon, 19 Jul 2021 02:04:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626685468; cv=none; d=google.com; s=arc-20160816; b=d7EEyrUxR/3bVuAFNy/ugYqxM43K2UsbSoMFrUVRR+3Qymcmdi+uxCONBZwDMEng/5 ixFKl0V1feXPXCaInbI5FmzH2zjT0u5tsd8I073UTyUaBY5JhOoq8leyYoxqDIcddMO4 G/ncorO6QC4OYhRyBTJgvvKlaZ+FbtRLbmVI5KF9X1bcApY3BeG6CJk7waTMUi1sdNm6 Y9vBkNzl5W1NzfpBrKdlcLpDTlqwlDHEaZKWWP75eBgMjBF9RZvDNCzQMtCBFBojcycU wX5iqSxAhfY1w9t767J+sezz02zowMOOTZ7/3usCaVhDXA6+YoneZDf3ICKmei91AA+2 9S5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:date:message-id:from:references:cc:to :dkim-signature:subject; bh=1sQnLLakPFoxGFTZgwA3rJYQO4JDT4aKxqjuQHtBZa0=; b=rnVwQ61i/98H6+loMw86Y9b9TP8bFttpsYRaoGJbN6ctEcStPB5ql+0f0SZpe4zhQq 9z/JiN9wl6RrxZ1AnzzpOg3Wwf+DaOwIJ4umyWQMOOn4nTpcs2i5Bw4pnPoGaBcEfVt3 4UEaBo7G47AU5kCH+cfoAb7skFMKLB+79DYIJMveCW4nMGzJjWie+Z613lOFs1YZnGXu VD2LO7L0O9pvypzKR/i/B+Nsk9A6OPnUlgd3L0fJvCSUnR/MfVDyv+mjTL5Bo52X3PIX UwHE4/iR/Zt8SSsZ9yrhcGX3ZClcYvUTZd6Cw8imuIx+AKvpvE32TqBHdjuks5xTEnwe lVTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@synology.com header.s=123 header.b="P/+x438M"; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=synology.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t15si18711002ilg.47.2021.07.19.02.04.16; Mon, 19 Jul 2021 02:04:28 -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=@synology.com header.s=123 header.b="P/+x438M"; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=synology.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235646AbhGSIXK (ORCPT + 99 others); Mon, 19 Jul 2021 04:23:10 -0400 Received: from mail.synology.com ([211.23.38.101]:32806 "EHLO synology.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S235498AbhGSIXJ (ORCPT ); Mon, 19 Jul 2021 04:23:09 -0400 Subject: Re: [RESEND PATCH v2] hfsplus: prevent negative dentries when casefolded DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synology.com; s=123; t=1626685428; bh=nrLeIo3KdjKJ3knzH46N/b/L2z/5UVOq0EeQ1Fo8DU0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=P/+x438MJ0hx/dzk6G6PB75DxBzAzn4P/QnJWOY1jTGjHRDDvcPxBC0B80YiZSuzL KiP/a3GgRsXI+BY3bryY1szsYl2nk5AwPcfaWZhXbE9HN1DJiInDlLHyPvZZDnq/19 WGggKzqDt5FvIreyh8/qvLLICGvyxhOAZ8L30QUE= To: Viacheslav Dubeyko Cc: Linux FS Devel , LKML , Al Viro , Andrew Morton , gustavoars@kernel.org, gregkh@linuxfoundation.org, keescook@chromium.org, mszeredi@redhat.com, shepjeng@gmail.com References: <20210716073635.1613671-1-cccheng@synology.com> <02B9566C-A78E-42FB-924B-A503E4BC6D2F@dubeyko.com> From: Chung-Chiang Cheng Message-ID: Date: Mon, 19 Jul 2021 17:03:45 +0800 MIME-Version: 1.0 In-Reply-To: <02B9566C-A78E-42FB-924B-A503E4BC6D2F@dubeyko.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Synology-MCP-Status: no X-Synology-Spam-Flag: no X-Synology-Spam-Status: score=0, required 6, WHITELIST_FROM_ADDRESS 0 X-Synology-Virus-Status: no Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This function revalidates dentries without blocking and storing to the dentry. As the document mentioned [1], I think it's safe in rcu-walk mode. I also found jfs_ci_revalidate() takes the same approach.         d_revalidate may be called in rcu-walk mode (flags & LOOKUP_RCU).         If in rcu-walk mode, the filesystem must revalidate the dentry without         blocking or storing to the dentry, d_parent and d_inode should not be         used without care (because they can change and, in d_inode case, even         become NULL under us [1] https://www.kernel.org/doc/Documentation/filesystems/vfs.txt Thanks, C.C.Cheng >> + >> +int hfsplus_revalidate_dentry(struct dentry *dentry, unsigned int flags) >> +{ > What’s 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; >> +} >> -- >> 2.25.1 >>