Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp692336pxa; Tue, 11 Aug 2020 12:32:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycPJAG7G4PGm3wbfkN1XecYy5Kk28sEs6082CcDeZEKFpwGf+cvF1NfO7bc3cSCWf9coEo X-Received: by 2002:a50:d75e:: with SMTP id i30mr28634982edj.246.1597174350757; Tue, 11 Aug 2020 12:32:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597174350; cv=none; d=google.com; s=arc-20160816; b=UJjIKac/nC81Ip1WZsu8J6jRZzOpnkt4JEZ10i/14qTQT2DphvOh3mDJKMEn40dqi6 9bTr1PfcfFeAM4DtR1/ARoFgI0wX18f5wEj9xd0UDR78/cAuw2wAyGjpXV4nHTELtI6r eXJXBS6nzWHkUkIxPMGGXL2Q8tArtPCL5nC2bo49bm7WIeNjrMr/cAAtQT+BZ3FMPnCl +Ji4dIDn1x03xLG32+gOUg1k93ItK15SdbukHsrNRa0GjBU4qfu7XX+XXyvusnaBlpX0 FtqmmB0cH6YrTvssndZVI1+XJ5xdz7SW4Ry0cMqtAOWAo3gSARku//e9Y2kZnxXsZu4E B/RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=KWVN5NgNHn9g+IaX0S6kKmiFwKzPuR3DecIiX9in4V4=; b=KdriBVasfticLurq/rHKgm37hrp2NdpHrl5O4AXUuc6MkUKCwLoWhBaUtu9Eq3vzjo 1Y2X4tArUQ7vqPnA/91kEWOR93wv0heTiWBjHDIh4oR5hXsjHENzPQ697k+yw+zkehPF NSWxbAqPSx42JexOrR89I8qoMun6ZC/ZH9plKwEJAvtdZN3lWivUyHkoxZ6SW+MBXi0H aOFqadk9xcarcTDjKZmFFsOgcxYuf8+IHO08Z/teBKONbVfHZotV9rVyCVfYQjRO8k6r hcjYRDf8wfBQJoaMmYUerFR/25jRBdCZjYzZdwAV6wNBzJZUkZos/8qm0SoaJqaYTWrm hiHg== ARC-Authentication-Results: i=1; mx.google.com; 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 zh8si11481658ejb.475.2020.08.11.12.32.07; Tue, 11 Aug 2020 12:32:30 -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; 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 S1726454AbgHKTbJ (ORCPT + 99 others); Tue, 11 Aug 2020 15:31:09 -0400 Received: from gardel.0pointer.net ([85.214.157.71]:51136 "EHLO gardel.0pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726068AbgHKTbJ (ORCPT ); Tue, 11 Aug 2020 15:31:09 -0400 Received: from gardel-login.0pointer.net (gardel.0pointer.net [85.214.157.71]) by gardel.0pointer.net (Postfix) with ESMTP id D6BA2E814E3; Tue, 11 Aug 2020 21:31:06 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id 3596D16081D; Tue, 11 Aug 2020 21:31:06 +0200 (CEST) Date: Tue, 11 Aug 2020 21:31:05 +0200 From: Lennart Poettering To: Miklos Szeredi Cc: Linus Torvalds , linux-fsdevel , David Howells , Al Viro , Karel Zak , Jeff Layton , Miklos Szeredi , Nicolas Dichtel , Christian Brauner , Linux API , Ian Kent , LSM , Linux Kernel Mailing List Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information) Message-ID: <20200811193105.GA228302@gardel-login> References: <1845353.1596469795@warthog.procyon.org.uk> <20200811135419.GA1263716@miu.piliscsaba.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Di, 11.08.20 20:49, Miklos Szeredi (miklos@szeredi.hu) wrote: > On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds > wrote: > > > and then people do "$(srctree)/". If you haven't seen that kind of > > pattern where the pathname has two (or sometimes more!) slashes in the > > middle, you've led a very sheltered life. > > Oh, I have. That's why I opted for triple slashes, since that should > work most of the time even in those concatenated cases. And yes, I > know, most is not always, and this might just be hiding bugs, etc... > I think the pragmatic approach would be to try this and see how many > triple slash hits a normal workload gets and if it's reasonably low, > then hopefully that together with warnings for O_ALT would be enough. There's no point. Userspace relies on the current meaning of triple slashes. It really does. I know many places in systemd where we might end up with a triple slash. Here's a real-life example: some code wants to access the cgroup attribute 'cgroup.controllers' of the root cgroup. It thus generates the right path in the fs for it, which is the concatenation of "/sys/fs/cgroup/" (because that's where cgroupfs is mounted), of "/" (i.e. for the root cgroup) and of "/cgroup.controllers" (as that's the file the attribute is exposed under). And there you go: "/sys/fs/cgroup/" + "/" + "/cgroup.controllers" → "/sys/fs/cgroup///cgroup.controllers" This is a real-life thing. Don't break this please. Lennart -- Lennart Poettering, Berlin