search for: tap_get_user

...996ed7cbf18 100644 > --- a/drivers/net/tap.c > +++ b/drivers/net/tap.c > @@ -619,7 +619,7 @@ static inline struct sk_buff *tap_alloc_skb(struct sock *sk, size_t prepad, > #define TAP_RESERVE HH_DATA_OFF(ETH_HLEN) > > /* Get packet from user space buffer */ > -static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m, > +static ssize_t tap_get_user(struct tap_queue *q, void *msg_control, > struct iov_iter *from, int noblock) > { > int good_linear = SKB_MAX_HEAD(TAP_RESERVE); > @@ -663,7 +663,7 @@ static ssize_t tap_get_user(struct tap_queue *q, str...

...ers/net/tap.c index f0f7cd977667..7996ed7cbf18 100644 --- a/drivers/net/tap.c +++ b/drivers/net/tap.c @@ -619,7 +619,7 @@ static inline struct sk_buff *tap_alloc_skb(struct sock *sk, size_t prepad, #define TAP_RESERVE HH_DATA_OFF(ETH_HLEN) /* Get packet from user space buffer */ -static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m, +static ssize_t tap_get_user(struct tap_queue *q, void *msg_control, struct iov_iter *from, int noblock) { int good_linear = SKB_MAX_HEAD(TAP_RESERVE); @@ -663,7 +663,7 @@ static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m, if (unli...

...on. But for now, let's see if we can > > address these edge cases. > > Ack > > > > > > I'm not familiar with tap code, so someone else will need to patch this > > > case, but it looks like: > > > > > > tap_sendmsg() > > > tap_get_user() > > > skb_probe_transport_header() > > > skb_flow_dissect_flow_keys_basic() > > > __skb_flow_dissect() > > > > > > skb->dev is only set later in the code. > > > > tap_get_user uses sock_alloc_send_pskb...

...oducer is not reliable. > > Yes, it is caused by commit d0e13a1488ad ("flow_dissector: lookup netns > by skb->sk if skb->dev is NULL") > > $ git tag --contains d0e13a1488ad > v4.20-rc1 > v4.20-rc2 > v4.20-rc3 > v4.20-rc4 > v4.20-rc5 > v4.20-rc6 That tap_get_user_xdp path is also new for 4.20-rc1: commit 0efac27791ee068075d80f07c55a229b1335ce12 tap: accept an array of XDP buffs through sendmsg() $ git describe --contains 0efac27791ee v4.20-rc1~14^2~382^2~1 In v4.19 and before all packets went through tap_get_user.

...oducer is not reliable. > > Yes, it is caused by commit d0e13a1488ad ("flow_dissector: lookup netns > by skb->sk if skb->dev is NULL") > > $ git tag --contains d0e13a1488ad > v4.20-rc1 > v4.20-rc2 > v4.20-rc3 > v4.20-rc4 > v4.20-rc5 > v4.20-rc6 That tap_get_user_xdp path is also new for 4.20-rc1: commit 0efac27791ee068075d80f07c55a229b1335ce12 tap: accept an array of XDP buffs through sendmsg() $ git describe --contains 0efac27791ee v4.20-rc1~14^2~382^2~1 In v4.19 and before all packets went through tap_get_user.

...e provided value. >>> So if the driver is currently not precise, it breaks tap. >> Well that's only for gso though right? > Yep. > > >> And making it bigger than necessary works fine ... > Well yeah. But tap does not do that, does it? it uses hdr_len directly. tap_get_user() limit the head length: static ssize_t tap_get_user(struct tap_queue *q, void *msg_control, ??????????????????????????? struct iov_iter *from, int noblock) { ?? ?int good_linear = SKB_MAX_HEAD(TAP_RESERVE); ... > > >>> I will add this to the patch description and send v2. >...

...was an invariant. If there are too many exceptions, I may have to revisit that assumption. But for now, let's see if we can address these edge cases. > I'm not familiar with tap code, so someone else will need to patch this > case, but it looks like: > > tap_sendmsg() > tap_get_user() > skb_probe_transport_header() > skb_flow_dissect_flow_keys_basic() > __skb_flow_dissect() > > skb->dev is only set later in the code. tap_get_user uses sock_alloc_send_pskb (through tap_alloc_skb) to allocate the skb. So skb->sk should be...

Hi all: This series tries to batch submitting packets to underlayer socket through msg_control during sendmsg(). This is done by: 1) Doing userspace copy inside vhost_net 2) Build XDP buff 3) Batch at most 64 (VHOST_NET_BATCH) XDP buffs and submit them once through msg_control during sendmsg(). 4) Underlayer sockets can use XDP buffs directly when XDP is enalbed, or build skb based on XDP

