Spotted by Thomas Gleixner <tglx@linutronix.de>, THANK YOU

forkrun() never properly handled the case that a child exited before
the timeout expired, because we had failed to block the signal and
hence never received a SIGCHLD. This was overlooked because this
functionality was never relevant (it only delayed test execution) and
because we did not explicitly test it.

Related to #31

Should fix #32

See #31

It seems with the recent debian updates on my machine, some change
of timing/scheduling has come which makes flock() fail when the
lock holder is being killed by the timeout code in forkrun()

For future reference: logs/20231026_apt_history.txt

Making a full copy of the logbuffer just to access four members
was not justified. The original idea was to re-use logbuffer_fini,
but, effectively, only buddy_return1_ptr_page() was called.

In particular with uint8_t, we risk writes to be non atomic and
overwrite neighboring members

Ref #28

Ref #28

Ref #28

Weird - I do not understand why this did not pop up earlier?

Conflicts:
	src/Makefile.am

with 6abc7c970dd5be381e588b9d0234c385a5a6d0d7 in liburing,
io_uring_prep_fallocate() arguments were (rightly) changed
from off_t to __u64.

Reflect this change. Also note that our struct fellow_io_discard
already used uint64_t.

Reported by Flexelint

Before:

$ find . -name \*.so| xargs nm|grep simple_task_
000000000004ffd0 T fellow_simple_task_run

After:

$ find . -name \*.so| xargs nm|grep simple_task_
<EOF>

Motivated by #27

See liburing commit 834496358870cb272f98cf22b3fe0307c83a526d

Fixes #26 specifically, we are still missing similar handling in other
places.

2d468a6f gave the clue:

When fellow_cache_obj_lru_touch() raced fellow_cache_lru_work(),
we would put the fco's fcs on the lru list twice: once from
_touch and then from _lru_work().

Fixes #25

See next commit for fix

This reverts commit bf1e9e71.

Conflicts:
	src/fellow_cache.c

Conflicts:
	src/fellow_cache.c

Motivated by #25, which looks like a self-induced deadlock
in fellow_cache_lru_work()