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?

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

Should fix #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.

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