Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1728414pxb; Fri, 1 Oct 2021 18:22:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxqL3VDr2Ofad/3BGhuc/WqEo+GJzzfbctCA5WsTRQlXU0QBiOCoU8JVFU2W2rIEC9s81II X-Received: by 2002:a63:6f02:: with SMTP id k2mr908323pgc.396.1633137724452; Fri, 01 Oct 2021 18:22:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633137724; cv=none; d=google.com; s=arc-20160816; b=L5AS3D+UJNptODLluwnX40wFcf0KAKKUl3uHGDBo/YwdJnOJBEFtgMW7PqVhl/Bexl z/oPdA5yxQAh4XfcJ6cs1zpUvO8OehbI7VRBLER/6QWXkwKx6FZEJttdAZACngLjXm9c dFWgJZCI7G5hTd5Xf6rPBB4hfW+rfV7PtnjRFg3A/611/zYfW9f2/doeP7SiprL3tCyJ 7hJ0AEWXi/jOI8vF5uXMKa0H5zfZNFiss/MJGNamyWdmnpyOIoj3Zcn0W/kOw0qNOcl/ PMrFEa5VeqF3zojwTnBySg7GZTarm/1W1tT7GhruybPWbiCo6Tc/CjskDVJr97Dtf2y7 bsfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=B9cbtwRP5VtO1T1peIYyTpwCIWK2Eig/SC5ktdxEYKk=; b=pEs/kMOCFu1QiFkjrs9VouBgEoZPAJo1HpTyFxfbXp0Pz1KKy1iNp6qEbiOlZpCNkb ds3LJNe04Wb8r7y0I+Sd79ncDo5eNDUxiLhLYO43fO2yzzv52xICoob6wfeweSrjLYpE fFrgdt0CjtG8+mP9Cg4RYdrliUQoGIq5XU1llj5ANjthipq/W/pIRVt2BCNvrs7/b4x5 aR9LMhBbLTec8dbV1SABxaLEHqQ7yu4Kv2OtJMerRrKYFKKwWQtusCFgAulEPxKAsn+3 UZF7krn82kdeAbxO3W7aC2y2S0pKQ4FVL57lpJCs5ErbfpPDXY65xyBskWXwhRwqxhR4 IwQw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i12si6126256pju.143.2021.10.01.18.21.45; Fri, 01 Oct 2021 18:22:04 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231904AbhJBBXZ (ORCPT + 99 others); Fri, 1 Oct 2021 21:23:25 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:57991 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S230255AbhJBBXZ (ORCPT ); Fri, 1 Oct 2021 21:23:25 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1921LXju001968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Oct 2021 21:21:34 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id BB75015C34AA; Fri, 1 Oct 2021 21:21:33 -0400 (EDT) Date: Fri, 1 Oct 2021 21:21:33 -0400 From: "Theodore Ts'o" To: Gabriel Krisman Bertazi Cc: Shreeya Patel , 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 2/2] fs: ext4: Fix the inconsistent name exposed by /proc/self/cwd Message-ID: References: <8402d1c99877a4fcb152de71005fa9cfb25d86a8.1632909358.git.shreeya.patel@collabora.com> <8735pk5zml.fsf@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8735pk5zml.fsf@collabora.com> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri, Oct 01, 2021 at 03:11:30PM -0400, Gabriel Krisman Bertazi wrote: > > The dcache name is exposed in more places, like /proc/mounts. We have a > bug reported against flatpak where its initialization code bind mounts a > directory that was previously touched with a different case combination, > and then checks /proc/mounts in a case-sensitive way to see if the mount > succeeded. This code now regresses on CI directories because the name > it asked to bind mount is not found in /proc/mounts. Ah, thanks for the context. That makes sense. > I think the more reasonable approach is to save the disk exact name on > the dcache, because that is the only version that doesn't change based > on who won the race for the first lookup. What about the alternative of storing the casefolded name? The advantage of using the casefolded name is that we can always casefold the name, where as in the case of a negative dentry, there is no disk exact name to use (since by definition there is no on-disk name). - Ted