[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190929090448.GB7669@openwall.com>
Date: Sun, 29 Sep 2019 12:04:48 +0300
From: croco@...nwall.com
To: owl-users@...ts.openwall.com
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 reptile.croco.net 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, croco@...nwall.com 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
./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
varan103!crocodil:~/crypt_blowfish-1.3$
Looks strange to me. The simple thread demo that fails is found here:
http://www.croco.net/qq/prod_cons.c -- 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.
Thanks!
--
Croco
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.
