Re: [PATCH RFC v3 04/10] bpf: Add lock-free cell for NMI-safe async operations

[Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>]

On 1/9/26 01:18, Andrii Nakryiko wrote:
> On Wed, Jan 7, 2026 at 11:05 AM Mykyta Yatsenko
> <mykyta.yatsenko5@gmail.com> wrote:
>> On 1/7/26 18:30, Kumar Kartikeya Dwivedi wrote:
>>> On Wed, 7 Jan 2026 at 18:49, Mykyta Yatsenko <mykyta.yatsenko5@gmail.com> wrote:
>>>> From: Mykyta Yatsenko <yatsenko@meta.com>
>>>>
>>>> Introduce mpmc_cell, a lock-free cell primitive designed to support
>>>> concurrent writes to struct in NMI context (only one writer advances),
>>>> allowing readers to consume consistent snapshot.
>>>>
>>>> Implementation details:
>>>>    Double buffering allows writers run concurrently with readers (read
>>>>    from one cell, write to another)
>>>>
>>>>    The implementation uses a sequence-number-based protocol to enable
>>>>    exclusive writes.
>>>>     * Bit 0 of seq indicates an active writer
>>>>     * Bits 1+ form a generation counter
>>>>     * (seq & 2) >> 1 selects the read cell, write cell is opposite
>>>>     * Writers atomically set bit 0, write to the inactive cell, then
>>>>       increment seq to publish
>>>>     * Readers snapshot seq, read from the active cell, then validate
>>>>       that seq hasn't changed
>>>>
>>>> mpmc_cell expects users to pre-allocate double buffers.
>>>>
>>>> Key properties:
>>>>    * Writers never block (fail if lost the race to another writer)
>>>>    * Readers never block writers (double buffering), but may require
>>>>    retries if write updates the snapshot concurrently.
>>>>
>>>> This will be used by BPF timer and workqueue helpers to defer NMI-unsafe
>>>> operations (like hrtimer_start()) to irq_work effectively allowing BPF
>>>> programs to initiate timers and workqueues from NMI context.
>>>>
>>>> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
>>>> ---
>>> We already have a dual-versioned concurrency control primitive in the
>>> kernel (seqcount_latch_t). I would just use that instead of
>>> reinventing it here. I don't see much of a difference except writer
>>> serialization, which can be done on top of it. If it was already
>>> considered and discarded for some reason, please add that reason to
>>> the commit message.
>> yes, multiple concurrent  writers support would is the main difference
>> between seqcount_latch_t and my implementation. I'll switch to
>> seqcount_latch_t and external synchronization for writers.
> One advantage of custom primitive is that we don't need a second
> atomic counter for writers. Here we combine the reader latch counter
> (it's just scaled 2x for custom implementation) and "writer is active"
> bit (even/odd counter).
>
> With potentially millions of timer activations per second for some
> extreme cases, would performance be enough reason to have custom
> "seqlock latch"? (I'm not sure myself, trying to get opinions)
>
Actually seqcount_latch_t variant may be faster (correct me if I'm wrong),
because mpmc_cell requires 2 lock prefixed instructions to enter the write
critical section and seqcount_latch_t just 1.

mpmc_cell:

if (1&atomic_fetch_or_acquire(1, &ctl->seq)) // first lock prefixed insn
return;
...
       atomic_fetch_add_release(1, &ctl->seq);     // second lock 
prefixed insn

seqcount_latch_t based:

     if (atomic_cmpxchg(&ctl->lock, 0, 1))        // first lock prefixed 
insn
         return;
write_seqcount_latch_begin(&ctl->seq);       // inc with barriers
     ...
     write_seqcount_latch(&ctl->seq);            // inc with barriers
     atomic_set(&ctl->lock, 0);            // plain mov on x86_64

Does it look right?
>>>>    [...]
>>>>