lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 30 Apr 2022 10:18:42 -0700 From: Cong Wang <xiyou.wangcong@...il.com> To: Jakub Sitnicki <jakub@...udflare.com> Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>, Cong Wang <cong.wang@...edance.com>, Eric Dumazet <edumazet@...gle.com>, John Fastabend <john.fastabend@...il.com>, Daniel Borkmann <daniel@...earbox.net> Subject: Re: [Patch bpf-next v1 1/4] tcp: introduce tcp_read_skb() On Tue, Apr 26, 2022 at 2:12 AM Jakub Sitnicki <jakub@...udflare.com> wrote: > > On Sun, Apr 10, 2022 at 09:10 AM -07, Cong Wang wrote: > > From: Cong Wang <cong.wang@...edance.com> > > > > This patch inroduces tcp_read_skb() based on tcp_read_sock(), > > a preparation for the next patch which actually introduces > > a new sock ops. > > > > TCP is special here, because it has tcp_read_sock() which is > > mainly used by splice(). tcp_read_sock() supports partial read > > and arbitrary offset, neither of them is needed for sockmap. > > > > Cc: Eric Dumazet <edumazet@...gle.com> > > Cc: John Fastabend <john.fastabend@...il.com> > > Cc: Daniel Borkmann <daniel@...earbox.net> > > Cc: Jakub Sitnicki <jakub@...udflare.com> > > Signed-off-by: Cong Wang <cong.wang@...edance.com> > > --- > > include/net/tcp.h | 2 ++ > > net/ipv4/tcp.c | 72 +++++++++++++++++++++++++++++++++++++++++------ > > 2 files changed, 66 insertions(+), 8 deletions(-) > > > > diff --git a/include/net/tcp.h b/include/net/tcp.h > > index 6d50a662bf89..f0d4ce6855e1 100644 > > --- a/include/net/tcp.h > > +++ b/include/net/tcp.h > > @@ -667,6 +667,8 @@ void tcp_get_info(struct sock *, struct tcp_info *); > > /* Read 'sendfile()'-style from a TCP socket */ > > int tcp_read_sock(struct sock *sk, read_descriptor_t *desc, > > sk_read_actor_t recv_actor); > > +int tcp_read_skb(struct sock *sk, read_descriptor_t *desc, > > + sk_read_actor_t recv_actor); > > Do you think it would be worth adding docs for the newly added function? > Why it exists and how is it different from the tcp_read_sock which has > the same interface? Yeah, I will add some comments to explain this in V2. Thanks.
Powered by blists - more mailing lists