linux-kernel - Re: [GIT PULL] iomap: new code for 5.13-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m135v7y5c5.fsf@fess.ebiederm.org>
Date:   Fri, 30 Apr 2021 13:50:34 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Rasmus Villemoes <linux@...musvillemoes.dk>,
        Christoph Hellwig <hch@....de>,
        "Darrick J. Wong" <djwong@...nel.org>, Jia He <justin.he@....com>,
        Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        Dave Chinner <david@...morbit.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Eric Sandeen <sandeen@...deen.net>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [GIT PULL] iomap: new code for 5.13-rc1

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Wed, Apr 28, 2021 at 11:40 PM Rasmus Villemoes
> <linux@...musvillemoes.dk> wrote:
>>
>> > That also does explain the arguably odd %pD defaults: %pd came first,
>> > and then %pD came afterwards.
>>
>> Eh? 4b6ccca701ef5977d0ffbc2c932430dea88b38b6 added them both at the same
>> time.
>
> Ahh, I looked at "git blame", and saw that file_dentry_name() was
> added later. But that turns out to have been an additional fix on top,
> not actually "later support".
>
> Looking more at that code, I am starting to think that
> "file_dentry_name()" simply shouldn't use "dentry_name()" at all.
> Despite that shared code origin, and despite that similar letter
> choice (lower-vs-upper case), a dentry and a file really are very very
> different from a name standpoint.
>
> And it's not the "a filename is the whale pathname, and a dentry has
> its own private dentry name" issue. It's really that the 'struct file'
> contains a _path_ - which is not just the dentry pointer, but the
> 'struct vfsmount' pointer too.
>
> So '%pD' really *could* get the real path right (because it has all
> the required information) in ways that '%pd' fundamentally cannot.
>
> At the same time, I really don't like printk specifiers to take any
> real locks (ie mount_lock or rename_lock), so I wouldn't want them to
> use the full  d_path() logic.

Well prepend_path the core of d_path, which is essentially the logic
I think you are suggesting to use does:
read_seqbegin_or_lock(&mount_lock, ...);
read_seqbegin_or_lock(&rename_lock, ...);

A printk specific variant could easily be modified to always restart or
to simply ignore renames and changes to the mount tree.  There are
always the corner cases when there is no sensible full path to display.
A rename or a mount namespace operation could be handled like one of
those.

Eric