linux-kernel - Re: I disabled more compiler warnings..

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 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <6a5a75043f697a130422fbc3a3f8464dc6d03e2f.camel@gnu.org>
Date:   Wed, 13 May 2020 11:32:50 -0400
From:   Paul Smith <psmith@....org>
To:     David Laight <David.Laight@...LAB.COM>,
        'Linus Torvalds' <torvalds@...ux-foundation.org>
Cc:     'Arnd Bergmann' <arnd@...db.de>,
        'Masahiro Yamada' <yamada.masahiro@...ionext.com>,
        'Linux Kernel Mailing List' <linux-kernel@...r.kernel.org>
Subject: Re: I disabled more compiler warnings..

On Wed, 2020-05-13 at 08:21 +0000, David Laight wrote:
> > GNU make uses pselect(), on systems that support it.  On systems
> > that don't support pselect() it uses a trick I described in another
> > email: we dup() the FD, read() on the dup, then in the SIGCHLD
> > handler we close() the dup.
> 
> Does that even work - seems like it requires close() to abort poll().
> Better is to just have the SIGCHLD handler write a byte into a pipe.

Sorry I guess I wasn't clear.

We use _either_ pselect(), _or_ the close()-the-dup trick.  Not both.

If we have pselect() we use that: no dup'ing or close'ing needed.

If we don't have pselect() we use the close() in the signal handler. 
In that case we're just waiting in the read(), we're not using select()
or poll() or whatever.  It's definitely the case that if we're waiting
in read() and someone closes the FD, we'll wake up! :)

> > Having the parent not acquire a token at all won't work; without
> > limiting sub-makes it means you might have 100's of them running at
> > the same time, even with -j2 or whatever.
> 
> Hmmm... 
> That means the sub-make must always hold one token.
> Otherwise the parent-make could use it to create a new sub-make.

Right, my first idea has this same problem so it won't work.

> Actually the token pipe can be opened NON_BLOCK because poll()
> can/will be used to wait for a token.

Again, that only works on systems where pselect() is available.

> So you always try to read a token - even when you have one 'in your
> hand' (either entry or because a job just finished).  If it isn't the
> 'abort' one, put it back.

Something like that would be needed, yes.

Note this is only needed in a rare situation where you're running with
parallelism enabled BUT you have a makefile which never actually tries
to run two or more jobs at the same time for some reason.