linux-kernel - Re: [PATCH] locking/lockdep: Move mark_lock() inside CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE

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: <20190624121755.x5746xrskrbbhaft@willie-the-truck>
Date:   Mon, 24 Jun 2019 13:17:55 +0100
From:   Will Deacon <will@...nel.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Frederic Weisbecker <frederic@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Bart Van Assche <bvanassche@....org>,
        Yuyang Du <duyuyang@...il.com>,
        Waiman Long <longman@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] locking/lockdep: Move mark_lock() inside
 CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING

Hi Arnd,

On Mon, Jun 17, 2019 at 02:47:05PM +0200, Arnd Bergmann wrote:
> The last cleanup patch triggered another issue, as now another function
> should be moved into the same section:
> 
> kernel/locking/lockdep.c:3580:12: error: 'mark_lock' defined but not used [-Werror=unused-function]
>  static int mark_lock(struct task_struct *curr, struct held_lock *this,
> 
> Move mark_lock() into the same #ifdef section as its only caller, and
> remove the now-unused mark_lock_irq() stub helper.
> 
> Fixes: 0d2cc3b34532 ("locking/lockdep: Move valid_state() inside CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
>  kernel/locking/lockdep.c | 73 +++++++++++++++++++---------------------
>  1 file changed, 34 insertions(+), 39 deletions(-)
> 
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 48a840adb281..43e880ceafc2 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -437,13 +437,6 @@ static int verbose(struct lock_class *class)
>  	return 0;
>  }
>  
> -/*
> - * Stack-trace: tightly packed array of stack backtrace
> - * addresses. Protected by the graph_lock.
> - */
> -unsigned long nr_stack_trace_entries;
> -static unsigned long stack_trace[MAX_STACK_TRACE_ENTRIES];
> -
>  static void print_lockdep_off(const char *bug_msg)
>  {
>  	printk(KERN_DEBUG "%s\n", bug_msg);
> @@ -453,6 +446,15 @@ static void print_lockdep_off(const char *bug_msg)
>  #endif
>  }
>  
> +unsigned long nr_stack_trace_entries;
> +
> +#if defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING)

Is this necessary, given that CONFIG_PROVE_LOCKING selects TRACE_IRQFLAGS?
I find that having both of the symbols makes this really hard to read. For
example:

> +/*
> + * Stack-trace: tightly packed array of stack backtrace
> + * addresses. Protected by the graph_lock.
> + */
> +static unsigned long stack_trace[MAX_STACK_TRACE_ENTRIES];

This is used later on by print_lock_trace(), which is only predicated
on #ifdef CONFIG_PROVE_LOCKING.

Will