Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Sep 2019 12:04:48 +0300
Subject: Re: x86 containers under x86_64 hardware node: threads
 don't work

On Sat, Sep 28, 2019 at 04:29:51PM +0200, Solar Designer wrote:
> Hi Croco,
> What Owl kernel version do you have on that host ("uname -rm", please)?

root@...tile:~ # uname -rm
2.6.32-042stab059.7.owl1 x86_64
root@...tile:~ # uname -arm
Linux 2.6.32-042stab059.7.owl1 #1 SMP Fri Oct 12 15:48:47
MSK 2018 x86_64 GNU/Linux

Okay, I'm starting to recall some detail about the kernel.  It is not the
kernel version from the distribution, because the HN is now a netbook (sic),
I don't remember exactly what; the default Owl kernel didn't see its
ethernet card (atl1) so I had to rebuild the kernel.  Well, actually I
failed to do that myself (don't remember what went wrong) and I had no
possibility to investigate (my server was down, with all my sites and
email, I had to prepare the replacement urgently), so Gremlin helped me and
created the kernel binary.  I can send you the /proc/config.gz :-)
> On Fri, Sep 27, 2019 at 06:17:30PM +0300, wrote:
> > After some unsuccessful attempts to 'solve' this by changing container's
> > config parameters, I started suspecting the problem is with threads as
> > such, and to check for it, tried to run a small (really small!)
> > pthread-based demo program.  It failed to create any threads at all, that
> > is, pthread_create always returns that damn EAGAIN.
> This is news to me, and I can't reproduce it.  For example, taking our
> crypt_blowfish 1.3 and running "make check_threads" in a 32-bit Owl
> container on a 64-bit Owl host works just fine for me.  Can you also try
> this very test?

Well, it doesn't issue any errors at least:

varan103!crocodil:~/crypt_blowfish-1.3$ make check_threads
gcc -c -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual
-Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wundef -Wpointer-arith
-O2 -fomit-frame-pointer -funroll-loops crypt_blowfish.c
gcc -c x86.S
gcc -c -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual
-Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wundef -Wpointer-arith
-O2 -fomit-frame-pointer -funroll-loops crypt_gensalt.c
gcc -c -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual
-Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wundef -Wpointer-arith
-O2 -fomit-frame-pointer -funroll-loops wrapper.c -DTEST -DTEST_THREADS=4
-o crypt_test_threads.o
gcc -s crypt_blowfish.o x86.o crypt_gensalt.o crypt_test_threads.o
-lpthread -o crypt_test_threads
229.0 c/s real, 229.0 c/s virtual
0: 72.5 c/s real
1: 72.8 c/s real
2: 71.8 c/s real
3: 72.5 c/s real

Looks strange to me.  The simple thread demo that fails is found here: -- it consists of one source file of
126 lines, implements the "producers&consumers" and is run like this:

varan103!crocodil:~$ gcc -Wall -g prod_cons.c -lpthread -lm -o pc
varan103!crocodil:~$ mkfifo _f1 _f2 _f3
varan103!crocodil:~$ ./pc _f1 _f2 _f3
PR0: can't create: Resource temporarily unavailable
PR1: can't create: Resource temporarily unavailable
PR2: can't create: Resource temporarily unavailable
CN0: can't create: Resource temporarily unavailable
CN1: can't create: Resource temporarily unavailable

(these FIFOs are for feeding the "producers" with some data, but the
program here doesn't reach the actual code to read the data)

What's the difference between them? 8-()  Well, I'm completely confused.



Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.