Re: Linux kernel Books

[Augusto Mecking Caringi]

On Fri, Mar 23, 2018 at 10:00 AM, Milad Kahsari  wrote:
> This book illustrates virtual memory space in a reasonably clear way, easy
> to follow with lots of diagrams, which I did not find in other books.
> Although it states IA-64, the concept is pretty much the same if you are
> looking for IA-32, excellent book, definitely recommend it! :)

It's worth to note that IA-64 [1] is not x86-64 [2].

IA-64 is the Itanium ISA. Is there still anyone using this? :)

Best regards,

[1] https://en.wikipedia.org/wiki/IA-64
[2] https://en.wikipedia.org/wiki/X86-64

-- 
Augusto Mecking Caringi

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Hang in FUTEX_WAKE_PRIVATE after clock_gettime

[valdis . kletnieks]

On Sat, 24 Mar 2018 04:43:42 -0400, Jeffrey Walton said:

> My question is, is a futex with a 2147483647 or -1 expected? Where
> should I be looking to begin to narrow the problem down?

'man 7 futex' says:

   Semantics
   Any futex operation starts in user space, but it may  be  necessary  to
   communicate with the kernel using the futex(2) system call.

   To  "up"  a  futex, execute the proper assembler instructions that will
   cause the host CPU to atomically  increment  the  integer.   Afterward,
   check  if  it has in fact changed from 0 to 1, in which case there were
   no waiters and the operation is done.  This is  the  noncontended  case
   which is fast and should be common.

   In the contended case, the atomic increment changed the counter from -1
   (or some other negative number).  If this is detected, there are  wait-
   ers.   User space should now set the counter to 1 and instruct the ker-
   nel to wake up any waiters using the FUTEX_WAKE operation.

   Waiting on a futex, to "down" it, is the reverse operation.  Atomically
   decrement  the  counter and check if it changed to 0, in which case the
   operation is done and the futex was uncontended.  In all other  circum-
   stances,  the process should set the counter to -1 and request that the
   kernel wait for another process to up the futex.  This  is  done  using
   the FUTEX_WAIT operation.

   The  futex(2) system call can optionally be passed a timeout specifying
   how long the kernel should wait for the futex to  be  upped.   In  this
   case,  semantics  are  more  complex  and the programmer is referred to
   futex(2) for more details.  The same holds for asynchronous futex 
waiting.

which pretty much says that a negative value means there's somebody waiting
on the futex.


pgpLKt41FqBMx.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Hang in FUTEX_WAKE_PRIVATE after clock_gettime

[Jeffrey Walton]

Hi Everyone,

I'm working with Botan (https://botan.randombit.net/). It is a TLS
security library written in C++11.

On an old Pentium III machine the self tests are hanging. Other
platforms are OK. The strace tail is shown below.

I am not that familiar with this type of debugging, and I am looking
for a direction to go. I've seen some similar problems on the web,
including an indictment of clock_gettime, but the problems lack a good
analysis of the problem.

My question is, is a futex with a 2147483647 or -1 expected? Where
should I be looking to begin to narrow the problem down?

Thanks in advance.

**

$ sudo strace ./botan-test block
execve("./botan-test", ["./botan-test", "block"], [/* 14 vars */]) = 0
brk(NULL)   = 0x9af9000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
readlink("/proc/self/exe", "/home/jwalton/botan/botan-test", 4096) = 30
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f4e000
...
stat64("src/tests/data/block/noekeon.vec", {st_mode=S_IFREG|0664,
st_size=121320, ...}) = 0
stat64("src/tests/data/block/aria.vec", {st_mode=S_IFREG|0664,
st_size=2663, ...}) = 0
stat64("src/tests/data/block/des.vec", {st_mode=S_IFREG|0664,
st_size=28722, ...}) = 0
getdents(3, /* 0 entries */, 32768) = 0
close(3)= 0
open("src/tests/data/block/aes.vec", O_RDONLY|O_LARGEFILE) = 3
read(3, "# Test vectors from NIST CAVP AE"..., 8191) = 8191
clock_gettime(CLOCK_REALTIME, {1521879372, 559396333}) = 0
futex(0xb78b6a34, FUTEX_WAKE_PRIVATE, 2147483647) = 0


*

This old machine runs Peppermint, which is a Ubuntu derivative.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Peppermint
Description:Peppermint 8 Eight
Release:8
Codename:   xenial

$ uname -a
Linux coppermine 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7
16:02:25 UTC 2018 i686 i686 i686 GNU/Linux

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies