Hi Petr
> -----Original Message-----
> From: Petr Mladek <pmladek@xxxxxxxx>
> Sent: Thursday, June 24, 2021 5:02 PM
> To: Justin He <Justin.He@xxxxxxx>
> Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>; Sergey Senozhatsky
> <senozhatsky@xxxxxxxxxxxx>; Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx>; Rasmus Villemoes
> <linux@xxxxxxxxxxxxxxxxxx>; Jonathan Corbet <corbet@xxxxxxx>; Alexander
> Viro <viro@xxxxxxxxxxxxxxxxxx>; Linus Torvalds <torvalds@linux-
> foundation.org>; 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 v2 2/4] lib/vsprintf.c: make '%pD' print the full path
> of file
>
> On Wed 2021-06-23 13:50:09, Jia He wrote:
> > Previously, the specifier '%pD' is for printing dentry name of struct
> > file. It may not be perfect (by default it only prints one component.)
> >
> > As suggested by Linus [1]:
> > > A dentry has a parent, but at the same time, a dentry really does
> > > inherently have "one name" (and given just the dentry pointers, you
> > > can't show mount-related parenthood, so in many ways the "show just
> > > one name" makes sense for "%pd" in ways it doesn't necessarily for
> > > "%pD"). But while a dentry arguably has that "one primary component",
> > > a _file_ is certainly not exclusively about that last component.
> >
> > Hence change the behavior of '%pD' to print the full path of that file.
> >
> > If someone invokes snprintf() with small but positive space,
> > prepend_name_with_len() moves or truncates the string partially.
>
> Does this comment belong to the 1st patch?
> prepend_name_with_len() is not called in this patch.
>
Tend to remove this paragraph since the comments in do_path_unsafe (patch1/4)
was clear enough.
> > More
> > than that, kasprintf() will pass NULL @buf and @end as the parameters,
> > and @end - @buf can be negative in some case. Hence make it return at
> > the very beginning with false in these cases.
>
> Same here. file_d_path_name() does not return bool.
>
> Well, please mention in the commit message that %pD uses the entire
> given buffer as a scratch space. It might write something behind
> the trailing '\0'.
>
> It would make sense to warn about this also in
> Documentation/core-api/printk-formats.rst. It is a bit non-standard
> behavior.
>
Okay
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index f0c35d9b65bf..f4494129081f 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -920,13 +921,44 @@ char *dentry_name(char *buf, char *end, const
> struct dentry *d, struct printf_sp
> > }
> >
> > static noinline_for_stack
> > -char *file_dentry_name(char *buf, char *end, const struct file *f,
> > +char *file_d_path_name(char *buf, char *end, const struct file *f,
> > struct printf_spec spec, const char *fmt)
> > {
> > + char *p;
> > + const struct path *path;
> > + int prepend_len, widen_len, dpath_len;
> > +
> > if (check_pointer(&buf, end, f, spec))
> > return buf;
> >
> > - return dentry_name(buf, end, f->f_path.dentry, spec, fmt);
> > + path = &f->f_path;
> > + if (check_pointer(&buf, end, path, spec))
> > + return buf;
> > +
> > + p = d_path_unsafe(path, buf, end - buf, &prepend_len);
> > +
> > + /* Calculate the full d_path length, ignoring the tail '\0' */
> > + dpath_len = end - buf - prepend_len - 1;
> > +
> > + widen_len = max_t(int, dpath_len, spec.field_width);
> > +
> > + /* Case 1: Already started past the buffer. Just forward @buf. */
> > + if (buf >= end)
> > + return buf + widen_len;
> > +
> > + /*
> > + * Case 2: The entire remaining space of the buffer filled by
> > + * the truncated path. Still need to get moved right when
> > + * the filled width is greather than the full path length.
>
> s/filled/field/ ?
>
Ah, sorry, I changed it. I would have thought it as a typo 😊
--
Cheers,
Justin (Jia He)
