search for: skb_clone

...q/vlan_dev.c 2003-10-07 16:01:29.000000000 +0200 >@@ -75,7 +75,12 @@ > static inline struct sk_buff *vlan_check_reorder_header(struct sk_buff >*skb) > { > if (VLAN_DEV_INFO(skb->dev)->flags & 1) { >- skb = skb_share_check(skb, GFP_ATOMIC); >+ if (skb_shared(skb) || skb_cloned(skb)) { >+ struct sk_buff *nskb; >+ nskb = skb_copy(skb, GFP_ATOMIC); >+ kfree_skb(skb); >+ skb = nskb; >+ } > if (skb) { > /* Lifted from Gleb's VLAN code... */ > memmove(skb->data - ETH_HLEN, > > >Christian, could you try this out? Thank...

...clone" flag. For distributing locally generated traffic, br_flood() is called in the mode "clone=0". This mode works like this: /* deliver this: */ sk_buff* skb; prev_port=NULL; port=tail of bridge port list; while (port) { if (prev_port != NULL) { deliver (prev_port, skb_clone (skb)); } prev_port = port; port = next bridge port in list; } if (prev_port) { deliver (prev_port, skb); return; } kfree_skb (skb); This results in clones of the original sk_buff being send through all bridge ports except for the last in list traversal. This port receives the...

...f **pskb, unsigned int untagged) +{ + struct sk_buff *skb = *pskb; + + if (skb->vlan == 0) /* don't touch the frame */ + return 0; + + if (skb->vlan == untagged) { + /* frame should be untagged */ + if (eth_hdr(skb)->h_proto == htons(ETH_P_8021Q)) { + /* remove VLAN tag */ + if (skb_cloned(skb) || skb_shared(skb)) { + struct sk_buff *new_skb; + + new_skb = skb_copy(skb, GFP_ATOMIC); + kfree_skb(skb); + if (!new_skb) + return 1; + *pskb = skb = new_skb; + } + + skb->mac.raw += VLAN_HLEN; + memmove(skb->mac.raw, skb->data, ETH_ALEN * 2); + skb_pull(...

...ister_netdevice_notifier) = 0x63ecad53 kernel(register_pernet_gen_device) = 0x72428be7 kernel(rtnl_lock) = 0xc7a4fbed kernel(rtnl_unlock) = 0x6e720ff2 kernel(schedule) = 0x01000e51 kernel(sk_release_kernel) = 0x829200f4 kernel(skb_checksum) = 0x10af67fe kernel(skb_checksum_help) = 0x72fad770 kernel(skb_clone) = 0xd87b0b1f kernel(skb_copy_and_csum_dev) = 0x51154c2a kernel(skb_copy_bits) = 0x20242fb9 kernel(skb_gso_segment) = 0x3461dbb2 kernel(skb_pull) = 0xd3c80841 kernel(skb_pull_rcsum) = 0xc238d18d kernel(skb_push) = 0x3229caeb kernel(skb_put) = 0x207b7e2c kernel(skb_trim) = 0xc01e3b23 kernel(sock_cre...

When I was preparing Xen''s netback driver for upstream one of the things I removed was the zero-copy guest transmit (i.e. netback receive) support. In this mode guest data pages ("foreign pages") were mapped into the backend domain (using Xen grant-table functionality) and placed into the skb''s paged frag list (skb_shinfo(skb)->frags, I hope I am using the right

>-----Original Message----- >From: Ben Greear [mailto:greearb@candelatech.com] >Sent: Monday, October 06, 2003 10:24 PM >To: Bart De Schuymer >Cc: netdev@oss.sgi.com; vlan@wanfear.com; bridge >Subject: [VLAN] Re: [PATCH/RFC] Let {ip,arp}tables "see" bridged VLAN >tagged{I,AR}P packets > > >Bart De Schuymer wrote: >> - add some code in

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 "vhost-net: flush outstanding DMAs on memory change" vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in

vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 "vhost-net: flush outstanding DMAs on memory change" vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

On Thu, Nov 02, 2017 at 11:40:36AM +0000, Ilya Lesokhin wrote: > Hi, > I've noticed that the virtio-net uses skb->cb. > > I don't know all the detail by my understanding is it caused problem with the mlx5 driver > and was fixed here: > https://github.com/torvalds/linux/commit/34802a42b3528b0e18ea4517c8b23e1214a09332 > > Thanks, > Ilya Thanks a lot for the

On Thu, Nov 02, 2017 at 11:40:36AM +0000, Ilya Lesokhin wrote: > Hi, > I've noticed that the virtio-net uses skb->cb. > > I don't know all the detail by my understanding is it caused problem with the mlx5 driver > and was fixed here: > https://github.com/torvalds/linux/commit/34802a42b3528b0e18ea4517c8b23e1214a09332 > > Thanks, > Ilya Thanks a lot for the

hi i tried the example given on the examples page to duplicate selected traffic like tc qdisc add dev eth0 root handle 1: prio tc qdisc add dev eth0 parent 1:3 handle 3: netem duplicate 40% tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst 11.0.2.2 flowid 1:3 when i ping from 11.0.2.2 to this interface my machine hangs. the same thing works for drop or delay. i would

...skb_get() lost at somewhere? > >> I reverted above commit the panic not occurred during our testing. > >> > >> Any input will appreciate! > > > > Well, fact is that your crash is happening in skb_copy(). > > > > Frank patch is OK. I suspect using skb_clone() would work too, > > so if these skb were fclone ready, chance of an GFP_ATOMIC allocation > > error would be smaller. > > > > So something is providing a wrong skb at the very beginning. > > > > You could try to do a early skb_copy to catch the bug and see in...

...ed: a small performance increase is > observed with batching (~2%), but buf_api makes tests perform equally > to baseline. > > pktgen was called using pktgen_sample01_simple.sh, with the environment: > DEV="$tap_name" F_THREAD=1 DST_MAC=$MAC_ADDR COUNT=$((2500000*25)) > SKB_CLONE=$((2**31)) > > And testpmd is the same as Tx but with forward-mode=rxonly. > > Pktgen reports: > Baseline: 1853025pps 622Mb/sec (622616400bps) errors: 7915231 > Batch: 1891404pps 635Mb/sec (635511744bps) errors: 4926093 > Buf_api: 1844008pps 619Mb/sec (619586688bps) errors: 4...

Looks like the GSO is involved? I got this while running Dom0 only (no guests), with a BOINC/Rosetta@home application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1133! invalid opcode: 0000 [#1] SMP CPU: 0 EIP: 0061:[<c04dceb0>] Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen