Re: [PATCH bpf-next v2] bpf: Fix mmap_lock leak in irq_work path

> maybe we should make bpf_mmap_unlock_get_irq_work() return `struct
> mmap_unlock_irq_work *` which would be ERR_PTR(), and return
> ERR_PTR(-EBUSY) if (active || irq_work_is_busy) (see below)? I'd
> probably call it bpf_mmap_unlock_guard_get(), though. And then we will
> have bpf_mmap_unlock_guard_put() (instead of
> bpf_mmap_unlock_put_irq_work) with the same logic.

Yes, I think this would make the code a bit more straightforward.

> we drop active to zero here, but irq_work_is_busy() can still return
> true, I think we do need to check both

Yes, BUSY can still be set after active is cleared. However, since the work can
be queued again while the callback is still running, I thought active alone was
enough. I also tested it in a widened window, and didn't see a lock leak.

But I may be missing something. Could requeueing the work here cause a problem,
or is this mainly to keep the original -EBUSY behavior?