* Re: kernel panic receiving flooded VXLAN traffic with OVS
From: Pravin Shelar @ 2014-11-07 23:06 UTC (permalink / raw)
To: Jesse Gross; +Cc: Jay Vosburgh, netdev, discuss@openvswitch.org
In-Reply-To: <CAEP_g=9gWZYtWGiF-JbVwmesa1n7FXYEJSQKdZi3L_yhPGPkAA@mail.gmail.com>
On Fri, Nov 7, 2014 at 2:29 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Fri, Nov 7, 2014 at 1:13 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>> Jesse Gross <jesse@nicira.com> wrote:
>>
>>>On Fri, Nov 7, 2014 at 10:34 AM, Jesse Gross <jesse@nicira.com> wrote:
>>>> On Fri, Nov 7, 2014 at 9:40 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>>>>> On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>> [...]
>>>>>> I'm not sure if this is an error on the part of the RX / GRO
>>>>>> processing in assembling the GRO skb, or in how OVS calls skb_segment.
>>>>>>
>>>>>
>>>>> I think this is related skb_segment() issue where it is not able to
>>>>> handle this type of skb geometry. We need to fix skb-segmentation. I
>>>>> will investigate it more.
>>>>
>>>> One problem that I see is that vxlan_gro_complete() doesn't add
>>>> SKB_GSO_UDP_TUNNEL to gso_type. This causes us to attempt
>>>> fragmentation as UDP rather than continuing down to do TCP
>>>> segmentation. That probably screws up the skb geometry.
>>>
>>>I sent out a patch to fix this issue. I'm pretty sure that it is the
>>>root cause of the originally reported case but I don't have a good way
>>>to reproduce it so it would be great if you could test it Jay.
>>
>> I'm having an issue there; when I set up my recreation on
>> current net-next (3.18-rc2) without your new patch, I get the following
>> oops when my ovs script does "ovs-vsctl --if-exists del-br br-ex":
>
> Hmm, that looks like a totally different problem. Pravin - any ideas?
I am not able to reproduce with above command. Jay, Can you send me
steps to reproduce this issue?
Thanks,
Pravin.
^ permalink raw reply
* Re: [PATCH net-next] net: introduce SO_INCOMING_CPU
From: Eric Dumazet @ 2014-11-07 23:26 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, netdev, Ying Cai, Willem de Bruijn, Neal Cardwell
In-Reply-To: <CA+mtBx9kpW8Q4HgTyNE+O4yPRmMcOgjshrBfZXVnPu=EMVh4Qg@mail.gmail.com>
On Fri, 2014-11-07 at 15:02 -0800, Tom Herbert wrote:
> Would it be better to get the incoming CPU before packet steering? Or
> maybe return this in addition to the CPU where ULP processes packet?
No packet steering : RFS is off.
If for some reason RPS is on (say NIC has a limited number of RX queues)
we'd like to have the cpu processing the packet in TCP stack for better
affinities.
^ permalink raw reply
* [PATCH net] cxgb4 : Fix bug in DCB app deletion
From: Anish Bhatt @ 2014-11-07 23:41 UTC (permalink / raw)
To: netdev; +Cc: davem, hariprasad, leedom, Anish Bhatt
Unlike CEE, IEEE has a bespoke app delete call and does not rely on priority
for app deletion
Fixes : 2376c879b80c ('cxgb4 : Improve handling of DCB negotiation or loss
thereof')
Signed-off-by: Anish Bhatt <anish@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
index 6fe300e..b6fdb14 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
@@ -79,8 +79,9 @@ static void cxgb4_dcb_cleanup_apps(struct net_device *dev)
app.protocol = dcb->app_priority[i].protocolid;
if (dcb->dcb_version == FW_PORT_DCB_VER_IEEE) {
+ app.priority = dcb->app_priority[i].user_prio_map;
app.selector = dcb->app_priority[i].sel_field + 1;
- err = dcb_ieee_setapp(dev, &app);
+ err = dcb_ieee_delapp(dev, &app);
} else {
app.selector = !!(dcb->app_priority[i].sel_field);
err = dcb_setapp(dev, &app);
--
2.1.3
^ permalink raw reply related
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-07 23:42 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, linux-kernel, bcrl
In-Reply-To: <20141107221114.GB7996@ZenIV.linux.org.uk>
On Fri, Nov 07, 2014 at 10:11:14PM +0000, Al Viro wrote:
> I'm looking through the tree right now; so far it looks like we can just
> move those suckers to the point where we validate iovec and lose them
> from low-level iovec and csum copying completely. I still haven't finished
> tracing all possible paths for address to arrive at the points where we
> currently check that stuff, but so far it looks very doable.
Definitely doable. The only remaining interesting part is drivers/vhost
with the stuff it puts in vq->iov[]. If we can guarantee that it satisfies
the sanity checks (access_ok() and size-related ones), we are done -
making verify_iovec() use rw_copy_check_uvector() (and verify_compat_iov()
use compat_rw_copy_check_uvector()) will suffice to guarantee that none of
csum_partial_copy_fromiovecend
memcpy_fromiovec
memcpy_toiovec
memcpy_toiovecend
memcpy_fromiovecend
skb_copy_datagram_iovec
skb_copy_datagram_iter
skb_copy_datagram_from_iter
zerocopy_sg_from_iter
skb_copy_and_csum_datagram
skb_copy_and_csum_datagram_iovec
csum_and_copy_from_user
csum_and_copy_to_user
csum_partial_copy_from_user
will ever see an address that doesn't satisfy access_ok() checks. And
having looked at the data flow... we definitely want to do those checks
on intake of iovec - as it is, we usually repeat them quite a few times
for the same iovec segment, and we practically never end up _not_ doing them
for some segment of iovec, unless we hit a failure exit before we get around
to copying any data at all.
I'll finish RTFS drivers/vhost and if it turns out to be OK I'll post the
series moving those checks to the moment of copying iovec from userland,
so that kernel-side we could always rely on ->msg_iov elements having been
verified.
^ permalink raw reply
* Re: [PATCH net 3/5] fm10k: Implement ndo_gso_check()
From: Vick, Matthew @ 2014-11-08 0:51 UTC (permalink / raw)
To: Joe Stringer
Cc: alexander.duyck@gmail.com, netdev@vger.kernel.org,
Dept-GELinuxNICDev@qlogic.com, linux-kernel@vger.kernel.org,
sathya.perla@emulex.com, Kirsher, Jeffrey T, Linux NICS,
amirv@mellanox.com, shahed.shaikh@qlogic.com, therbert@google.com,
Or Gerlitz
In-Reply-To: <201411071435.56628.joestringer@nicira.com>
On 11/7/14, 2:35 PM, "Joe Stringer" <joestringer@nicira.com> wrote:
>Sure, I think fm10k_tx_encap_offload() is a good place for the header
>length
>check. Separately, my question above was regarding the idea of a helper
>for
>SKB_GSO_{GRE,UDP_TUNNEL}. The only reason it might be useful for the
>fm10k
>driver is because all encap is checked in the fm10k_tx_encap_offload()
>function.
>Other drivers don't seem to handle different tunnels together like this
>though,
>so I'm inclined to stick with the below for now.
>
>
>static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
>
>{
>
> return (!(skb_shinfo(skb)->gso_type &
>
> (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE)) ||
>
> fm10k_tx_encap_offload(skb));
>
>}
>
>Cheers,
>Joe
I agree. I think that makes the most sense.
Cheers,
Matthew
^ permalink raw reply
* Re: [PATCH net] udptunnel: Add SKB_GSO_UDP_TUNNEL during gro_complete.
From: Jay Vosburgh @ 2014-11-08 1:51 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev
In-Reply-To: <1415391969-108511-1-git-send-email-jesse@nicira.com>
Jesse Gross <jesse@nicira.com> wrote:
>When doing GRO processing for UDP tunnels, we never add
>SKB_GSO_UDP_TUNNEL to gso_type - only the type of the inner protocol
>is added (such as SKB_GSO_TCPV4). The result is that if the packet is
>later resegmented we will do GSO but not treat it as a tunnel. This
>results in UDP fragmentation and since that is not the original layout
>of the skb, a panic in skb_segment().
>
>Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
>Signed-off-by: Jesse Gross <jesse@nicira.com>
>---
>This problem occurs back to 3.14 for VXLAN but the FOU portion needs to
>be removed for kernels other than the 'net' tree.
This patch does not resolve the problem when applied to a
3.17-ish kernel; the panic message is below, and appears to be
unchanged.
-J
[ 146.960891] kernel BUG at net/core/skbuff.c:3011!
[ 146.960891] invalid opcode: 0000 [#1] SMP
[ 146.960891] Modules linked in: veth 8021q garp mrp bonding xt_tcpudp bridge s
tp llc iptable_filter ip_tables x_tables openvswitch vxlan udp_tunnel gre libcrc
32c i915 video drm_kms_helper coretemp kvm_intel drm kvm gpio_ich serio_raw i2c_
algo_bit ppdev lpc_ich parport_pc lp parport mac_hid hid_generic usbhid hid psmo
use r8169 mii sky2
[ 146.960891] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc7 #11
[ 146.960891] Hardware name: LENOVO 0829F3U/To be filled by O.E.M., BIOS 90KT15
AUS 07/21/2010
[ 146.960891] task: ffffffff81c1d480 ti: ffffffff81c00000 task.ti: ffffffff81c0
0000
[ 146.960891] RIP: 0010:[<ffffffff816117d2>] [<ffffffff816117d2>] skb_segment+
0x962/0x990
[ 146.960891] RSP: 0018:ffff88013fc03908 EFLAGS: 00010216
[ 146.960891] RAX: 00000000000002dc RBX: ffff8800a62f0a00 RCX: ffff88003215e4f0
[ 146.960891] RDX: 0000000000000074 RSI: ffff88003215e400 RDI: ffff88003215f800
[ 146.960891] RBP: ffff88013fc039d0 R08: 0000000000000022 R09: 0000000000000000
[ 146.960891] R10: ffff8800a62f0b00 R11: 00000000000005ca R12: ffff88003215f8f0
[ 146.960891] R13: 0000000000000000 R14: ffff8800320e4100 R15: 0000000000000074
[ 146.960891] FS: 0000000000000000(0000) GS:ffff88013fc00000(0000) knlGS:00000
00000000000
[ 146.960891] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 146.960891] CR2: 000000000218c818 CR3: 00000000b1e4e000 CR4: 00000000000407f0
[ 146.960891] Stack:
[ 146.960891] ffff8800320e4c00 ffffffffffffffde ffff8800000005ca 0000000000000
022
[ 146.960891] 0000000000000040 ffff8800a62f0b00 00000001000005a8 0000000000000
000
[ 146.960891] 0000000000000022 00000000000005a8 ffff8800a62f0a00 ffff88003215e
4f0
[ 146.960891] Call Trace:
[ 146.960891] <IRQ>
[ 146.960891] [<ffffffff81686612>] udp4_ufo_fragment+0xc2/0x130
[ 146.960891] [<ffffffff8168f372>] inet_gso_segment+0x132/0x360
[ 146.960891] [<ffffffff8161fbe6>] ? dev_hard_start_xmit+0x316/0x5c0
[ 146.960891] [<ffffffff8161f5cb>] skb_mac_gso_segment+0x9b/0x170
[ 146.960891] [<ffffffff8161f700>] __skb_gso_segment+0x60/0xc0
[ 147.148004] [<ffffffffa01a7231>] queue_gso_packets+0x41/0x1b0 [openvswitch]
[ 147.148004] [<ffffffff81616ab3>] ? skb_flow_dissect+0x173/0x430
[ 147.148004] [<ffffffff81616d90>] ? __skb_get_hash+0x20/0x140
[ 147.148004] [<ffffffffa01a7c6e>] ovs_dp_upcall+0x2e/0x70 [openvswitch] [ 147.148004] [<ffffffffa01a7d9e>] ovs_dp_process_received_packet+0xee/0x110 [
openvswitch]
[ 147.148004] [<ffffffffa01adaea>] ovs_vport_receive+0x2a/0x30 [openvswitch]
[ 147.148004] [<ffffffffa01ae381>] netdev_frame_hook+0xc1/0x120 [openvswitch]
[ 147.148004] [<ffffffff8161daf2>] __netif_receive_skb_core+0x1b2/0x790
[ 147.148004] [<ffffffff8161e0e8>] __netif_receive_skb+0x18/0x60
[ 147.148004] [<ffffffff8161e153>] netif_receive_skb_internal+0x23/0x90
[ 147.148004] [<ffffffff81685e5b>] ? udp_gro_complete+0x5b/0x70
[ 147.148004] [<ffffffff8161e2d4>] napi_gro_complete+0xa4/0xe0
[ 147.148004] [<ffffffff8161e82f>] dev_gro_receive+0x1ef/0x2f0
[ 147.148004] [<ffffffff8161ec1c>] napi_gro_receive+0x2c/0xf0
[ 147.148004] [<ffffffffa001f28f>] sky2_poll+0x78f/0xd70 [sky2]
[ 147.148004] [<ffffffff8161e542>] net_rx_action+0x152/0x250
[ 147.148004] [<ffffffff81070925>] __do_softirq+0xf5/0x2e0
[ 147.148004] [<ffffffff81070de5>] irq_exit+0x105/0x110
[ 147.148004] [<ffffffff81724a78>] do_IRQ+0x58/0xf0
[ 147.148004] [<ffffffff817228ed>] common_interrupt+0x6d/0x6d
[ 147.148004] <EOI>
[ 147.148004] [<ffffffff810c9578>] ? rcu_nocb_kthread+0x158/0x510
[ 147.148004] [<ffffffff81055056>] ? native_safe_halt+0x6/0x10
[ 147.148004] [<ffffffff8101d1af>] default_idle+0x1f/0xc0
[ 147.148004] [<ffffffff8101db1f>] arch_cpu_idle+0xf/0x20
[ 147.148004] [<ffffffff810aadcd>] cpu_startup_entry+0x30d/0x340
[ 147.148004] [<ffffffff8170b307>] rest_init+0x77/0x80
[ 147.148004] [<ffffffff81d37084>] start_kernel+0x42f/0x43a
[ 147.148004] [<ffffffff81d36a4e>] ? set_init_arg+0x53/0x53
[ 147.148004] [<ffffffff81d36120>] ? early_idt_handlers+0x120/0x120
[ 147.148004] [<ffffffff81d365ee>] x86_64_start_reservations+0x2a/0x2c
[ 147.148004] [<ffffffff81d36733>] x86_64_start_kernel+0x143/0x152
[ 147.148004] Code: 24 70 4c 8b 54 24 58 44 8b 44 24 68 44 8b 4c 24 28 48 8b 4c
24 10 44 8b 5c 24 04 8b 14 24 0f 85 19 fd ff ff e9 10 fd ff ff 0f 0b <0f> 0b 0f
0b c6 44 24 33 01 e9 92 f7 ff ff e8 33 ad 10 00 0f 0b
[ 147.148004] RIP [<ffffffff816117d2>] skb_segment+0x962/0x990
[ 147.148004] RSP <ffff88013fc03908>
> drivers/net/vxlan.c | 2 ++
> include/net/udp_tunnel.h | 9 +++++++++
> net/ipv4/fou.c | 2 ++
> 3 files changed, 13 insertions(+)
>
>diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>index ca30982..cfb892b 100644
>--- a/drivers/net/vxlan.c
>+++ b/drivers/net/vxlan.c
>@@ -621,6 +621,8 @@ static int vxlan_gro_complete(struct sk_buff *skb, int nhoff)
> int vxlan_len = sizeof(struct vxlanhdr) + sizeof(struct ethhdr);
> int err = -ENOSYS;
>
>+ udp_tunnel_gro_complete(skb, nhoff);
>+
> eh = (struct ethhdr *)(skb->data + nhoff + sizeof(struct vxlanhdr));
> type = eh->h_proto;
>
>diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h
>index a47790b..2a50a70 100644
>--- a/include/net/udp_tunnel.h
>+++ b/include/net/udp_tunnel.h
>@@ -100,6 +100,15 @@ static inline struct sk_buff *udp_tunnel_handle_offloads(struct sk_buff *skb,
> return iptunnel_handle_offloads(skb, udp_csum, type);
> }
>
>+static inline void udp_tunnel_gro_complete(struct sk_buff *skb, int nhoff)
>+{
>+ struct udphdr *uh;
>+
>+ uh = (struct udphdr *)(skb->data + nhoff - sizeof(struct udphdr));
>+ skb_shinfo(skb)->gso_type |= uh->check ?
>+ SKB_GSO_UDP_TUNNEL_CSUM : SKB_GSO_UDP_TUNNEL;
>+}
>+
> static inline void udp_tunnel_encap_enable(struct socket *sock)
> {
> #if IS_ENABLED(CONFIG_IPV6)
>diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
>index 32e7892..606c520 100644
>--- a/net/ipv4/fou.c
>+++ b/net/ipv4/fou.c
>@@ -133,6 +133,8 @@ static int fou_gro_complete(struct sk_buff *skb, int nhoff)
> int err = -ENOSYS;
> const struct net_offload **offloads;
>
>+ udp_tunnel_gro_complete(skb, nhoff);
>+
> rcu_read_lock();
> offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads;
> ops = rcu_dereference(offloads[proto]);
>--
>1.9.1
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Herbert Xu @ 2014-11-08 2:21 UTC (permalink / raw)
To: Al Viro; +Cc: David Miller, netdev, linux-kernel, bcrl
In-Reply-To: <20141107234253.GE7996@ZenIV.linux.org.uk>
On Fri, Nov 07, 2014 at 11:42:53PM +0000, Al Viro wrote:
> I'll finish RTFS drivers/vhost and if it turns out to be OK I'll post the
> series moving those checks to the moment of copying iovec from userland,
> so that kernel-side we could always rely on ->msg_iov elements having been
> verified.
Great thanks!
Dave, please hold off on my skb_copy_datagram_iter series until
this verify_iovec change is added.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net] udptunnel: Add SKB_GSO_UDP_TUNNEL during gro_complete.
From: Jesse Gross @ 2014-11-08 3:54 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: David Miller, netdev
In-Reply-To: <28743.1415411491@famine>
On Fri, Nov 7, 2014 at 5:51 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
> Jesse Gross <jesse@nicira.com> wrote:
>
>>When doing GRO processing for UDP tunnels, we never add
>>SKB_GSO_UDP_TUNNEL to gso_type - only the type of the inner protocol
>>is added (such as SKB_GSO_TCPV4). The result is that if the packet is
>>later resegmented we will do GSO but not treat it as a tunnel. This
>>results in UDP fragmentation and since that is not the original layout
>>of the skb, a panic in skb_segment().
>>
>>Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
>>Signed-off-by: Jesse Gross <jesse@nicira.com>
>>---
>>This problem occurs back to 3.14 for VXLAN but the FOU portion needs to
>>be removed for kernels other than the 'net' tree.
>
> This patch does not resolve the problem when applied to a
> 3.17-ish kernel; the panic message is below, and appears to be
> unchanged.
Hmm, OK, thanks for testing. I think this patch is probably still good
to apply as it may solve a problem after we get this one figured out.
^ permalink raw reply
* Re: [ovs-discuss] kernel panic receiving flooded VXLAN traffic with OVS
From: Jay Vosburgh @ 2014-11-08 5:13 UTC (permalink / raw)
To: Pravin Shelar; +Cc: netdev, discuss-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
In-Reply-To: <CALnjE+q1t0dbC6-EvxsQvvNafKsk2HNKXBjDrALA9S-gon68PQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Pravin Shelar <pshelar@nicira.com> wrote:
>On Fri, Nov 7, 2014 at 2:29 PM, Jesse Gross <jesse@nicira.com> wrote:
>> On Fri, Nov 7, 2014 at 1:13 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>>> Jesse Gross <jesse@nicira.com> wrote:
>>>
>>>>On Fri, Nov 7, 2014 at 10:34 AM, Jesse Gross <jesse@nicira.com> wrote:
>>>>> On Fri, Nov 7, 2014 at 9:40 AM, Pravin Shelar <pshelar@nicira.com> wrote:
>>>>>> On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>>> [...]
>>>>>>> I'm not sure if this is an error on the part of the RX / GRO
>>>>>>> processing in assembling the GRO skb, or in how OVS calls skb_segment.
>>>>>>>
>>>>>>
>>>>>> I think this is related skb_segment() issue where it is not able to
>>>>>> handle this type of skb geometry. We need to fix skb-segmentation. I
>>>>>> will investigate it more.
>>>>>
>>>>> One problem that I see is that vxlan_gro_complete() doesn't add
>>>>> SKB_GSO_UDP_TUNNEL to gso_type. This causes us to attempt
>>>>> fragmentation as UDP rather than continuing down to do TCP
>>>>> segmentation. That probably screws up the skb geometry.
>>>>
>>>>I sent out a patch to fix this issue. I'm pretty sure that it is the
>>>>root cause of the originally reported case but I don't have a good way
>>>>to reproduce it so it would be great if you could test it Jay.
>>>
>>> I'm having an issue there; when I set up my recreation on
>>> current net-next (3.18-rc2) without your new patch, I get the following
>>> oops when my ovs script does "ovs-vsctl --if-exists del-br br-ex":
>>
>> Hmm, that looks like a totally different problem. Pravin - any ideas?
>
>I am not able to reproduce with above command. Jay, Can you send me
>steps to reproduce this issue?
Well, at the moment a 3.18.0-rc2 kernel panics in
ovs_flow_tbl_insert as soon as ovs-vswitchd starts up. Booting to an
earlier kernel (3.17, for example) with no other changes doesn't panic.
I moved /etc/openvswitch/conf.db away and rebooted the system
(which I think will eliminate the stored configuration), and the kernel
still hits this oops when ovs-vswitchd starts up.
A bit of poking with crash
[ 22.180002] RIP: 0010:[<ffffffffa01a55ec>] [<ffffffffa01a55ec>] ovs_flow_tbl_insert+0xdc/0x1f0 [openvswitch]
[ 22.180002] RSP: 0018:ffff8801391a77a8 EFLAGS: 00010203
[ 22.180002] RAX: 00000000076cc6f1 RBX: ffff8800b35c2020 RCX: 00000000fb994f19
[ 22.180002] RDX: 000000009cc907e5 RSI: 00000000a490ff19 RDI: ffff8800b0c1c19c
[ 22.180002] RBP: ffff8801391a77f8 R08: 000000006867223a R09: 00000000819d92a7
[ 22.180002] R10: ffffffffa01a5696 R11: 0000000000000004 R12: ffff8800b35c2028
[ 22.180002] R13: ffff8801391a7850 R14: ffff8800b35c2028 R15: ffff880134827800
[ 22.180002] FS: 00007f0ef491a980(0000) GS:ffff88013fc80000(0000) knlGS:0000000000000000
0xffffffffa01a55e7 <ovs_flow_tbl_insert+0xd7>: callq 0xffffffff813a75c0 <__jhash2>
0xffffffffa01a55ec <ovs_flow_tbl_insert+0xdc>: mov %eax,0x30(%r8)
0xffffffffa01a55f0 <ovs_flow_tbl_insert+0xe0>: mov (%rbx),%r13
0xffffffffa01a55f3 <ovs_flow_tbl_insert+0xe3>: mov %r8,%rsi
0xffffffffa01a55f6 <ovs_flow_tbl_insert+0xe6>: mov %r13,%rdi
0xffffffffa01a55f9 <ovs_flow_tbl_insert+0xe9>: callq 0xffffffffa01a4ba0 <table_instance_insert>
So it panics on return from __jhash2 because %r8 is invalid;
this is presumably
int ovs_flow_tbl_insert(struct flow_table *table, struct sw_flow *flow,
struct sw_flow_mask *mask)
{
[...]
flow->hash = flow_hash(&flow->key, flow->mask->range.start,
flow->mask->range.end);
ti = ovsl_dereference(table->ti);
table_instance_insert(ti, flow);
Looking at __jash2, it uses %r8 internally, but %r8 doesn't
appear to be saved and restored either around the call to, or within,
__jhash2. In ovs_flow_tbl_insert %r8 appears to hold the "flow"
variable, so this panic might have nothing to do with ovs itself.
I'll have to look at this further on Monday.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
^ permalink raw reply
* FROM Ms Faith Titi Attah
From: Ms Faith Titi Attah @ 2014-11-06 21:01 UTC (permalink / raw)
faithattah27@cantv.net
FROM Ms Faith Titi Attah
Dearest one
I wish you and your family happy moments of life
now and forever more amen.Please, I do not have formal relationship
with you but because of my present predicament and circumstances I am
made to contact you.I have been suffering from cancer of the Lungs and
has a short life to leave.I have made up my mind to donate my
inheritance of 21.5 million US to the less privileged please help me
to fulfill my last wish.please CONTACT ME TO MY EMAIL
faithattah27@cantv.net
Thanks CONTACT ME TO MY EMAIL faithattah27@cantv.net
Ms Faith Titi Attah
^ permalink raw reply
* Re: [PATCH] ipvs: Keep skb->sk when allocating headroom on tunnel xmit
From: Julian Anastasov @ 2014-11-08 6:16 UTC (permalink / raw)
To: Calvin Owens
Cc: Simon Horman, Wensong Zhang, lvs-devel, linux-kernel, netdev,
agartrell, kernel-team
In-Reply-To: <545D43BD.8030203@fb.com>
Hello,
On Fri, 7 Nov 2014, Calvin Owens wrote:
> On 11/05/2014 01:21 AM, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Tue, 4 Nov 2014, Calvin Owens wrote:
> >
> > > ip_vs_prepare_tunneled_skb() ignores ->sk when allocating a new
> > > skb, either unconditionally setting ->sk to NULL or allowing
> > > the uninitialized ->sk from a newly allocated skb to leak through
> > > to the caller.
> > >
> > > This patch properly copies ->sk and increments its reference count.
> > >
> > > Signed-off-by: Calvin Owens <calvinowens@fb.com>
> >
> > Good catch. Please, extend your patch to
> > fix also the second place that has such error,
> > ip_vs_tunnel_xmit_v6. This call is missing from long time,
> > it was not needed. But commits that allow skb->sk (local
> > clients) already need it, eg.
>
> I'm not sure where exactly you mean: ip_vs_tunnel_xmit_v6() calls
> ip_vs_prepare_tunneled_skb() to do the allocation, so this patch covers that
> case.
>
> In older versions of the kernel, ip_vs_tunnel_xmit_v6() does it directly,
> could that be what you're looking at?
Sorry, it seems I was checking old branch.
Simon, please apply.
Acked-by: Julian Anastasov <ja@ssi.bg>
> > - f2428ed5e7bc89c7 ("ipvs: load balance ipv6 connections from a local
> > process"), 2.6.28
> > - 4856c84c1358b798 ("ipvs: load balance IPv4 connections from a local
> > process"), 2.6.28
> >
> > > ---
> > > net/netfilter/ipvs/ip_vs_xmit.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/net/netfilter/ipvs/ip_vs_xmit.c
> > > b/net/netfilter/ipvs/ip_vs_xmit.c
> > > index 437a366..bd90bf8 100644
> > > --- a/net/netfilter/ipvs/ip_vs_xmit.c
> > > +++ b/net/netfilter/ipvs/ip_vs_xmit.c
> > > @@ -846,6 +846,8 @@ ip_vs_prepare_tunneled_skb(struct sk_buff *skb, int
> > > skb_af,
> > > new_skb = skb_realloc_headroom(skb, max_headroom);
> > > if (!new_skb)
> > > goto error;
> > > + if (skb->sk)
> > > + skb_set_owner_w(new_skb, skb->sk);
> > > consume_skb(skb);
> > > skb = new_skb;
> > > }
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH 1/2] 8139too: Allow setting MTU larger than 1500
From: Alban Bedel @ 2014-11-08 11:48 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Bjorn Helgaas, Benoit Taine, Eric W. Biederman,
David S. Miller, Alban Bedel
Replace the default ndo_change_mtu callback with one that allow
setting MTU that the driver can handle.
Signed-off-by: Alban Bedel <albeu@free.fr>
---
drivers/net/ethernet/realtek/8139too.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index 007b38c..8387de9 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -185,6 +185,9 @@ static int debug = -1;
/* max supported ethernet frame size -- must be at least (dev->mtu+14+4).*/
#define MAX_ETH_FRAME_SIZE 1536
+/* max supported payload size */
+#define MAX_ETH_DATA_SIZE (MAX_ETH_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)
+
/* Size of the Tx bounce buffers -- must be at least (dev->mtu+14+4). */
#define TX_BUF_SIZE MAX_ETH_FRAME_SIZE
#define TX_BUF_TOT_LEN (TX_BUF_SIZE * NUM_TX_DESC)
@@ -920,11 +923,19 @@ static int rtl8139_set_features(struct net_device *dev, netdev_features_t featur
return 0;
}
+static int rtl8139_change_mtu(struct net_device *dev, int new_mtu)
+{
+ if (new_mtu < 68 || new_mtu > MAX_ETH_DATA_SIZE)
+ return -EINVAL;
+ dev->mtu = new_mtu;
+ return 0;
+}
+
static const struct net_device_ops rtl8139_netdev_ops = {
.ndo_open = rtl8139_open,
.ndo_stop = rtl8139_close,
.ndo_get_stats64 = rtl8139_get_stats64,
- .ndo_change_mtu = eth_change_mtu,
+ .ndo_change_mtu = rtl8139_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = rtl8139_set_mac_address,
.ndo_start_xmit = rtl8139_start_xmit,
--
2.0.0
^ permalink raw reply related
* [PATCH 2/2] 8139too: Allow using the largest possible MTU
From: Alban Bedel @ 2014-11-08 11:48 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Bjorn Helgaas, Benoit Taine, Eric W. Biederman,
David S. Miller, Alban Bedel
In-Reply-To: <1415447316-12424-1-git-send-email-albeu@free.fr>
This driver allows MTU up to 1518 bytes which is not enought to run
batman-adv. Simply raise the maximum packet size up to the maximum
allowed by the transmit descriptor, 1792 bytes, giving a maximum MTU
of 1774 bytes.
Signed-off-by: Alban Bedel <albeu@free.fr>
---
drivers/net/ethernet/realtek/8139too.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index 8387de9..e157541 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -183,7 +183,7 @@ static int debug = -1;
#define NUM_TX_DESC 4
/* max supported ethernet frame size -- must be at least (dev->mtu+14+4).*/
-#define MAX_ETH_FRAME_SIZE 1536
+#define MAX_ETH_FRAME_SIZE 1792
/* max supported payload size */
#define MAX_ETH_DATA_SIZE (MAX_ETH_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)
--
2.0.0
^ permalink raw reply related
* alx can't send packet larger than 750 bytes
From: Konrad Mosoń @ 2014-11-08 16:06 UTC (permalink / raw)
To: netdev, nic-devel
Hello there,
I just submitted bug to bugzilla.redhat.com (not to mail kernel, cause i
didn't have problem on ArchLinux).
https://bugzilla.redhat.com/show_bug.cgi?id=1161861
Could be nice if you could look into it. It's kinda critical — network
just doesn't works.
Thanks for help,
Konrad Mosoń
PS
nic-devel@qca.qualcomm — sorry for doublemail but netdev@vger rejected
my mail at first time cause i used html.
^ permalink raw reply
* [PATCH] drivers: atm: eni: Add pci_dma_mapping_error() call
From: Tina Johnson @ 2014-11-08 16:18 UTC (permalink / raw)
To: chas; +Cc: linux-atm-general, netdev, linux-kernel, julia.lawall,
Tina Johnson
Added a pci_dma_mapping_error() call to check for mapping errors before
further using the dma handle. Unchecked dma handles were found using
Coccinelle:
@rule1@
expression e1;
identifier x;
@@
*x = pci_map_single(...);
... when != pci_dma_mapping_error(e1,x)
Signed-off-by: Tina Johnson <tinajohnson.1234@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
drivers/atm/eni.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c
index d65975a..6450a36 100644
--- a/drivers/atm/eni.c
+++ b/drivers/atm/eni.c
@@ -356,6 +356,8 @@ static int do_rx_dma(struct atm_vcc *vcc,struct sk_buff *skb,
if (skb) {
paddr = pci_map_single(eni_dev->pci_dev,skb->data,skb->len,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(eni_dev->pci_dev, paddr))
+ goto trouble;
ENI_PRV_PADDR(skb) = paddr;
if (paddr & 3)
printk(KERN_CRIT DEV_LABEL "(itf %d): VCI %d has "
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net-next] PPC: bpf_jit_comp: add SKF_AD_HATYPE instruction
From: Alexei Starovoitov @ 2014-11-08 17:59 UTC (permalink / raw)
To: Denis Kirjanov
Cc: netdev@vger.kernel.org, linuxppc-dev, Daniel Borkmann,
Philippe Bergheaud
In-Reply-To: <1415253755-4001-1-git-send-email-kda@linux-powerpc.org>
On Wed, Nov 5, 2014 at 10:02 PM, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> Add BPF extension SKF_AD_HATYPE to ppc JIT to check
> the hw type of the interface
>
> JIT off:
> [ 69.106783] test_bpf: #20 LD_HATYPE 48 48 PASS
> JIT on:
> [ 64.721757] test_bpf: #20 LD_HATYPE 7 6 PASS
>
> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
> CC: Daniel Borkmann<dborkman@redhat.com>
> CC: Philippe Bergheaud<felix@linux.vnet.ibm.com>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> ---
> arch/powerpc/net/bpf_jit_comp.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index d110e28..8bf4fc2 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -412,6 +412,22 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
> PPC_ANDI(r_A, r_A, PKT_TYPE_MAX);
> PPC_SRWI(r_A, r_A, 5);
> break;
> + case BPF_ANC | SKF_AD_HATYPE:
> + BUILD_BUG_ON(FIELD_SIZEOF(struct net_device, type) != 2);
> + PPC_LD_OFFS(r_scratch1, r_skb, offsetof(struct sk_buff,
> + dev));
> + PPC_CMPDI(r_scratch1, 0);
> + if (ctx->pc_ret0 != -1) {
> + PPC_BCC(COND_EQ, addrs[ctx->pc_ret0]);
> + } else {
> + /* Exit, returning 0; first pass hits here. */
> + PPC_BCC_SHORT(COND_NE, (ctx->idx*4)+12);
please use canonical formatting ctx->idx * 4 + 12
> + PPC_LI(r_ret, 0);
> + PPC_JMP(exit_addr);
> + }
> + PPC_LHZ_OFFS(r_A, r_scratch1,
> + offsetof(struct net_device, type));
the whole thing looks like copy paste from 'case ifindex'.
Would be nice to handle them together to reduce
duplicated code, sine only last load is different.
Also in commit log please do _both_ runs with JIT on.
You should see a difference before/after applying this patch.
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] r8152: clear theflagofSCHEDULE_TASKLETin tasklet
From: Francois Romieu @ 2014-11-08 22:11 UTC (permalink / raw)
To: Hayes Wang
Cc: David Miller, netdev@vger.kernel.org, nic_swsd,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2ECDFC2@RTITMBSV03.realtek.com.tw>
Hayes Wang <hayeswang@realtek.com> :
> Francois Romieu [mailto:romieu@fr.zoreil.com]
> > Sent: Monday, November 03, 2014 6:53 AM
> [...]
> > test_and_clear_bit (dense) or clear_bit would be more idiomatic.
>
> Excuse me. Any suggestion?
> Should I use clear_bit directly, or something else?
> Or, do I have to remove this patch?
The performance explanation leaves me a bit unconvinced. Without any
figure one could simply go for the always locked clear_bit because of:
1. the "I'm racy" message that the open-coded test + set sends
2. the extra work needed to avoid 1 (comment, explain, ...).
The extra time could thus be used to see what happens when napi is
shoehorned in this tasklet machinery. I'd naively expect it to be
relevant for efficiency.
I won't mind if your agenda is completely different. :o)
--
Ueimor
^ permalink raw reply
* e100: Laptop battery drain and WoL settings from EEPROM
From: Ondrej Zary @ 2014-11-08 23:15 UTC (permalink / raw)
To: e1000-devel; +Cc: netdev, Kernel development list
Hello,
there is long-standing problem with battery drain after turning off at least
some Toshiba laptops, see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110784
I have the same problem with Toshiba Portege R100. When I shut it down in
Linux, the battery is drained to zero in a couple of days. I noticed that the
LAN port is still active, even when AC disconnected.
The WoL is enabled by default by e100 driver:
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: No
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
By this code:
/* Wol magic packet can be enabled from eeprom */
if ((nic->mac >= mac_82558_D101_A4) &&
(nic->eeprom[eeprom_id] & eeprom_id_wol)) {
nic->flags |= wol_magic;
device_set_wakeup_enable(&pdev->dev, true);
}
because the WoL bit is set in EEPROM ID word:
# ethtool -e eth0
Offset Values
------ ------
0x0000: xx xx xx xx xx xx 03 1b 00 00 01 02 01 47 00 00
0x0010: 00 00 00 00 a2 49 01 00 79 11 7f 00 00 00 00 00
^^ bit 5 here
0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0040: 00 00 00 00 00 00 3d 10 00 00 00 00 00 00 00 00
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060: e4 00 3f 40 09 41 00 00 00 00 00 00 00 00 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f7 fe
Looks like this laptop is probably WoL-capable even on battery.
Measured the current from AC adapter:
around 20mA with WoL inactive (shut down from Windows or by power button in GRUB)
around 40mA with WoL active (shut down from Linux)
So to work-around this problem, users must disable WoL manually on each boot.
Maybe the driver should ignore the EEPROM WoL bit on Toshiba susbsystem IDs?
Or completely, like Windows driver does?
Ethernet controller details:
02:08.0 Ethernet controller [0200]: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller [8086:103d] (rev 83)
Subsystem: Toshiba America Info Systems Device [1179:0001]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at dfdff000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at cf40 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: e100
--
Ondrej Zary
^ permalink raw reply
* [PATCH 0/3 net-next] sunvnet: edge-case/race-conditions bug fixes
From: Sowmini Varadhan @ 2014-11-09 1:41 UTC (permalink / raw)
To: davem, sowmini.varadhan; +Cc: netdev, david.stevens
This patch series contains fixes for race-conditions in sunvnet,
that can encountered when there is a difference in latency between
producer and consumer.
Patch 1 addresses a case when the STOPPED LDC ack from a peer is
processed before vnet_start_xmit can finish updating the dr->prod
state.
Patch 2 fixes the edge-case when outgoing data and incoming
stopped-ack cross each other in flight.
Patch 3 adds a missing rcu_read_unlock(), found by code-inspection.
Sowmini Varadhan (3):
Fix race between vnet_start_xmit() and vnet_ack()
vnet_ack() should check if !start_cons to send a missed trigger
Add missing rcu_read_unlock() in vnet_start_xmit
drivers/net/ethernet/sun/sunvnet.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--
1.8.4.2
^ permalink raw reply
* [PATCH 1/3 net-next] sunvnet: Fix race between vnet_start_xmit() and vnet_ack()
From: Sowmini Varadhan @ 2014-11-09 1:41 UTC (permalink / raw)
To: davem, sowmini.varadhan; +Cc: netdev, david.stevens
When vnet_start_xmit() is concurrent with vnet_ack(), we may
have a race that looks like:
thread 1 thread 2
vnet_start_xmit vnet_event_napi -> vnet_rx
__vnet_tx_trigger for some desc X
at this point dr->prod == X
peer sends back a stopped ack for X
we process X, but X == dr->prod
so we bail out in vnet_ack with
!idx_is_pending
update dr->prod
As a result of the fact that we never processed the stopped ack for X,
the Tx path is led to incorrectly believe that the peer is still
"started" and reading, but the peer has stopped reading, which will
ultimately end in flow-control assertions.
The fix is to synchronize the above 2 paths on the netif_tx_lock.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
drivers/net/ethernet/sun/sunvnet.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
index 5c5fb59..deb395a 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -559,15 +559,17 @@ static int vnet_ack(struct vnet_port *port, void *msgbuf)
return 0;
end = pkt->end_idx;
- if (unlikely(!idx_is_pending(dr, end)))
- return 0;
-
vp = port->vp;
dev = vp->dev;
+ netif_tx_lock(dev);
+ if (unlikely(!idx_is_pending(dr, end))) {
+ netif_tx_unlock(dev);
+ return 0;
+ }
+
/* sync for race conditions with vnet_start_xmit() and tell xmit it
* is time to send a trigger.
*/
- netif_tx_lock(dev);
dr->cons = next_idx(end, dr);
desc = vio_dring_entry(dr, dr->cons);
if (desc->hdr.state == VIO_DESC_READY && port->start_cons) {
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH net-next] dccp: Convert DCCP_WARN to net_warn_ratelimited
From: David Miller @ 2014-11-09 1:42 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel, gerrit
In-Reply-To: <1415307221.21526.0.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 06 Nov 2014 12:53:41 -0800
> Remove the dependency on the "warning" sysctl (net_msg_warn)
> which is only used by the LIMIT_NETDEBUG macro.
>
> Convert the LIMIT_NETDEBUG use in DCCP_WARN to the more
> common net_warn_ratelimited mechanism.
>
> This still ratelimits based on the net_ratelimit()
> function, but removes the check for the sysctl.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
> What about the LIMIT_NETDEBUG stuff now?
>
> Maybe all of them might as well be net_dbg_ratelimited
> even if it changes some of the logging levels.
I think a straight conversion to net_dbg_ratelimited would
be fine.
^ permalink raw reply
* [PATCH 2/3 net-next] sunvnet: vnet_ack() should check if !start_cons to send a missed trigger
From: Sowmini Varadhan @ 2014-11-09 1:42 UTC (permalink / raw)
To: davem, sowmini.varadhan; +Cc: netdev, david.stevens
As per comments in vnet_start_xmit, for the edge case
when outgoing vnet_start_xmit() data and an incoming STOPPED
ACK cross each other in flight, we may need to send the missed
START trigger from maybe_tx_wakeup() after checking for a
false value of start_cons
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
drivers/net/ethernet/sun/sunvnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
index deb395a..826b385 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -572,7 +572,7 @@ static int vnet_ack(struct vnet_port *port, void *msgbuf)
*/
dr->cons = next_idx(end, dr);
desc = vio_dring_entry(dr, dr->cons);
- if (desc->hdr.state == VIO_DESC_READY && port->start_cons) {
+ if (desc->hdr.state == VIO_DESC_READY && !port->start_cons) {
/* vnet_start_xmit() just populated this dring but missed
* sending the "start" LDC message to the consumer.
* Send a "start" trigger on its behalf.
--
1.8.4.2
^ permalink raw reply related
* [PATCH 3/3 net-next] sunvnet: Add missing rcu_read_unlock() in vnet_start_xmit
From: Sowmini Varadhan @ 2014-11-09 1:42 UTC (permalink / raw)
To: davem, sowmini.varadhan; +Cc: netdev, david.stevens
The out_dropped label will only do rcu_read_unlock for non-null port.
So add the missing rcu_read_unlock() when bailing due to non-null port.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
---
drivers/net/ethernet/sun/sunvnet.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
index 826b385..55d66c9 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -981,8 +981,10 @@ static int vnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
rcu_read_lock();
port = __tx_port_find(vp, skb);
- if (unlikely(!port))
+ if (unlikely(!port)) {
+ rcu_read_unlock();
goto out_dropped;
+ }
if (skb->len > port->rmtu) {
unsigned long localmtu = port->rmtu - ETH_HLEN;
--
1.8.4.2
^ permalink raw reply related
* [PATCH V1 net-next] net/fm10k: Avoid double setting of NETIF_F_SG for the HW encapsulation feature mask
From: Or Gerlitz @ 2014-11-09 8:13 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev, Or Gerlitz
The networking core does it for the driver during registration time.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
changes from v0:
- set alignment to be per the request of Matthew Vick
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
index 8811364..14882dc 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
@@ -1414,13 +1414,12 @@ struct net_device *fm10k_alloc_netdev(void)
dev->vlan_features |= dev->features;
/* configure tunnel offloads */
- dev->hw_enc_features = NETIF_F_IP_CSUM |
- NETIF_F_TSO |
- NETIF_F_TSO6 |
- NETIF_F_TSO_ECN |
- NETIF_F_GSO_UDP_TUNNEL |
- NETIF_F_IPV6_CSUM |
- NETIF_F_SG;
+ dev->hw_enc_features |= NETIF_F_IP_CSUM |
+ NETIF_F_TSO |
+ NETIF_F_TSO6 |
+ NETIF_F_TSO_ECN |
+ NETIF_F_GSO_UDP_TUNNEL |
+ NETIF_F_IPV6_CSUM;
/* we want to leave these both on as we cannot disable VLAN tag
* insertion or stripping on the hardware since it is contained
--
1.7.1
^ permalink raw reply related
* Re: [PATCH V2 net-next 2/2] net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE
From: Amir Vadai @ 2014-11-09 8:14 UTC (permalink / raw)
To: Or Gerlitz, David S. Miller
Cc: netdev, Matan Barak, Saeed Mahameed, Shani Michaeli, Ido Shamay,
Jerry Chu
In-Reply-To: <1415291324-22069-3-git-send-email-ogerlitz@mellanox.com>
On 11/6/2014 6:28 PM, Or Gerlitz wrote:
> From: Shani Michaeli <shanim@mellanox.com>
>
> When processing received traffic, pass CHECKSUM_COMPLETE status to the
> stack, with calculated checksum for non TCP/UDP packets (such
> as GRE or ICMP).
>
> Although the stack expects checksum which doesn't include the pseudo
> header, the HW adds it. To address that, we are subtracting the pseudo
> header checksum from the checksum value provided by the HW.
>
> In the IPv6 case, we also compute/add the IP header checksum which
> is not added by the HW for such packets.
>
> Cc: Jerry Chu <hkchu@google.com>
> Signed-off-by: Shani Michaeli <shanim@mellanox.com>
> Signed-off-by: Matan Barak <matanb@mellanox.com>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 +
> drivers/net/ethernet/mellanox/mlx4/en_port.c | 2 +
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 127 +++++++++++++++++++++--
> drivers/net/ethernet/mellanox/mlx4/main.c | 9 ++
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 5 +-
> include/linux/mlx4/device.h | 1 +
> 7 files changed, 142 insertions(+), 9 deletions(-)
>
[...]
> @@ -702,8 +787,8 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> * and not performing the selftest or flb disabled
> */
> if (priv->flags & MLX4_EN_FLAG_RX_FILTER_NEEDED) {
> - struct ethhdr *ethh;
> dma_addr_t dma;
> + struct ethhdr *ethh;
> /* Get pointer to first fragment since we haven't
> * skb yet and cast it to ethhdr struct
> */
This hunk is not needed
> @@ -744,13 +829,26 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> (cqe->vlan_my_qpn & cpu_to_be32(MLX4_CQE_L2_TUNNEL));
[...]
Amir
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox