RE: [GIT PULL] iomap: new code for 5.13-rc1

[Justin He <Justin.He@arm.com>]

Hi

> -----Original Message-----
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Sent: Friday, April 30, 2021 12:46 AM
> To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Cc: Christoph Hellwig <hch@lst.de>; Darrick J. Wong <djwong@kernel.org>;
> Justin He <Justin.He@arm.com>; Al Viro <viro@zeniv.linux.org.uk>; linux-
> fsdevel <linux-fsdevel@vger.kernel.org>; linux-xfs <linux-
> xfs@vger.kernel.org>; Dave Chinner <david@fromorbit.com>; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>; Eric Sandeen
> <sandeen@sandeen.net>; Andy Shevchenko <andy.shevchenko@gmail.com>
> Subject: Re: [GIT PULL] iomap: new code for 5.13-rc1
>
> On Wed, Apr 28, 2021 at 11:40 PM Rasmus Villemoes
> <linux@rasmusvillemoes.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.

Is it a good idea to introduce a new d_path_nolock() for file_dentry_name()?
In d_path_nolock(), if it detects that there is conflicts with mount_lock
or rename_lock, then returned NULL as a name of that vfsmount?

Thanks for further suggestion.

--
Cheers,
Justin (Jia He)


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.