linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Timur Tabi <timur@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Matthew Wilcox <willy@infradead.org>,
	akpm@linux-foundation.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	roman.fietze@magna.com, Kees Cook <keescook@chromium.org>,
	John Ogness <john.ogness@linutronix.de>,
	akinobu.mita@gmail.com, glider@google.com,
	Andrey Konovalov <andreyknvl@google.com>,
	Marco Elver <elver@google.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Pavel Machek <pavel@ucw.cz>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 3/3] lib/vsprintf: make-printk-non-secret printks all addresses as unhashed
Date: Fri, 12 Feb 2021 12:52:01 +0100	[thread overview]
Message-ID: <YCZr4WrcwfWxVVad@alley> (raw)
In-Reply-To: <ca1371e2-8df3-3e28-b5d6-b4bc0fbe6b70@kernel.org>

Hi,

I have realized that I did not comment the two ideas.

On Wed 2021-02-10 11:27:45, Timur Tabi wrote:
> 
> 
> On 2/10/21 7:41 AM, Petr Mladek wrote:
> > 
> > The option causes that vsprintf() will not hash pointers. Yes, it is
> > primary used by printk(). But it is used also in some other
> > interfaces, especially trace_printk(), seq_buf() API. The naked
> > pointers might appear more or less anywhere, including procfs,
> > sysfs, debugfs.
>
> Fair point.  Shouldn't calls to seq_buf_printf() (and any printk usage that
> always exists in the context of a user-space process) use %pK anyway?

seq_buf is a handy API that might be used for different purpose.
For example, it seems to be used ftrace where people might want
to see real pointers when debugging.

> Hmmm.... maybe vsprintf() should automatically replace %p with %pK if it
> detects a user-space context?

I am not sure if there is an easy and reliable way how to detect the
user-space context. On some architectures, it might be possible to
guess it by the address of the buffer. But it will not work when
the message is temporary printed into a local buffer and copied
later.

Let's keep it simple. Heuristics often become very complex over time.

Best Regards,
Petr


  reply	other threads:[~2021-02-12 11:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10  5:18 [PATCH 0/3][RESEND] add support for never printing hashed addresses Timur Tabi
2021-02-10  5:18 ` [PATCH 1/3] lib/test_printf: use KSTM_MODULE_GLOBALS macro Timur Tabi
2021-02-10  5:21   ` Timur Tabi
2021-02-10 13:14   ` Petr Mladek
2021-02-10  5:18 ` [PATCH 2/3] kselftest: add support for skipped tests Timur Tabi
2021-02-10  5:18 ` [PATCH 3/3] lib/vsprintf: make-printk-non-secret printks all addresses as unhashed Timur Tabi
2021-02-10 11:03   ` Vlastimil Babka
2021-02-10 13:41   ` Petr Mladek
2021-02-10 17:27     ` Timur Tabi
2021-02-12 11:52       ` Petr Mladek [this message]
2021-02-10 11:11 ` [PATCH 0/3][RESEND] add support for never printing hashed addresses Marco Elver
2021-02-10 19:03   ` Timur Tabi
2021-02-10 11:47 ` Andy Shevchenko
2021-02-10 16:57   ` Timur Tabi
2021-02-10 15:46 ` Tetsuo Handa
2021-02-10 16:18   ` Steven Rostedt
2021-02-10 16:39     ` Tetsuo Handa
2021-02-10 16:46       ` Steven Rostedt
2021-02-10 17:07         ` Tetsuo Handa
2021-02-10 17:29           ` Steven Rostedt
2021-02-10 17:21         ` Timur Tabi
2021-02-10 16:54       ` Andy Shevchenko
2021-02-10 17:41         ` Tetsuo Handa

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=YCZr4WrcwfWxVVad@alley \
    --to=pmladek@suse.com \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=john.ogness@linutronix.de \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=pavel@ucw.cz \
    --cc=roman.fietze@magna.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=timur@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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).