RE: [PATCH v2 2/4] lib/vsprintf.c: make '%pD' print the full path of file

[Justin He]

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)