RE: [PATCH v7 0/5] make '%pD' print the full path of file

From: Justin He
Date: Wed Aug 04 2021 - 20:39:54 EST


Hi Al

> -----Original Message-----
> From: Petr Mladek <pmladek@xxxxxxxx>
> Sent: Wednesday, July 21, 2021 10:12 PM
> To: Justin He <Justin.He@xxxxxxx>; Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
> Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>; Sergey Senozhatsky
> <senozhatsky@xxxxxxxxxxxx>; Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx>; Rasmus Villemoes
> <linux@xxxxxxxxxxxxxxxxxx>; Jonathan Corbet <corbet@xxxxxxx>; Linus
> Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>; Peter Zijlstra (Intel)
> <peterz@xxxxxxxxxxxxx>; Eric Biggers <ebiggers@xxxxxxxxxx>; Ahmed S.
> Darwish <a.darwish@xxxxxxxxxxxxx>; linux-doc@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx; Matthew Wilcox
> <willy@xxxxxxxxxxxxx>; Christoph Hellwig <hch@xxxxxxxxxxxxx>; nd
> <nd@xxxxxxx>
> Subject: Re: [PATCH v7 0/5] make '%pD' print the full path of file
>
> On Thu 2021-07-15 09:14:02, Jia He wrote:
> > Background
> > ==========
> > Linus suggested printing the full path of file instead of printing
> > the components as '%pd'.
> >
> > Typically, there is no need for printk specifiers to take any real locks
> > (ie mount_lock or rename_lock). So I introduce a new helper
> > d_path_unsafe() which is similar to d_path() except it doesn't take any
> > seqlock/spinlock.
> >
> > TODO
> > ====
> > I plan to do the followup work after '%pD' behavior is changed.
> > - s390/hmcdrv: remove the redundant directory path in printing string.
> > - fs/iomap: simplify the iomap_swapfile_fail() with '%pD'.
> > - simplify the string printing when file_path() is invoked(in some
> > cases, not all).
> > - change the previous '%pD[2,3,4]' to '%pD'
> >
> > Jia He (4):
> > d_path: fix Kernel doc validator complaints
> > d_path: introduce helper d_path_unsafe()
> > lib/vsprintf.c: make '%pD' print the full path of file
> > lib/test_printf.c: add test cases for '%pD'
> >
> > Rasmus Villemoes (1):
> > lib/test_printf.c: split write-beyond-buffer check in two
>
> The patchset is ready for linux-next from my POV.
>
> I could take it via printk tree if Al provides Acks for the
> first two "d_path: *: patches.
>
> Or Al could take it via his tree if he would prefer to do so.

Kindly ping 😉

--
Cheers,
Justin (Jia He)