Re: [GIT PULL] locking fixes

[Ingo Molnar <mingo@kernel.org>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, Apr 20, 2019 at 12:30 AM Ingo Molnar <mingo@kernel.org> wrote:
> >
> > A lockdep warning fix and a script execution fix when atomics are
> > generated.
> 
> Hmm. I've pulled this, but looking at it, I think it's worth noting something...
> 
> > diff --git a/scripts/atomic/gen-atomics.sh b/scripts/atomic/gen-atomics.sh
> > index 27400b0cd732..000dc6437893 100644
> > --- a/scripts/atomic/gen-atomics.sh
> > +++ b/scripts/atomic/gen-atomics.sh
> > -       ${ATOMICDIR}/${script} ${ATOMICTBL} > ${LINUXDIR}/include/${header}
> > +       /bin/sh ${ATOMICDIR}/${script} ${ATOMICTBL} > ${LINUXDIR}/include/${header}
> 
> /bin/sh ?
> 
> Yes, that's what the hash-bang line says in the scripts themselves,
> and thus what we used to do with the whole direct execution thing, so
> it's clearly not _wrong_, but every single time when we manually do
> the "run with shell" normally, we use $(CONFIG_SHELL)".
> 
> So I get the feeling that we should likely do that here too.
> 
> Of course, the gen-atomics script is (now) outside the normal build,
> so maybe people just go "this is special, doesn't go through the
> normal build process anyway, and thus might as well not follow the
> common rules".

Yeah, agreed that this is all a bit weird. The status quo right now is:

 - scripts/atomic/gen-atomics.sh is a completely standalone, external 
   script which isn't even tied into any Makefile mechanism to build the 
   kernel.

 - To generate the headers one has to explicitly call 
   scripts/atomic/gen-atomics.sh, and it's not even executable, so the 
   incantation is even more weird:

         $ . scripts/atomic/gen-atomics.sh

So I agree that the UI of all this should be improved, I suspect we 
should do the following improvements:

   - make gen-atomics.sh executable

   - add a "make headers_gen_atomics" target to the main Makefile

   - call gen-atomics.sh via the build system and thus have access to 
     $CONFIG_SHELL and such and don't have assumptions about the shell 
     environment.

Arguably /bin/sh tends to exist during the build, everywhere. What 
usually results in the use of CONFIG_SHELL isn't /bin/sh per se but 
specific shell variant assumptions such as /bin/bash and the resulting 
occasional Bashism in the scripts - there are systems with non-bash 
shells by default and so.

Thanks,

	Ingo