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: <4a540a5d341c468bae131934b413e4ce@AcuMS.aculab.com>
Date:   Wed, 13 May 2020 08:21:52 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "'psmith@....org'" <psmith@....org>,
        '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..

From: Paul Smith
> Sent: 12 May 2020 17:55
> On Tue, 2020-05-12 at 15:04 +0000, David Laight wrote:
> > I think there were some sub-makes that were started with make
> > instead of $(MAKE) so ended up creating a new job pipe.
> 
> Oh, yes, that will do it.
> 
> > Doesn't it do blocking reads with SIGCHLD enabled?
> 
> No, because it's racy (by itself).
> 
> > (or hopefully ppoll() to avoid the race)
> 
> 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.

> > Another option is for the 'parent' make to return (or not acquire)
> > a job token for $(MAKE) commands.
> 
> It just feels cleaner to me to have the parent simply always take the
> token, and leave it up to the child to put it back if appropriate,
> rather than the parent putting it back.
> 
> 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.

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

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.
A bit of faffing on the token pipe isn't going to affect the performance
when it is about to do fork+exec.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)