From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Alexei Starovoitov <ast@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Lorenzo Bianconi <lorenzo@kernel.org>, bpf <bpf@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH] bpf: fix reference count leak in bpf_prog_test_run_xdp()
Date: Thu, 08 Jan 2026 15:44:55 +0100 [thread overview]
Message-ID: <87o6n42mfs.fsf@toke.dk> (raw)
In-Reply-To: <1db0fa14-af3b-47e6-93dc-0adffaa3d934@I-love.SAKURA.ne.jp>
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
> On 2026/01/08 23:01, Toke Høiland-Jørgensen wrote:
>> Hmm, this will end up call bpf_ctx_finish() in the error path, which I'm
>> not sure we want?
>
> Excuse me, but I don't think bpf_ctx_finish() will be called, for
>
> +out_put_dev:
> /* We convert the xdp_buff back to an xdp_md before checking the return
> * code so the reference count of any held netdevice will be decremented
> * even if the test run failed.
> */
> xdp_convert_buff_to_md(&xdp, ctx);
> if (ret) // <== ret was set to non-0 value immediately before the "goto out_put_dev;" line.
> goto out;
Oh, right; I think my brain just pattern matched on "if (ret) right
after a function call" and assumed there was an assignment to ret there
as well :D
Okay, not the clearest code flow, but not sure there's a good way to
make it clearer without quite a bit of refactoring.
>
> size = xdp.data_end - xdp.data_meta + sinfo->xdp_frags_size;
> ret = bpf_test_finish(kattr, uattr, xdp.data_meta, sinfo, size, sinfo->xdp_frags_size,
> retval, duration);
> if (!ret)
> ret = bpf_ctx_finish(kattr, uattr, ctx,
> sizeof(struct xdp_md));
>
>>
>> Could we just move the xdp_convert_md_to_buff() call to after the frags
>> have been copied? Not sure there's technically any dependency there,
>> even though it does look a little off?
>
> Unless
>
> xdp_md->data = xdp->data - xdp->data_meta;
> xdp_md->data_end = xdp->data_end - xdp->data_meta;
>
> in xdp_convert_buff_to_md() lines do something bad for the error path,
> I think this change will be safe.
Yeah, sure, this should be fine.
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
next prev parent reply other threads:[~2026-01-08 14:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 12:36 [PATCH] bpf: fix reference count leak in bpf_prog_test_run_xdp() Tetsuo Handa
2026-01-08 14:01 ` Toke Høiland-Jørgensen
2026-01-08 14:18 ` Tetsuo Handa
2026-01-08 14:44 ` Toke Høiland-Jørgensen [this message]
2026-01-13 2:25 ` 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=87o6n42mfs.fsf@toke.dk \
--to=toke@redhat.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=john.fastabend@gmail.com \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/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.