On Tue, May 19, 2026 at 08:49:30PM +0800, Cen Zhang wrote:

Hi John,

Thanks a lot for the review.

On Tue, May 19, 2026 at 05:32:00AM +0000, John Fastabend wrote:

quoted

Important note here on where this actually happens. It will only
effect users of BPF programs that are making the push/pop/..
calls. So most/all users should not be impacted. Agree though lets
fix this.

Thanks, that makes sense. We will make the impact scope clearer in the
next version.

quoted

To make this easier to read I think having a,

static void sk_msg_clear_elem_copy(struct sk_msg *msg, u32 i, bool copy)
{
__clear_bit(i, msg->sg.copy);
}

is nice to have. Otherwise we get lots of

sk_msg_clear_elem_copy(..., false)

Or just direclty call __clear_bit() is also cleaner.
This is sk_msg_sg_move()?

Agreed. We will clean this up in v3, either by directly clearing the bit
where appropriate or by using a small helper if that makes the move logic
clearer.

quoted

I think we need another fix here,

           rsge.offset += start - offset;

Probably carry in another patch. I can do it if you want?
sk_msg_sg_move()?

I think this is good with small cleanup. The bot report (need to check
again), but I think it was calling out another issue with a different
fix/patch needed.

Do you want to follow up with the other couple addons or should I?

Also please add a test for this so we capture it in selftests.

We would like to follow up with a patch series to address this and the
related fixes. We will also do our best to add a selftest for this. We are
not very familiar with the BPF selftest infrastructure yet, but we will
do our best to follow the existing tests.

Thanks again for the guidance.

Great. I think its fine to address the tools extra callouts in a follow
on PR if you want. If it helps get this merged sooner lets do that. All
the tooling keeps hitting this and we have lots of duplicate reports.

Thanks,
Zhang Cen