linux-kernel - Re: Compilation error for target liblockdep

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] [day] [month] [year] [list]

Date:   Mon, 18 Nov 2019 15:14:05 -0800
From:   Bart Van Assche <bvanassche@....org>
To:     Zhengyuan Liu <liuzhengyuan@...inos.cn>, mingo <mingo@...nel.org>,
        "alexander.levin" <alexander.levin@...rosoft.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: Compilation error for target liblockdep

On 11/18/19 1:20 AM, Zhengyuan Liu wrote:
> I got a compilation error while building target liblockdep and I think I'd
> better report it to you. The error info showed as bellow:
> 
>          # cd SRC/tools
>          # make liblockdep
>            DESCEND  lib/lockdep
>            CC       lockdep.o
>          In file included from lockdep.c:33:0:
>          ../../../kernel/locking/lockdep.c:53:28: fatal error: linux/rcupdate.h: No such file or directory
>          compilation terminated.
>          mv: cannot stat './.lockdep.o.tmp': No such file or directory
>          /home/lzy/kernel-upstream/linux-linus-ubuntu/tools/build/Makefile.build:96: recipe for target 'lockdep.o' failed
>          make[2]: *** [lockdep.o] Error 1
>          Makefile:121: recipe for target 'liblockdep-in.o' failed
>          make[1]: *** [liblockdep-in.o] Error 2
>          Makefile:68: recipe for target 'liblockdep' failed
>          make: *** [liblockdep] Error 2
> 
> BTW, It was introduced by commit a0b0fd53e1e ("locking/lockdep: Free lock classes that are no longer in use").

(+Peter)

Hi Zhengyuan Liu,

The approach of liblockdep is fragile. Every time an additional kernel 
header is included from the lockdep code or a change is made in one of 
the kernel headers used by lockdep, that change has to be ported to the 
include files in the tools/lib/lockdep/include/liblockdep/ directory. I 
think there are two possible solutions:
- Making the changes necessary to make liblockdep build again.
- Removing the code under tools/lib/lockdep and porting this code to the
   new KUnit framework. If I understood the KUnit framework correctly it
   is based on UML and hence does not require kernel headers to be
   duplicated.

I'm not sure what the best approach is.

Thanks,

Bart.