Re: [PATCH v3 bpf-next 05/11] resolve_btfids: Tag the functions that return errors

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Sat Nov 14, 2026 at 9:07 PM UTC, David Windsor wrote:
> On Sat, Nov 14, 2026 at 3:00 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Sat, Nov 14, 2026 at 11:37 AM David Windsor <dwindsor@gmail.com> wrote:
>> > Do we also need -EBUSY here as an exception? crypto_enqueue_request
>> > uses it to mean the request was queued on the backlog (not that it
>> > failed)
>>
>> Good point. -EBUSY is not a failure there, -ENOSPC is.
>> A prog that returns -EBUSY skips the list_add_tail().
>> crypto_wait_req() then waits for a completion that never comes.
>>
>> In most other functions -EBUSY is a plain failure, so means_failure()
>> can't drop it for all.
>> ccp_enqueue_cmd() and qat_alg_send_message_maybacklog() have such
>> a backlog too. All three also return -EINPROGRESS.
>> So drop -EBUSY only if the function returns -EINPROGRESS too.
>> crypto_enqueue_request() stays a target with -ENOSPC.
>>
>> Here is proposed follow up... other ideas?
>>
>
> Looks good, selftest looks right.

sent a follow up, since it's trivial and doesn't change fmodret list.

> Other interesting edge cases my bot identified:
>
> 1. bit_wait() in kernel/sched/wait_bit.c returns -EINTR to report the
> status of the waiting task, not to indicate failure
> 2. try_mem_charge_cg returns -ENOMEM, but callers might not be set up
> to handle it, it can be masked by __GFP_NOFAIL. Such callers won't
> expect an error there.

BTF can answer that, but I'm going to table that for now,
since chasing long tail is never going to end.
We're not aiming for 100% safety.