lkml.org 
[lkml]   [2021]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4.19 088/323] locking/lockdep: Avoid RCU-induced noinstr fail
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

\
 
 \ /
  Last update: 2021-12-04 11:31    [W:0.186 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site