[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <201909162006.3138C81AE0@keescook>
Date: Mon, 16 Sep 2019 20:07:55 -0700
From: Kees Cook <keescook@...omium.org>
To: "Paul E. McKenney" <paulmck@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lockdep: Make print_lock() address visible
On Mon, Sep 16, 2019 at 06:39:46PM -0700, keescook@...omium.org wrote:
> commit 519248f36d6f3c80e176f6fa844c10d94f1f5990
> Author: Paul E. McKenney <paulmck@...ux.ibm.com>
> Date: Thu May 30 05:39:25 2019 -0700
>
> lockdep: Make print_lock() address visible
>
> Security is a wonderful thing, but so is the ability to debug based on
> lockdep warnings. This commit therefore makes lockdep lock addresses
> visible in the clear.
>
> Signed-off-by: Paul E. McKenney <paulmck@...ux.ibm.com>
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 4861cf8e274b..4aca3f4379d2 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -620,7 +620,7 @@ static void print_lock(struct held_lock *hlock)
> return;
> }
>
> - printk(KERN_CONT "%p", hlock->instance);
> + printk(KERN_CONT "%px", hlock->instance);
> print_lock_name(lock);
> printk(KERN_CONT ", at: %pS\n", (void *)hlock->acquire_ip);
> }
Just to clarify: this is only visible under CONFIG_LOCKDEP, yes? That's
not a state anyone would run a production system under, I'd hope.
--
Kees Cook
Powered by blists - more mailing lists