From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
Yiming Qian <yimingqian591@gmail.com>,
Zhang Cen <rollkingzzc@gmail.com>,
Han Guidong <2045gemini@gmail.com>
Cc: bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org,
memxor@gmail.com, eddyz87@gmail.com, tj@kernel.org
Subject: Re: [GIT PULL] BPF changes for 7.2
Date: Wed, 17 Jun 2026 16:51:12 +0800 [thread overview]
Message-ID: <1c178c2f-358c-4933-b74e-36522f699f71@linux.dev> (raw)
In-Reply-To: <CAHk-=wjAVP3uu1inFqxeGmk5bTJqm204kxcWu8zzDGFNOh=Q7A@mail.gmail.com>
On 6/17/26 4:37 PM, Linus Torvalds wrote:
> On Mon, 15 Jun 2026 at 19:09, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>> There are two conflicts:
> Actually, since I ended up doing things a bit out of order and did the
> networking pull first, there were three conflicts, and while the two
> you mentioned were trivial, the one to net/core/filter.c was a bit
> different. Both networking and bpf had done "make sure to preserve the
> sg.copy" bits, but done it quite differently.
>
> And I think bpf did some things better, and the networking tree did
> other things better, so my resolution is actually a mix of the two.
>
> bpf had nicely named helper functions.
>
> And the networking version used __assign_bit() instead of duplicating that
>
> if (set)
> set_bit
> else
> clear_bit
>
> pattern.
>
> So my resolution is to take a bit from column A, and a bit from column B.
>
> And the networking tree had a case of clearing the sg.copy fields (in
> bpf_msg_pull_data()) that the bpf tree didn't have at all - but I took
> the nicer helper function from the bpf side.
>
> Did I get everything right? It _looks_ right to me, and better than
> either side on their own. But mistakes happen. Please check out my
> resolution and send me fixes from whatever I may have messed up.
>
> It doesn't help that I did this on my laptop while traveling - I hate
> not having my big monitors and better test build environment, but I
> tried to be careful, and it builds for me in my limited test
> environment.
>
> Please give it a good once-over - I've cc'd everybody involved on both
> sides of the conflicting changes.
>
> Linus
Thanks, Linus. I was just trying to figure out how to send a patch to
avoid this merge conflict.
The resolution looks correct to me.
One tiny thing: the call to sk_msg_set_elem_copy() in sk_msg_sg_move() has a
trailing tab — it doesn't matter at all, and I'll clean it up next time I
touch that code.
Sorry for the inconvenience.
next prev parent reply other threads:[~2026-06-17 8:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 18:08 [GIT PULL] BPF changes for 7.2 Alexei Starovoitov
2026-06-17 8:37 ` Linus Torvalds
2026-06-17 8:51 ` Jiayuan Chen [this message]
2026-06-17 8:40 ` pr-tracker-bot
2026-06-17 17:16 ` patchwork-bot+netdevbpf
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=1c178c2f-358c-4933-b74e-36522f699f71@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=2045gemini@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kuba@kernel.org \
--cc=memxor@gmail.com \
--cc=rollkingzzc@gmail.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=yimingqian591@gmail.com \
/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.