From: Steven Rostedt <rostedt@goodmis.org>
To: Anna-Maria Gleixner <anna-maria@linutronix.de>
Cc: "Tobin C. Harding" <me@tobin.cc>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Kees Cook <keescook@chromium.org>, Theodore Ts'o <tytso@mit.edu>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vsprintf: Add command line option debug_boot_weak_hash
Date: Tue, 15 May 2018 10:33:28 -0400 [thread overview]
Message-ID: <20180515103328.4dc32cd8@gandalf.local.home> (raw)
In-Reply-To: <1526359115-5489-1-git-send-email-me@tobin.cc>
Anna-Maria,
Can you test this patch on that kernel you were having issues with (the
one triggering the RCU stalls, and not having entropy to show the
pointers of the timer events).
And report back what you find.
Thanks!
-- Steve
On Tue, 15 May 2018 14:38:35 +1000
"Tobin C. Harding" <me@tobin.cc> wrote:
> Currently printing [hashed] pointers requires enough entropy to be
> available. Early in the boot sequence this may not be the case
> resulting in a dummy string '(____ptrval____)' being printed. This
> makes debugging the early boot sequence difficult. We can relax the
> requirement to use cryptographically secure hashing during debugging.
> This enables debugging while keeping development/production kernel
> behaviour the same.
>
> If new command line option debug_boot_weak_hash is enabled use
> cryptographically insecure hashing and hash pointer value immediately.
>
> Signed-off-by: Tobin C. Harding <me@tobin.cc>
> ---
>
> This patch was previously submitted as the last in the set
>
> [PATCH v3 0/4] enable early printing of hashed pointers
>
> Helps debugging using ftrace. Original problem reported by Anna-Maria,
> solution requested by Steve.
>
> Changes since above mentioned patch set
> - change option name from debug_early_boot -> debug_boot_weak_hash
> (suggested by Steve).
>
>
> I have only tested this by enabling the option and printing some
> pointers. This does not _prove_ that it fixes the ftrace issue.
>
> thanks,
> Tobin.
>
>
> Documentation/admin-guide/kernel-parameters.txt | 8 ++++++++
> lib/vsprintf.c | 18 ++++++++++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 3b8032431585..c95dd6704592 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -748,6 +748,14 @@
>
> debug [KNL] Enable kernel debugging (events log level).
>
> + debug_boot_weak_hash
> + [KNL] Enable debugging early in the boot sequence. If
> + enabled, we use a weak hash instead of siphash to hash
> + pointers. Use this option if you need to see pointer
> + values during early boot (i.e you are seeing instances
> + of '(___ptrval___)') - cryptographically insecure,
> + please do not use on production kernels.
> +
> debug_locks_verbose=
> [KNL] verbose self-tests
> Format=<0|1>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index b82f0c6c2aec..5ff18f8fe3bd 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1654,6 +1654,18 @@ char *device_node_string(char *buf, char *end, struct device_node *dn,
> return widen_string(buf, buf - buf_start, end, spec);
> }
>
> +/* Make pointers available for printing early in the boot sequence. */
> +static int debug_boot_weak_hash __ro_after_init;
> +EXPORT_SYMBOL(debug_boot_weak_hash);
> +
> +static int __init debug_boot_weak_hash_enable(char *str)
> +{
> + debug_boot_weak_hash = 1;
> + pr_info("debug_boot_weak_hash enabled\n");
> + return 0;
> +}
> +early_param("debug_boot_weak_hash", debug_boot_weak_hash_enable);
> +
> static bool have_filled_random_ptr_key __read_mostly;
> static siphash_key_t ptr_key __read_mostly;
>
> @@ -1694,6 +1706,12 @@ static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec spec)
> const char *str = sizeof(ptr) == 8 ? "(____ptrval____)" : "(ptrval)";
> unsigned long hashval;
>
> + /* When debugging early boot use non-cryptographically secure hash */
> + if (unlikely(debug_boot_weak_hash)) {
> + hashval = hash_long((unsigned long)ptr, 32);
> + return pointer_string(buf, end, (const void *)hashval, spec);
> + }
> +
> if (unlikely(!have_filled_random_ptr_key)) {
> spec.field_width = 2 * sizeof(ptr);
> /* string length must be less than default_width */
next prev parent reply other threads:[~2018-05-15 14:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 4:38 Tobin C. Harding
2018-05-15 14:33 ` Steven Rostedt [this message]
2018-05-15 15:29 ` Randy Dunlap
2018-05-16 22:26 ` Tobin C. Harding
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=20180515103328.4dc32cd8@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=anna-maria@linutronix.de \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=me@tobin.cc \
--cc=rdunlap@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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
all inboxes | Powered by JetHome®