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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Thu, 13 Feb 2020 21:57:43 -0800
From:   Bart Van Assche <bvanassche@....org>
To:     Johannes Thumshirn <Johannes.Thumshirn@....com>,
        Zhengyuan Liu <liuzhengyuan@...inos.cn>,
        mingo <mingo@...nel.org>,
        "alexander.levin" <alexander.levin@...rosoft.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: Compilation error for target liblockdep

On 2020-02-13 04:59, Johannes Thumshirn wrote:
> On 18/11/2019 10:20, Zhengyuan Liu wrote:
>> Hi, guys,
>>
>> 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").
> 
> This error still pops up here on current master
> HEAD: 0bf999f9c5e74c7ecf9dafb527146601e5c848b9

I'm not sure it's worth fixing the tests under tools/lib/lockdep since
keeping these tests working requires modifying the headers under
tools/lib/lockdep/include/ every time the kernel headers under include/
are changed. How about removing tools/lib/lockdep entirely and
converting these lockdep tests to the KUnit framework? KUnit is based on
UML and I think that's a much more robust approach. For more information
about KUnit, see also https://lwn.net/Articles/780985/.

Thanks,

Bart.


Powered by blists - more mailing lists