Unfortunately, this was present even in the initial public
release 58ec40f9

This issue should have had no production impact, but it made hunting
down bugs unnecessary hard.

When we work on the last segment, the remaining length is zero,
but we still have a current pointer and length.

This was a particularly annoying glitch because I wrote almost
the same code for varnish-cache with the equivalent assertion in
the right place :(

Sorry

Ref https://github.com/varnishcache/varnish-cache/pull/4013/commits/8ec77190d91603c8f0dead0cee013e3c9ca8fa78#diff-f79cfeda8456789ae873270aefa58e8f1e94213ee16d32ea96b8db8a7013ebf8R790
Closes #34

it is planned to replace the "inuse" tri-state and might turn
out helpful for debugging.

https://github.com/varnishcache/varnish-cache/pull/4013 fixes two
issues in Varnish-Cache, which are relevant for SLASH/fellow and of
which the first is the root cause of #33.

This commit works around these issues until the fix gets merged:

Because of the wrong use of the .objtrimstore API function by
varnish-cache, we remove it from our obj_methods and exploit the fact
that varnish-cache always sets the OA_LEN attribute when the object is
complete: We move the trimstore function there, effectively calling it
at the right time only.

The inefficient memory allocation fixed in the second commit of
VC#4013 is particularly relevant for fellow, because it causes the
allocation code to assume that the object might grow up to the maximum
possible size, which causes a substantial over-allocation. We work
around this issue for the case that a 304 copy is made from fellow to
fellow by using private thread-local storage to emulate basically the
same function as the #4013 fix.

Closes #33
Ref https://github.com/varnishcache/varnish-cache/pull/4013

Ref #33
Ref https://github.com/varnishcache/varnish-cache/pull/4013

These would have made analyzing #33 much easier. :|

motivated by #32

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?

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