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:   Sun, 21 Apr 2019 20:23:54 +0200
From:   Ingo Molnar <>
To:     Linus Torvalds <>,
        Mark Rutland <>
Cc:     Linux List Kernel Mailing <>,
        Thomas Gleixner <>,
        Peter Zijlstra <>,
        Andrew Morton <>,
        Will Deacon <>
Subject: Re: [GIT PULL] locking fixes

* Linus Torvalds <> wrote:

> On Sat, Apr 20, 2019 at 12:30 AM Ingo Molnar <> 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/ b/scripts/atomic/
> > index 27400b0cd732..000dc6437893 100644
> > --- a/scripts/atomic/
> > +++ b/scripts/atomic/
> > -       ${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/ is a completely standalone, external 
   script which isn't even tied into any Makefile mechanism to build the 

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

         $ . scripts/atomic/

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

   - make executable

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

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

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.



Powered by blists - more mailing lists