Hi all: This series tries to batch submitting packets to underlayer socket through msg_control during sendmsg(). This is done by: 1) Doing userspace copy inside vhost_net 2) Build XDP buff 3) Batch at most 64 (VHOST_NET_BATCH) XDP buffs and submit them once through msg_control during sendmsg(). 4) Underlayer sockets can use XDP buffs directly when XDP is enalbed, or build skb based on XDP

Hi all: This series tries to batch submitting packets to underlayer socket through msg_control during sendmsg(). This is done by: 1) Doing userspace copy inside vhost_net 2) Build XDP buff 3) Batch at most 64 (VHOST_NET_BATCH) XDP buffs and submit them once through msg_control during sendmsg(). 4) Underlayer sockets can use XDP buffs directly when XDP is enalbed, or build skb based on XDP

...letions(-) > > diff --git a/drivers/net/tap.c b/drivers/net/tap.c > index 7996ed7cbf18..50eb7bf22225 100644 > --- a/drivers/net/tap.c > +++ b/drivers/net/tap.c > @@ -1146,14 +1146,83 @@ static const struct file_operations tap_fops = { > #endif > }; > > +static int tap_get_user_xdp(struct tap_queue *q, struct xdp_buff *xdp) > +{ > + struct virtio_net_hdr *gso = xdp->data_hard_start + sizeof(int); > + int buflen = *(int *)xdp->data_hard_start; > + int vnet_hdr_len = 0; > + struct tap_dev *tap; > + struct sk_buff *skb; > + int err, depth; > + &...

...aused by commit d0e13a1488ad ("flow_dissector: lookup netns >> by skb->sk if skb->dev is NULL") >> >> $ git tag --contains d0e13a1488ad >> v4.20-rc1 >> v4.20-rc2 >> v4.20-rc3 >> v4.20-rc4 >> v4.20-rc5 >> v4.20-rc6 > > That tap_get_user_xdp path is also new for 4.20-rc1: > > commit 0efac27791ee068075d80f07c55a229b1335ce12 > tap: accept an array of XDP buffs through sendmsg() > > $ git describe --contains 0efac27791ee > v4.20-rc1~14^2~382^2~1 > > In v4.19 and before all packets went throug...

...++++++++-- 1 file changed, 71 insertions(+), 2 deletions(-) diff --git a/drivers/net/tap.c b/drivers/net/tap.c index 7996ed7cbf18..50eb7bf22225 100644 --- a/drivers/net/tap.c +++ b/drivers/net/tap.c @@ -1146,14 +1146,83 @@ static const struct file_operations tap_fops = { #endif }; +static int tap_get_user_xdp(struct tap_queue *q, struct xdp_buff *xdp) +{ + struct virtio_net_hdr *gso = xdp->data_hard_start + sizeof(int); + int buflen = *(int *)xdp->data_hard_start; + int vnet_hdr_len = 0; + struct tap_dev *tap; + struct sk_buff *skb; + int err, depth; + + if (q->flags & IFF_VNET_HDR) +...

Mon, Feb 20, 2023 at 01:55:33PM CET, mst at redhat.com wrote: >On Mon, Feb 20, 2023 at 09:35:00AM +0100, Jiri Pirko wrote: >> Fri, Feb 17, 2023 at 02:47:36PM CET, mst at redhat.com wrote: >> >On Fri, Feb 17, 2023 at 01:53:55PM +0100, Jiri Pirko wrote: >> >> Fri, Feb 17, 2023 at 01:22:01PM CET, mst at redhat.com wrote: >> >> >On Fri, Feb 17, 2023 at

...> [85109.572130] ([<0000000000000000>] (null)) >> [85109.572134] [<000003ff800c81e4>] tap_sendmsg+0x384/0x430 [tap] > > I'm not familiar with tap code, so someone else will need to patch this > case, but it looks like: > > tap_sendmsg() > tap_get_user() > skb_probe_transport_header() > skb_flow_dissect_flow_keys_basic() > __skb_flow_dissect() > > skb->dev is only set later in the code. > >> [85109.572137] [<000003ff801acdee>] vhost_tx_batch.isra.10+0x66/0xe0 [vhost_net] >> [85109.5...

...expectation that in-kernel devices support this feature, and > >> >if so how would it affect them? If I read the spec correctly, devices > >> > >> Well, the tap driver actually trusts the hdr_len to be of correct header > >> size nowadays. > > > >tap_get_user performs basic bounds checking on the length passed. > > Sure. It trusts the hdr_len, but it sanitizes the input. > > > > > >> > >> >still need to be careful against malicious drivers, so cannot assume > >> >much beyond what they do today (i.e....