Hi Greg,
On Tue, Nov 30, 2021 at 08:57:46AM +0100, Greg Kroah-Hartman wrote:
On Mon, Nov 29, 2021 at 07:30:30PM +0100, Salvatore Bonaccorso wrote:
Hi Greg,
(Adding Ben as well)
On Sun, Nov 28, 2021 at 02:08:53PM +0100, Greg Kroah-Hartman wrote:
On Sun, Nov 28, 2021 at 02:06:30PM +0100, Greg Kroah-Hartman wrote:
On Sun, Nov 28, 2021 at 01:11:11PM +0100, Salvatore Bonaccorso wrote:
Hi,
On Sun, Nov 28, 2021 at 12:59:24PM +0100, Salvatore Bonaccorso wrote:
Hi,
On Sun, Nov 28, 2021 at 10:46:13AM +0100, Salvatore Bonaccorso wrote: > Hi, > > On Wed, Nov 24, 2021 at 12:54:38PM +0100, Greg Kroah-Hartman wrote: > > From: Peter Zijlstra peterz@infradead.org > > > > [ Upstream commit ce0b9c805dd66d5e49fd53ec5415ae398f4c56e6 ] > > > > vmlinux.o: warning: objtool: look_up_lock_class()+0xc7: call to rcu_read_lock_any_held() leaves .noinstr.text section > > For 4.19.218 at least this commit seems to cause a build failure for > cpupower, if warnings are treated as errors, I have not seen the same > for the 5.10.80 build: > > gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -DVERSION="4.19" -DPACKAGE="cpupower" -DPACKAGE_BUGREPORT="Debian\ (reportbug\ linux-cpupower)" -D_GNU_SOURCE -pipe -DNLS -Wall -Wchar-subscripts -Wpointer-arith > -Wsign-compare -Wno-pointer-sign -Wdeclaration-after-statement -Wshadow -Os -fomit-frame-pointer -fPIC -o /home/build/linux-4.19.218/debian/build/build-tools/tools/power/cpupower/lib/cpupower.o -c lib/cpupower.c > In file included from lockdep.c:28: > ../../../kernel/locking/lockdep.c: In function ‘look_up_lock_class’: > ../../../kernel/locking/lockdep.c:694:2: error: implicit declaration of function ‘hlist_for_each_entry_rcu_notrace’; did you mean ‘hlist_for_each_entry_continue’? [-Werror=implicit-function-declaration] > hlist_for_each_entry_rcu_notrace(class, hash_head, hash_entry) { > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > hlist_for_each_entry_continue > ../../../kernel/locking/lockdep.c:694:53: error: ‘hash_entry’ undeclared (first use in this function); did you mean ‘hash_ptr’? > hlist_for_each_entry_rcu_notrace(class, hash_head, hash_entry) { > ^~~~~~~~~~ > hash_ptr > ../../../kernel/locking/lockdep.c:694:53: note: each undeclared identifier is reported only once for each function it appears in > ../../../kernel/locking/lockdep.c:694:64: error: expected ‘;’ before ‘{’ token > hlist_for_each_entry_rcu_notrace(class, hash_head, hash_entry) { > ^~ > ; > ../../../kernel/locking/lockdep.c:706:1: warning: control reaches end of non-void function [-Wreturn-type] > } > ^ > cc1: some warnings being treated as errors > make[5]: *** [/home/build/linux-4.19.218/tools/build/Makefile.build:97: /home/build/linux-4.19.218/debian/build/build-tools/tools/lib/lockdep/lockdep.o] Error 1 > make[4]: *** [Makefile:121: /home/build/linux-4.19.218/debian/build/build-tools/tools/lib/lockdep/liblockdep-in.o] Error 2 > make[4]: Leaving directory '/home/build/linux-4.19.218/tools/lib/lockdep' > make[3]: *** [/home/build/linux-4.19.218/debian/rules.d/tools/lib/lockdep/Makefile:16: all] Error 2 > make[3]: Leaving directory '/home/build/linux-4.19.218/debian/build/build-tools/tools/lib/lockdep' > make[2]: *** [debian/rules.real:795: build-liblockdep] Error 2 > make[2]: *** Waiting for unfinished jobs.... > > I was not yet able to look further on it.
Might actually be a distro specific issue, needs some further investigation.
I'm really sorry about the doubled noice, so here is the stance. I can reproduce distro indpeendent, but the initial claim was wrong. It can be reproduced for 4.19.218:
$ LC_ALL=C.UTF-8 V=1 ARCH=x86 make -C tools liblockdep make: Entering directory '/home/build/linux-stable/tools' mkdir -p lib/lockdep && make subdir=lib/lockdep -C lib/lockdep make[1]: Entering directory '/home/build/linux-stable/tools/lib/lockdep' make -f /home/build/linux-stable/tools/build/Makefile.build dir=. obj=fixdep gcc -Wp,-MD,./.fixdep.o.d -Wp,-MT,fixdep.o -D"BUILD_STR(s)=#s" -c -o fixdep.o fixdep.c ld -r -o fixdep-in.o fixdep.o gcc -o fixdep fixdep-in.o gcc -Wp,-MD,./.common.o.d -Wp,-MT,common.o -g -DCONFIG_LOCKDEP -DCONFIG_STACKTRACE -DCONFIG_PROVE_LOCKING -DBITS_PER_LONG=__WORDSIZE -DLIBLOCKDEP_VERSION='"4.19.218"' -rdynamic -O0 -g -fPIC -Wall -I. -I./uinclude -I./include -I../../include -D"BUILD_STR(s)=#s" -c -o common.o common.c gcc -Wp,-MD,./.lockdep.o.d -Wp,-MT,lockdep.o -g -DCONFIG_LOCKDEP -DCONFIG_STACKTRACE -DCONFIG_PROVE_LOCKING -DBITS_PER_LONG=__WORDSIZE -DLIBLOCKDEP_VERSION='"4.19.218"' -rdynamic -O0 -g -fPIC -Wall -I. -I./uinclude -I./include -I../../include -D"BUILD_STR(s)=#s" -c -o lockdep.o lockdep.c In file included from lockdep.c:28: ../../../kernel/locking/lockdep.c: In function ‘look_up_lock_class’: ../../../kernel/locking/lockdep.c:692:2: warning: implicit declaration of function ‘hlist_for_each_entry_rcu_notrace’; did you mean ‘hlist_for_each_entry_continue’? [-Wimplicit-function-declaration] hlist_for_each_entry_rcu_notrace(class, hash_head, hash_entry) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ hlist_for_each_entry_continue ../../../kernel/locking/lockdep.c:692:53: error: ‘hash_entry’ undeclared (first use in this function); did you mean ‘hash_ptr’? hlist_for_each_entry_rcu_notrace(class, hash_head, hash_entry) { ^~~~~~~~~~ hash_ptr ../../../kernel/locking/lockdep.c:692:53: note: each undeclared identifier is reported only once for each function it appears in ../../../kernel/locking/lockdep.c:692:64: error: expected ‘;’ before ‘{’ token hlist_for_each_entry_rcu_notrace(class, hash_head, hash_entry) { ^~ ; ../../../kernel/locking/lockdep.c:704:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ make[2]: *** [/home/build/linux-stable/tools/build/Makefile.build:97: lockdep.o] Error 1 make[1]: *** [Makefile:121: liblockdep-in.o] Error 2 make[1]: Leaving directory '/home/build/linux-stable/tools/lib/lockdep' make: *** [Makefile:66: liblockdep] Error 2 make: Leaving directory '/home/build/linux-stable/tools'
Reverting upstream ce0b9c805dd6 ("locking/lockdep: Avoid RCU-induced noinstr fail") on top of 4.19.218 fixes the issue.
So back to square one, and again apologies for the intermediate noise!
What config/arch is causing this to break? And if you add rchlist.h to the include files for lockdep.c, does that resolve the issue? I haven't seen any other reports of this yet.
Ah, it's the tools being built here, sorry, that was confusing.
Ah yes, sorry this was not clear. It's all about the tools, which some are built as well as packages in Debian accompaning, tools/lib/lockdep is one of those built.
Ok, fair enough, I'll gladly take a patch that fixes this up for the 4.19.y releases.
We (speaking as for Debian) will probably drop the ball here as well, and drop building the lockdep tool packages in the next upload. It was probabably anyway not a good idea to have them built in the first place.
Regards, Salvatore