Displaying 16 results from an estimated 16 matches for "tap_get_us".
Did you mean:
tap_get_user
2018 Sep 06
1
[PATCH net-next 08/11] tun: switch to new type of msg_control
...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, s...
2018 Sep 06
0
[PATCH net-next 08/11] tun: switch to new type of msg_control
...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 (un...
2018 Dec 20
1
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
...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_ps...
2018 Dec 20
2
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
...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.
2018 Dec 20
2
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
...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.
2023 Feb 21
1
[patch net-next] net: virtio_net: implement exact header length guest feature
...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.
&g...
2018 Dec 20
0
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
...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...
2018 Sep 06
22
[PATCH net-next 00/11] Vhost_net TX batching
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
2018 Sep 12
14
[PATCH net-next V2 00/11] vhost_net TX batching
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
2018 Sep 12
14
[PATCH net-next V2 00/11] vhost_net TX batching
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
2018 Sep 06
1
[PATCH net-next 10/11] tap: accept an array of XDP buffs through sendmsg()
...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;
> +...
2018 Dec 21
0
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
...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 thro...
2018 Sep 06
0
[PATCH net-next 10/11] tap: accept an array of XDP buffs through sendmsg()
...++++++++--
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)
+...
2023 Feb 20
2
[patch net-next] net: virtio_net: implement exact header length guest feature
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
2018 Dec 20
0
4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect
...> [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...
2023 Feb 22
1
[patch net-next v2] net: virtio_net: implement exact header length guest feature
...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....