All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v1 1/2] bpf: Fix tracing of kfuncs with implicit args
Date: Fri, 10 Jul 2026 12:34:21 -0700	[thread overview]
Message-ID: <96c07e3a-88f5-4929-aa53-0efb2c2bb0cd@linux.dev> (raw)
In-Reply-To: <DJV2Q54OF8BU.1H6KXCS93P3N6@gmail.com>

On 7/10/26 10:40 AM, Kumar Kartikeya Dwivedi wrote:
> On Fri Jul 10, 2026 at 7:34 PM CEST, Ihor Solodrai wrote:
>> On 7/10/26 10:23 AM, Kumar Kartikeya Dwivedi wrote:
>>> [...]
>>>
>>> Also, why not do it for BPF_TRACE_ITER case as well? I just feel keeping it
>>> consistent may outweigh figuring out whether it's necessary in that case or not,
>>> etc.
>>
>>
>> I mentioned this in the patch description:
>>
>>   The BPF_TRACE_ITER case distills a registered iterator's
>>   prototype, and bpf_struct_ops_desc_init() distills the
>>   function-pointer members of a struct_ops type. Neither is
>>   a kfunc, and so can't have implicit arguments.
>>
> 
> Yeah, I saw that, but abstracting that inside the function and not having to
> think from the caller about those details would be better. That said, I don't
> have any strong preference, it is obviously correct as it is.

Let's keep the fix patch minimal. I think we can do a more thoughtful
refactoring as a follow up for bpf-next. Hopefully I'll find time for
this in not so distant future.

Just sent a v2 with a module ref fix and a brief cover.

> 
>>
>>>
>>> Please supply a cover letter in the next version too since you're sending
>>> multiple patches.
>>
>> I used the first patch's message as a cover letter, since it's
>> just a fix + selftest pair.
>>
>> The series could be split further into refactoring changes, but I thought
>> it'll be easier to backport if the fix is in a single self-contained patch.
>>
>> I think we want the fix to get into 7.2, and backport it to 7.1.
>>
>> If it's ok to carry separate refactoring patches there, then I'll split.
>> Kartikeya, wdyt?
>>
> 
> You can still keep the patches as is, but just add a cover letter, it will not
> affect backporting. The cover letter is just to summarize the series and the fix
> in the merge commit. Also, my understanding is that with the Fixes: tag, it
> should automatically be picked up for stable kernels.


      reply	other threads:[~2026-07-10 19:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10  0:59 [PATCH bpf v1 1/2] bpf: Fix tracing of kfuncs with implicit args Ihor Solodrai
2026-07-10  0:59 ` [PATCH bpf v1 2/2] selftests/bpf: Cover tracing implicit kfunc args Ihor Solodrai
2026-07-10  1:21 ` [PATCH bpf v1 1/2] bpf: Fix tracing of kfuncs with implicit args sashiko-bot
2026-07-10 17:08   ` Ihor Solodrai
2026-07-10 17:23     ` Kumar Kartikeya Dwivedi
2026-07-10 17:34       ` Ihor Solodrai
2026-07-10 17:40         ` Kumar Kartikeya Dwivedi
2026-07-10 19:34           ` Ihor Solodrai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=96c07e3a-88f5-4929-aa53-0efb2c2bb0cd@linux.dev \
    --to=ihor.solodrai@linux.dev \
    --cc=bpf@vger.kernel.org \
    --cc=memxor@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.