Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1471251pxb; Fri, 1 Oct 2021 11:17:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwn5fTiDfIIohn6TTVyXgU1AW6VUiidstQSzop3YBumNynHE7+LvJBYIJ1q6cgpsFoNeCCw X-Received: by 2002:a62:3896:0:b0:44c:21a0:3ec with SMTP id f144-20020a623896000000b0044c21a003ecmr2344155pfa.29.1633112241826; Fri, 01 Oct 2021 11:17:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633112241; cv=none; d=google.com; s=arc-20160816; b=IZv2X4s3r99se4u6/8klvzbyo5EC9lwo3aXUrEFVZY5x8J/KOaKxxD4zpRPZLd/b48 lsl8XJw2iF2VTP2fV9ymD99+P3xvL/wQKJqJBXIHkRGdnKNb+V5ppo/zq8Op3OnH3/J+ a4f5JmpnaNXVDO3fS6QVj/7QHZmOeRSC0eAmmxgg4lW5mZKOieqLWsSWKLjx8Mn877NL +MZ0GRcLHBgLOh+/Fh3l2hBJEKQ7FOfJb7HNWs88t9PfFmXi+eyvyZn9rnA9RlHtlriK 1spe+mYtK4f6zOlAxIZtZ+2sVQRvzrbJnDnRwghme/R32EC46W0vgZTqOQiCvhiFvHtH CZmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:organization:subject:cc:to:from; bh=dua5EMttz2zPocog6sd9XmhtY2PFwq/mDW8N6i28rg8=; b=kUnBnGPBQlMRytTMzZK9ieUxFtmMg/Inu/rSVtazz5twEZ720+myIxxO1jeTdI7rNm yTLl6Y45l23KUgbjgwu9uWITxqZgWco5aXP2QKqUojLJAyi92jZkZSnTQdDnFlavWlUB J3Zg5hoCSihTcCU/6YartcENHziM8w5P9e0PNe0EkP3Di3+6ZQTp9uZnAG3QZkveSiIZ h/rOfMtZ7sbyizN0K6SqAH92wk4pSMpdW3upwlUjvXJA4R+V7H+Rhbfn7skMvqszo69f D+Njt27dg7L7nRaZ6VH3V/fDFsS6FuSCgycs3wm6IvzqAgvU8NEHb/Mu5JVpN3EVfP6U nwMw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id br16si8197010pjb.155.2021.10.01.11.16.54; Fri, 01 Oct 2021 11:17:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355667AbhJASSe (ORCPT + 99 others); Fri, 1 Oct 2021 14:18:34 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:48506 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229755AbhJASSe (ORCPT ); Fri, 1 Oct 2021 14:18:34 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 4FC621F42460 From: Gabriel Krisman Bertazi To: Shreeya Patel Cc: tytso@mit.edu, viro@zeniv.linux.org.uk, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@collabora.com Subject: Re: [PATCH 0/2] Handle a soft hang and the inconsistent name issue Organization: Collabora References: Date: Fri, 01 Oct 2021 14:16:45 -0400 In-Reply-To: (Shreeya Patel's message of "Wed, 29 Sep 2021 16:23:37 +0530") Message-ID: <87ee94625u.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Shreeya Patel writes: > When d_add_ci is called from the fs layer, we face a soft hang which is > caused by the deadlock in d_alloc_parallel. First patch in the series > tries to resolve it by doing a case-exact match instead of the > case-inexact match done by d_same_name function. Hi Shreeya, I understand what you are trying to solve here, but this could use some clarification. There is no such deadlock in the upstream code base, since d_add_ci is never called by a file system with a d_compare hook that causes the issue. Patch 02/02 will be the first to include such path, to address the /proc/self/cwd leakage, therefore, Patch 01/02 is done in preparation of that patch. That needs to be clearly stated here. Originally, the 'native', per-directory case-insensitive implementation merged in ext4/f2fs stores the case of the first lookup on the dcache, regardless of the disk exact file name case. This is intended as an internal implementation detail, that shouldn't be leaked to userspace. Whenever the kernel returns a name to userspace it should be the exact name, as written on disk. But, on /proc/self/cwd, the internal name is leaked to userspace. The goal of the series is *solely* to fix the leakage of this implementation detail to userspace. I think the solution is in the right direction, but I see some issues on the implementation I'm discussing inline. > The second patch resolves the inconsistent name that is exposed by >/proc/self/cwd in case of a case-insensitive filesystem. >/proc/self/cwd uses the dentry name stored in dcache. Since the dcache >is populated only on the first lookup, with the string used in that >lookup, cwd will have an unexpected case, depending on how the data was >first looked-up in a case-insesitive filesystem. > > > Shreeya Patel (2): > fs: dcache: Handle case-exact lookup in d_alloc_parallel > fs: ext4: Fix the inconsistent name exposed by /proc/self/cwd > > fs/dcache.c | 20 ++++++++++++++++++-- > fs/ext4/namei.c | 13 +++++++++++++ > 2 files changed, 31 insertions(+), 2 deletions(-) -- Gabriel Krisman Bertazi