[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0190e181-c592-454a-a99b-5ec361ce84e9@linux.dev>
Date: Thu, 24 Jul 2025 08:52:04 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Jakub Sitnicki <jakub@...udflare.com>
Cc: Jakub Kicinski <kuba@...nel.org>, bpf@...r.kernel.org,
Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>,
Arthur Fabre <arthur@...hurfabre.com>, Daniel Borkmann
<daniel@...earbox.net>, Eduard Zingerman <eddyz87@...il.com>,
Eric Dumazet <edumazet@...gle.com>, Jesper Dangaard Brouer
<hawk@...nel.org>, Jesse Brandeburg <jbrandeburg@...udflare.com>,
Joanne Koong <joannelkoong@...il.com>, Lorenzo Bianconi
<lorenzo@...nel.org>, Toke Høiland-Jørgensen
<thoiland@...hat.com>, Yan Zhai <yan@...udflare.com>,
kernel-team@...udflare.com, netdev@...r.kernel.org,
Stanislav Fomichev <sdf@...ichev.me>
Subject: Re: [PATCH bpf-next v4 2/8] bpf: Enable read/write access to skb
metadata through a dynptr
On 7/24/25 4:53 AM, Jakub Sitnicki wrote:
> In this series we maintain the status quo. Access metadata dynptr is
> limited to TC BPF hook only, so we provide the same guarntees as the
> existing __sk_buff->data_meta.
The verifier tracks if the __sk_buff->data_meta is written in
"seen_direct_write". tc_cls_act_prologue is called and that should have
triggered skb_metadata_clear for a clone skb. Meaning, for a clone skb, I think
__sk_buff->data_meta is read-only.
bpf_dynptr_from_skb_meta can set the DYNPTR_RDONLY_BIT if the skb is a clone.
Powered by blists - more mailing lists