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: <AM6PR08MB4376E39649192846F644E785F7069@AM6PR08MB4376.eurprd08.prod.outlook.com>
Date:   Fri, 25 Jun 2021 02:29:38 +0000
From:   Justin He <Justin.He@....com>
To:     Petr Mladek <pmladek@...e.com>
CC:     Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Jonathan Corbet <corbet@....net>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Eric Biggers <ebiggers@...gle.com>,
        "Ahmed S. Darwish" <a.darwish@...utronix.de>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Christoph Hellwig <hch@...radead.org>, nd <nd@....com>
Subject: RE: [PATCH v2 2/4] lib/vsprintf.c: make '%pD' print the full path of
 file

Hi Petr

> -----Original Message-----
> From: Petr Mladek <pmladek@...e.com>
> Sent: Thursday, June 24, 2021 5:02 PM
> To: Justin He <Justin.He@....com>
> Cc: Steven Rostedt <rostedt@...dmis.org>; Sergey Senozhatsky
> <senozhatsky@...omium.org>; Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com>; Rasmus Villemoes
> <linux@...musvillemoes.dk>; Jonathan Corbet <corbet@....net>; Alexander
> Viro <viro@...iv.linux.org.uk>; Linus Torvalds <torvalds@...ux-
> foundation.org>; Peter Zijlstra (Intel) <peterz@...radead.org>; Eric
> Biggers <ebiggers@...gle.com>; Ahmed S. Darwish <a.darwish@...utronix.de>;
> linux-doc@...r.kernel.org; linux-kernel@...r.kernel.org; linux-
> fsdevel@...r.kernel.org; Matthew Wilcox <willy@...radead.org>; Christoph
> Hellwig <hch@...radead.org>; nd <nd@....com>
> 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)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