Re: [RFC PATCH bpf-next v3 03/10] bpf: Refactor reporting log_true_size for prog_load

[Leon Hwang <leon.hwang@linux.dev>]

On 3/10/25 02:34, Alexei Starovoitov wrote:
> On Thu, Oct 2, 2025 at 8:49 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> In the next commit, it will be able to report logs via extended common
>> attributes, which will report 'log_true_size' via the extended common
>> attributes meanwhile.
>>
>> Therefore, refactor the way of 'log_true_size' reporting in order to
>> report 'log_true_size' via the extended common attributes easily.
>>

[...]

>>
>> +static int copy_prog_load_log_true_size(union bpf_attr *attr, bpfptr_t uattr, unsigned int size)
>> +{
>> +       if (!attr->log_true_size)
>> +               return 0;
> 
> We've been through this many times :(
> The commit log says that it's a refactoring patch, but
> you introduce this new logic.
> Do NOT do it.
> If you want to add such additional check, do it in a separate patch
> and explain why it's ok.
> 
> So why is it ok to skip writing to user space when it's zero?
> 

My mistake — I see now that introducing this extra check changes the
behavior and doesn't belong in a refactoring patch.

My original intention was just to avoid calling copy_to_user() when
there is no log, but as you pointed out, it's important to still report
log_true_size back to user space, even if it's zero. That way, users can
reliably check if a log is present.

I'll drop this new logic in the next revision and keep the patch
strictly as a refactoring.

Thanks,
Leon