linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Jia He <justin.he@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Jonathan Corbet <corbet@lwn.net>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Al Viro <viro@ftp.linux.org.uk>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Ira Weiny <ira.weiny@intel.com>,
	Eric Biggers <ebiggers@google.com>,
	"Ahmed S. Darwish" <a.darwish@linutronix.de>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC 2/3] lib/vsprintf.c: make %pD print full path for file
Date: Mon, 10 May 2021 15:04:57 +0200	[thread overview]
Message-ID: <YJkveb46BoFbXi0q@alley> (raw)
In-Reply-To: <20210508122530.1971-3-justin.he@arm.com>

On Sat 2021-05-08 20:25:29, Jia He wrote:
> We have '%pD' for printing a filename. It may not be perfect (by
> default it only prints one component.)
> 
> As suggested by Linus at [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 "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
> different from a name standpoint.
> 
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index f0c35d9b65bf..8220ab1411c5 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -27,6 +27,7 @@
>  #include <linux/string.h>
>  #include <linux/ctype.h>
>  #include <linux/kernel.h>
> +#include <linux/dcache.h>
>  #include <linux/kallsyms.h>
>  #include <linux/math64.h>
>  #include <linux/uaccess.h>
> @@ -923,10 +924,17 @@ static noinline_for_stack
>  char *file_dentry_name(char *buf, char *end, const struct file *f,
>  			struct printf_spec spec, const char *fmt)
>  {
> +	const struct path *path = &f->f_path;

This dereferences @f before it is checked by check_pointer().

> +	char *p;
> +	char tmp[128];
> +
>  	if (check_pointer(&buf, end, f, spec))
>  		return buf;
>  
> -	return dentry_name(buf, end, f->f_path.dentry, spec, fmt);
> +	p = d_path_fast(path, (char *)tmp, 128);
> +	buf = string(buf, end, p, spec);

Is 128 a limit of the path or just a compromise, please?

d_path_fast() limits the size of the buffer so we could use @buf
directly. We basically need to imitate what string_nocheck() does:

     + the length is limited by min(spec.precision, end-buf);
     + the string need to get shifted by widen_string()

We already do similar thing in dentry_name(). It might look like:

char *file_dentry_name(char *buf, char *end, const struct file *f,
			struct printf_spec spec, const char *fmt)
{
	const struct path *path;
	int lim, len;
	char *p;

	if (check_pointer(&buf, end, f, spec))
		return buf;

	path = &f->f_path;
	if (check_pointer(&buf, end, path, spec))
		return buf;

	lim = min(spec.precision, end - buf);
	p = d_path_fast(path, buf, lim);
	if (IS_ERR(p))
		return err_ptr(buf, end, p, spec);

	len = strlen(buf);
	return widen_string(buf + len, len, end, spec);
}

Note that the code is _not_ even compile tested. It might include
some ugly mistake.

> +
> +	return buf;
>  }
>  #ifdef CONFIG_BLOCK
>  static noinline_for_stack
> @@ -2296,7 +2304,7 @@ early_param("no_hash_pointers", no_hash_pointers_enable);
>   * - 'a[pd]' For address types [p] phys_addr_t, [d] dma_addr_t and derivatives
>   *           (default assumed to be phys_addr_t, passed by reference)
>   * - 'd[234]' For a dentry name (optionally 2-4 last components)
> - * - 'D[234]' Same as 'd' but for a struct file
> + * - 'D' Same as 'd' but for a struct file

It is not really the same. We should make it clear that it prints
the full path:

+   * - 'D' Same as 'd' but for a struct file; prints full path with
+       the mount-related parenthood

>   * - 'g' For block_device name (gendisk + partition number)
>   * - 't[RT][dt][r]' For time and date as represented by:
>   *      R    struct rtc_time
> -- 
> 2.17.1

Best Regards,
Petr

  parent reply	other threads:[~2021-05-10 13:38 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08 12:25 [PATCH RFC 0/3] make '%pD' print full path for file Jia He
2021-05-08 12:25 ` [PATCH RFC 1/3] fs: introduce helper d_path_fast() Jia He
2021-05-08 15:30   ` Linus Torvalds
2021-05-08 19:13     ` Al Viro
2021-05-08 20:39       ` Linus Torvalds
2021-05-08 21:05         ` Al Viro
2021-05-08 22:17           ` Linus Torvalds
2021-05-08 22:46             ` Al Viro
2021-05-08 22:48               ` Linus Torvalds
2021-05-08 23:15               ` Al Viro
2021-05-08 23:18                 ` Al Viro
2021-05-09 22:58                 ` Eric W. Biederman
2021-05-10 12:51                   ` Christian Brauner
2021-05-10  7:20                 ` Christian Brauner
2021-05-08 22:42           ` Linus Torvalds
2021-05-08 22:47             ` Linus Torvalds
2021-05-09  2:28               ` Al Viro
2021-05-09  2:53                 ` Linus Torvalds
2021-05-19  0:43                   ` [PATCHSET] d_path cleanups Al Viro
2021-05-19  0:48                     ` [PATCH 01/14] d_path: "\0" is {0,0}, not {0} Al Viro
2021-05-19  0:48                       ` [PATCH 02/14] d_path: saner calling conventions for __dentry_path() Al Viro
2021-06-25  9:32                         ` Justin He
2021-07-07  4:52                           ` Justin He
2021-05-19  0:48                       ` [PATCH 03/14] d_path: regularize handling of root dentry in __dentry_path() Al Viro
2021-07-07  4:50                         ` Justin He
2021-05-19  0:48                       ` [PATCH 04/14] d_path: get rid of path_with_deleted() Al Viro
2021-05-19  0:48                       ` [PATCH 05/14] getcwd(2): saner logics around prepend_path() call Al Viro
2021-07-07  7:41                         ` Justin He
2021-05-19  0:48                       ` [PATCH 06/14] d_path: don't bother with return value of prepend() Al Viro
2021-06-24  6:13                         ` Justin He
2021-05-19  0:48                       ` [PATCH 07/14] d_path: lift -ENAMETOOLONG handling into callers of prepend_path() Al Viro
2021-06-25  9:18                         ` Justin He
2021-06-28  5:20                           ` Justin He
2021-05-19  0:48                       ` [PATCH 08/14] d_path: make prepend_name() boolean Al Viro
2021-05-20  9:12                         ` Justin He
2021-05-20  9:19                           ` Andy Shevchenko
2021-05-20 14:53                           ` Petr Mladek
2021-05-20 19:35                             ` Al Viro
2021-07-07  7:43                         ` Justin He
2021-05-19  0:48                       ` [PATCH 09/14] d_path: introduce struct prepend_buffer Al Viro
2021-06-23 13:28                         ` Justin He
2021-06-24  9:29                           ` Enrico Weigelt, metux IT consult
2021-06-25  0:43                             ` Justin He
2021-06-28 16:42                               ` Enrico Weigelt, metux IT consult
2021-06-28 17:10                                 ` Andy Shevchenko
2021-05-19  0:48                       ` [PATCH 10/14] d_path: prepend_path(): get rid of vfsmnt Al Viro
2021-05-19  0:48                       ` [PATCH 11/14] d_path: prepend_path(): lift resetting b in case when we'd return 3 out of loop Al Viro
2021-05-19  0:48                       ` [PATCH 12/14] d_path: prepend_path(): lift the inner loop into a new helper Al Viro
2021-05-19  8:07                         ` Andy Shevchenko
2021-05-19 15:55                           ` Al Viro
2021-07-07  7:52                         ` Justin He
2021-05-19  0:49                       ` [PATCH 13/14] d_path: prepend_path() is unlikely to return non-zero Al Viro
2021-06-25  8:00                         ` Justin He
2021-06-25 17:58                           ` Al Viro
2021-06-28  3:28                             ` Justin He
2021-06-28  4:14                               ` Al Viro
2021-06-28  4:36                                 ` Justin He
2021-06-28  4:37                         ` Justin He
2021-05-19  0:49                       ` [PATCH 14/14] getcwd(2): clean up error handling Al Viro
2021-07-07  8:03                         ` Justin He
2021-06-24  6:05                       ` [PATCH 01/14] d_path: "\0" is {0,0}, not {0} Justin He
2021-05-19  2:39                     ` [PATCHSET] d_path cleanups Linus Torvalds
2021-06-22 14:00                     ` Justin He
2021-05-09  2:20         ` [PATCH RFC 1/3] fs: introduce helper d_path_fast() Al Viro
2021-05-09  4:58           ` Al Viro
2021-05-10 16:16           ` Eric W. Biederman
2021-05-10 15:07         ` Justin He
2021-05-10 17:03           ` Linus Torvalds
2021-05-08 12:25 ` [PATCH RFC 2/3] lib/vsprintf.c: make %pD print full path for file Jia He
2021-05-10  3:46   ` Sergey Senozhatsky
2021-05-10 13:04   ` Petr Mladek [this message]
2021-05-10 14:25     ` Justin He
2021-05-27  7:20     ` Justin He
2021-05-27  9:14       ` Petr Mladek
2021-05-08 12:25 ` [PATCH RFC 3/3] s390/hmcdrv: remove the redundant directory path in debug message Jia He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YJkveb46BoFbXi0q@alley \
    --to=pmladek@suse.com \
    --cc=a.darwish@linutronix.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=borntraeger@de.ibm.com \
    --cc=corbet@lwn.net \
    --cc=darrick.wong@oracle.com \
    --cc=ebiederm@xmission.com \
    --cc=ebiggers@google.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=ira.weiny@intel.com \
    --cc=justin.he@arm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ftp.linux.org.uk \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).