Re: [RFC PATCH 12/12] samples: Add a cache on RCU pseudo-transactions with a lock per node

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-10-23 14:22, Puranjay Mohan wrote:
[...]
> I think there's an eviction race here.  cache_lock_entry() re-plans
> from e's current links, but doesn't check that e is still the tail.
[...]
> Checking p->next == &cache_lru.head.node for
> evictions would close it, but then cache_lock_entry() has to return
> false when the check fails rather than retry, or the writer spins until
> e is back at the tail.

Yes, this is a race. The next version will add a CACHE_EVICT mode to
cache_lock_entry(). It checks that the entry is still the tail, and
returns false when it is not. The writer then reads the new tail.

[...]
> Nit: an allocation failure in cache_unlink() or cache_link() also ends
> up here, so it's counted as a lost race as well as a failure.

A fix is planned for the next version. Link and unlink will return an
errno. An allocation failure will be counted in nr_nomem only.

> Two more small things, which apply to the mutex sample in patch 11 as
> well: a bad lookup (nr_bad) prints the same "the hash table and the list
> disagree" as a cache_check() failure, and a kthread_run() failure is
> skipped silently, so a run in which no thread started reports no error.

Fixes are planned for the next version, in both samples. A bad lookup
will have its own message. A thread that fails to start will fail the
module load.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com