Re: [patch 08/10] kernel/locking/lockdep.c: convert hash tables to hlists
From: Ingo Molnar
Date: Fri Feb 12 2016 - 04:51:06 EST
* akpm@xxxxxxxxxxxxxxxxxxxx <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Subject: kernel/locking/lockdep.c: convert hash tables to hlists
>
> Mike said:
>
> : CONFIG_UBSAN_ALIGNMENT breaks x86-64 kernel with lockdep enabled, i. e
> : kernel with CONFIG_UBSAN_ALIGNMENT fails to load without even any error
> : message.
> :
> : The problem is that ubsan callbacks use spinlocks and might be called
> : before lockdep is initialized. Particularly this line in the
> : reserve_ebda_region function causes problem:
> :
> : lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES);
> :
> : If i put lockdep_init() before reserve_ebda_region call in
> : x86_64_start_reservations kernel loads well.
>
> Fix this ordering issue permanently: change lockdep so that it uses hlists
> for the hash tables. Unlike a list_head, an hlist_head is in its
> initialized state when it is all-zeroes, so lockdep is ready for operation
> immediately upon boot - lockdep_init() need not have run.
>
> The patch will also save some memory.
>
> lockdep_init() and lockdep_initialized can be done away with now - a 4.6
> patch has been prepared to do this.
>
> Reported-by: Mike Krinkin <krinkin.m.u@xxxxxxxxx>
> Suggested-by: Mike Krinkin <krinkin.m.u@xxxxxxxxx>
> Cc: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> ---
>
> include/linux/lockdep.h | 4 +--
> kernel/locking/lockdep.c | 42 ++++++++++++++++---------------------
> 2 files changed, 21 insertions(+), 25 deletions(-)
Hm, so I already have the patch below queued up for v4.6, in the locking tree,
plus the followup lockdep_init() patch as well.
Didn't want to merge this relatively intrusive patch late in the -rc cycle, as it
appears this is not a regression: CONFIG_UBSAN_ALIGNMENT apparently never worked
on x86_64.
But no big feelings either way.
Thanks,
Ingo
===================================>