Re: [PATCH 1/1] bonding: restrict up state in 802.3ad mode

[Michal Kubecek]

On Thu, Jan 07, 2016 at 03:37:26PM +0800, zhuyj wrote:
> >If I read this right, whenever this state (link up but speed/duplex
> >unknown) is entered, you'll keep writing this message into kernel log
> >every miimon milliseconds until something changes. I'm not sure how long
> >a NIC can stay in such state but it might get quite annoying (even more
> >if something really goes wrong and NIC stays that way which can't be
> >completely ruled out, IMHO).
> 
> Sure, Thanks a lot. I want to confirm link_up without link_speed. It
> is not usual. So I think this only lasts for several seconds.
> It is very important to us since it can help us to find the root cause.

For debugging purposes it's fine, of course. But this looked like an
officially submitted patch so I didn't like the idea of log spamming
(even one second could result in 10-100 messages and admins certainly
would hate that).

   Michal Kubecek

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG 4.4-rc4]: oops around sock_recvmsg

[Russell King - ARM Linux]

On Thu, Jan 07, 2016 at 09:58:14AM +0100, Holger Schurig wrote:
> This oops with sock_recvmsg() inside it now happened 3 times, just not
> at my test box, only at one very remote from me. That's also the reason
> why the log is truncated, the people that grabbed it from Windows with
> Putty over the serial line just did give this to me ... :-(

It's a little incomplete, but luckily we have some useful information
buried in it.

> BTW, are several places with "???" below. Is this just a "grabbing from
> Windows" artifact? Or an indication that the processor/memory of the
> system got completely insane?

No idea, sorry.

...
> [] (do_page_fault) from [] (do_PrefetchAbort+0x3c/0xa0)
> r10:c0037790 r9:0001 r8:0001 r7:ed9a9bf8 r6:fffe r5:c055fbc4
> r4:0007
> [] (do_PrefetchAbort) from [] (__pabt_svc+0x4c/0x80)
> Exception stack(0xed9a9bf8 to 0xed9a9c40)
> 9be0:?? ebaa3d18 0001
> 9c00: 0001 0304 ee1c2c04 fff3 0001 0304 0001 0001
> 9c20: c0037790 ed9a9c74  ed9a9c48 c004febc fffe 800100b3 

These are the registers - r0 to pc, cpsr and "orig_r0".  The PC value
triggering the prefetch abort was 0xfffe, and the link register
was 0xc004febc - this should be the instruction after the call.

To do any diagnosis, I'd need the disassembly around the link
register - it may be best if you can send me the vmlinux file itself
by private mail in case I need to reference other functions too.

I've left the remainder of the trace in place - please retain it when
you reply with the disassembly so I can refer directly to it in my
next reply without having to find the previous email.  Thanks.

> r7:ed9a9c2c r6: r5:800100b3 r4:fffe
> [] (__wake_up_common) from [] 
> (__wake_up_sync_key+0x4c/0x60)
> r10: r9:0010 r8:0304 r7:0001 r6:0001 r5:a0010013
> r4:ee1c2c00 r3:0001
> [] (__wake_up_sync_key) from [] 
> (unix_write_space+0x60/0x90)
> r8:ed9a9df4 r7:eb9decc0 r6:ed95d5e4 r5:ed95f02c r4:ed95ef80
> [] (unix_write_space) from [] (sock_wfree+0x4c/0x84)
> r4:ed95ef80 r3:c03cf970
> [] (sock_wfree) from [] (unix_destruct_scm+0x6c/0x74)
> r5: r4:eb9decc0
> [] (unix_destruct_scm) from [] 
> (skb_release_head_state+0x70/0xb0)
> r4:eb9decc0
> [] (skb_release_head_state) from [] 
> (skb_release_all+0x14/0x2c)
> r4:eb9decc0 r3:0001
> [] (skb_release_all) from [] (__kfree_skb+0x14/0x94)
> r4:eb9decc0 r3:0001
> [] (__kfree_skb) from [] (consume_skb+0x58/0x5c)
> r4:ed95d400 r3:0001
> [] (consume_skb) from [] 
> (unix_stream_read_generic+0x5ec/0x750)
> [] (unix_stream_read_generic) from [] 
> (unix_stream_recvmsg+0x50/0x5c)
> r10:ecc13800 r9:ed9a9e88 r8:bee12988 r7:0040 r6:ecc13800 r5:ed9a9f4c
> r4:1000
> [] (unix_stream_recvmsg) from [] (sock_recvmsg+0x18/0x1c)
> r7:bee1296c r6:0040 r5: r4:ed9a9f4c
> [] (sock_recvmsg) from [] (___sys_recvmsg+0x98/0x170)
> [] (___sys_recvmsg) from [] (__sys_recvmsg+0x44/0x68)
> r10: r9:ed9a8000 r8:c000f1e4 r7:0129 r6:bee1296c r5:
> r4:ecc13800
> [] (__sys_recvmsg) from [] (SyS_recvmsg+0x10/0x14)
> r6:b6f7df10 r5:81196c08 r4:bee12988
> [] (SyS_recvmsg) from [] (ret_fast_syscall+0x0/0x3c)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 2/2] r8152: adjust ALDPS function

[Hayes Wang]

Replace disable_aldps() and enable_aldps() with aldps_en().

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 72 +++--
 1 file changed, 34 insertions(+), 38 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4f0bb67..230c73c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2452,23 +2452,23 @@ static void r8153_teredo_off(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TEREDO_TIMER, 0);
 }
 
-static void r8152b_disable_aldps(struct r8152 *tp)
+static void r8152_aldps_en(struct r8152 *tp, bool enable)
 {
-   ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPDNPS | LINKENA | DIS_SDSAVE);
-   msleep(20);
-}
-
-static inline void r8152b_enable_aldps(struct r8152 *tp)
-{
-   ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPWRSAVE | ENPDNPS |
-   LINKENA | DIS_SDSAVE);
+   if (enable) {
+   ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPWRSAVE | ENPDNPS |
+   LINKENA | DIS_SDSAVE);
+   } else {
+   ocp_reg_write(tp, OCP_ALDPS_CONFIG, ENPDNPS | LINKENA |
+   DIS_SDSAVE);
+   msleep(20);
+   }
 }
 
 static void rtl8152_disable(struct r8152 *tp)
 {
-   r8152b_disable_aldps(tp);
+   r8152_aldps_en(tp, false);
rtl_disable(tp);
-   r8152b_enable_aldps(tp);
+   r8152_aldps_en(tp, true);
 }
 
 static void r8152b_hw_phy_cfg(struct r8152 *tp)
@@ -2780,30 +2780,26 @@ static void r8153_enter_oob(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
 }
 
-static void r8153_disable_aldps(struct r8152 *tp)
+static void r8153_aldps_en(struct r8152 *tp, bool enable)
 {
u16 data;
 
data = ocp_reg_read(tp, OCP_POWER_CFG);
-   data &= ~EN_ALDPS;
-   ocp_reg_write(tp, OCP_POWER_CFG, data);
-   msleep(20);
-}
-
-static void r8153_enable_aldps(struct r8152 *tp)
-{
-   u16 data;
-
-   data = ocp_reg_read(tp, OCP_POWER_CFG);
-   data |= EN_ALDPS;
-   ocp_reg_write(tp, OCP_POWER_CFG, data);
+   if (enable) {
+   data |= EN_ALDPS;
+   ocp_reg_write(tp, OCP_POWER_CFG, data);
+   } else {
+   data &= ~EN_ALDPS;
+   ocp_reg_write(tp, OCP_POWER_CFG, data);
+   msleep(20);
+   }
 }
 
 static void rtl8153_disable(struct r8152 *tp)
 {
-   r8153_disable_aldps(tp);
+   r8153_aldps_en(tp, false);
rtl_disable(tp);
-   r8153_enable_aldps(tp);
+   r8153_aldps_en(tp, true);
usb_enable_lpm(tp->udev);
 }
 
@@ -2900,9 +2896,9 @@ static void rtl8152_up(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, >flags))
return;
 
-   r8152b_disable_aldps(tp);
+   r8152_aldps_en(tp, false);
r8152b_exit_oob(tp);
-   r8152b_enable_aldps(tp);
+   r8152_aldps_en(tp, true);
 }
 
 static void rtl8152_down(struct r8152 *tp)
@@ -2913,9 +2909,9 @@ static void rtl8152_down(struct r8152 *tp)
}
 
r8152_power_cut_en(tp, false);
-   r8152b_disable_aldps(tp);
+   r8152_aldps_en(tp, false);
r8152b_enter_oob(tp);
-   r8152b_enable_aldps(tp);
+   r8152_aldps_en(tp, true);
 }
 
 static void rtl8153_up(struct r8152 *tp)
@@ -2924,9 +2920,9 @@ static void rtl8153_up(struct r8152 *tp)
return;
 
r8153_u1u2en(tp, false);
-   r8153_disable_aldps(tp);
+   r8153_aldps_en(tp, false);
r8153_first_init(tp);
-   r8153_enable_aldps(tp);
+   r8153_aldps_en(tp, true);
r8153_u2p3en(tp, true);
r8153_u1u2en(tp, true);
usb_enable_lpm(tp->udev);
@@ -2942,9 +2938,9 @@ static void rtl8153_down(struct r8152 *tp)
r8153_u1u2en(tp, false);
r8153_u2p3en(tp, false);
r8153_power_cut_en(tp, false);
-   r8153_disable_aldps(tp);
+   r8153_aldps_en(tp, false);
r8153_enter_oob(tp);
-   r8153_enable_aldps(tp);
+   r8153_aldps_en(tp, true);
 }
 
 static bool rtl8152_in_nway(struct r8152 *tp)
@@ -3230,7 +3226,7 @@ static void r8152b_init(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, >flags))
return;
 
-   r8152b_disable_aldps(tp);
+   r8152_aldps_en(tp, false);
 
if (tp->version == RTL_VER_01) {
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_LED_FEATURE);
@@ -3252,7 +3248,7 @@ static void r8152b_init(struct r8152 *tp)
ocp_write_word(tp, MCU_TYPE_PLA, PLA_GPHY_INTR_IMR, ocp_data);
 
r8152b_enable_eee(tp);
-   r8152b_enable_aldps(tp);
+   r8152_aldps_en(tp, true);
r8152b_enable_fc(tp);
rtl_tally_reset(tp);
 
@@ -3270,7 +3266,7 @@ static void r8153_init(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, >flags))
return;
 
-   r8153_disable_aldps(tp);
+   r8153_aldps_en(tp, false);

Re: [PATCH net 1/2] vxlan: Relax the MTU constraint on vxlan devices

[Thomas Graf]

On 01/06/16 at 01:33pm, David Wragg wrote:
> Allow the MTU of vxlan devices without an underlying device to be set to
> larger values (up to a maximum based on IP packet limits and vxlan
> overhead).
> 
> Previously, their MTUs could not be set to higher than the conventional
> ethernet value of 1500.  This is a very arbitrary value in the context
> of vxlan, and prevented such vxlan devices from being able to take
> advantage of jumbo frames etc.
> 
> The default MTU remains 1500, for compatibility.
> 
> Signed-off-by: David Wragg 

A remain of eth_change_mtu

> + int max_mtu = 65535;

This should probably be represented as a new const DEV_MAX_MTU which
can be used by veth, tun, and virtio as well instead of hardcoding
this separately in each driver.

> +static int vxlan_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + struct vxlan_dev *vxlan = netdev_priv(dev);
> + struct vxlan_rdst *dst = >default_dst;
> + struct net_device *lowerdev = __dev_get_by_index(vxlan->net,
> +  dst->remote_ifindex);
> + return __vxlan_change_mtu(dev, lowerdev, dst, new_mtu);

Any particular reason for the indirection?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

[Konstantin Khlebnikov]

On Thu, Jan 7, 2016 at 2:00 PM, Konstantin Khlebnikov  wrote:
> On Thu, Jan 7, 2016 at 2:49 AM, Florian Westphal  wrote:
>> Florian Westphal  wrote:
>>> Thadeu Lima de Souza Cascardo  wrote:
>>> > On Wed, Jan 06, 2016 at 11:11:41PM +0300, Konstantin Khlebnikov wrote:
>>
>> [ skb_gso_segment uses skb->cb[], causes oops if ip_fragment is invoked
>>   on segmented skbs ]
>>
>>> > I have hit this as well, this fixes it for me on an older kernel. Can you 
>>> > try it
>>> > on latest kernel?
>>>
>>> > diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
>>> > index d8a1745..f44bc91 100644
>>> > --- a/net/ipv4/ip_output.c
>>> > +++ b/net/ipv4/ip_output.c
>>> > @@ -216,6 +216,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)
>>> > netdev_features_t features;
>>> > struct sk_buff *segs;
>>> > int ret = 0;
>>> > +   struct inet_skb_parm ipcb;
>>> >
>>> > if (skb_gso_network_seglen(skb) <= ip_skb_dst_mtu(skb))
>>> > return ip_finish_output2(skb);
>>> > @@ -227,6 +228,10 @@ static int ip_finish_output_gso(struct sk_buff *skb)
>>> >  * 2) skb arrived via virtio-net, we thus get TSO/GSO skbs directly
>>> >  * from host network stack.
>>> >  */
>>> > +   /* We need to save IPCB here because skb_gso_segment will use
>>> > +* SKB_GSO_CB.
>>> > +*/
>>> > +   ipcb = *IPCB(skb);
>>> > features = netif_skb_features(skb);
>>> > segs = skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
>>> > if (IS_ERR_OR_NULL(segs)) {
>>> > @@ -241,6 +246,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)
>>> > int err;
>>> >
>>> > segs->next = NULL;
>>> > +   *IPCB(segs) = ipcb;
>>> > err = ip_fragment(segs, ip_finish_output2);
>>> >
>>> > if (err && ret == 0)
>>>
>>> I'm worried that this doesn't solve all cases. f.e. xfrm may also
>>> call skb_gso_segment(), and it will call into ipv4/ipv6 netfilter
>>> postrouting + ipv4 output functions...
>>>
>>> nfqnl_enqueue_packet() is also affected.
>>
>> ... but it seems that those three are the only affected callers
>> of skb_gso_segment (tbf is ok since skb isn't owned by anyone,
>> ovs does save/restore already).
>>
>> I think this patch is the right way, we just need similar
>> save/restore in nfqnl_enqueue_packet and xfrm_output_gso().
>
> Which CB could be here? at this point skb isn't owned by netlink yet.
>
>>
>> The latter two can be used by either ipv4 or ipv6 so it might
>> be preferable to just save/restore sizeof(struct skb_gso_cb);
>> or a union of inet_skb_parm+inet6_skb_parm.
>
> Or just shift GSO CB and add couple checks like
> BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb)));

Somethin like this (in attachment)

Also I've found strange thing: reason of expanding skb->cb from 40 to
48 bypes in 2006
3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
not fit. But it's is only 24 bytes. Does some arches add pad after
each _u16 field?


net-preserve-lower-bytes-of-skb-cb-during-gso-segmentation
Description: Binary data

Re: [v2] mwifiex: correctly handling kzalloc

[Kalle Valo]

> Since kzalloc can be failed in memory pressure,
> it needs to be handled, otherwise NULL dereference could be happened
> 
> Signed-off-by: Insu Yun 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net] r8152: fix the wake event

[Hayes Wang]

When the autosuspend is enabled and occurs before system suspend, we should
wake the device before running system syspend. Then, we could change the wake
event for system suspend. Otherwise, the device would resume the system when
receiving any packet.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 40 +++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2fb637a..ef9aab6 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -25,12 +25,13 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Information for net-next */
 #define NETNEXT_VERSION"08"
 
 /* Information for net */
-#define NET_VERSION"2"
+#define NET_VERSION"3"
 
 #define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -604,6 +605,9 @@ struct r8152 {
struct delayed_work schedule;
struct mii_if_info mii;
struct mutex control;   /* use for hw setting */
+#ifdef CONFIG_PM_SLEEP
+   struct notifier_block pm_notifier;
+#endif
 
struct rtl_ops {
void (*init)(struct r8152 *);
@@ -3048,6 +3052,33 @@ out1:
usb_autopm_put_interface(tp->intf);
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int rtl_notifier(struct notifier_block *nb, unsigned long action,
+   void *data)
+{
+   struct r8152 *tp = container_of(nb, struct r8152, pm_notifier);
+
+   switch (action) {
+   case PM_HIBERNATION_PREPARE:
+   case PM_SUSPEND_PREPARE:
+   usb_autopm_get_interface(tp->intf);
+   break;
+
+   case PM_POST_HIBERNATION:
+   case PM_POST_SUSPEND:
+   usb_autopm_put_interface(tp->intf);
+   break;
+
+   case PM_POST_RESTORE:
+   case PM_RESTORE_PREPARE:
+   default:
+   break;
+   }
+
+   return NOTIFY_DONE;
+}
+#endif
+
 static int rtl8152_open(struct net_device *netdev)
 {
struct r8152 *tp = netdev_priv(netdev);
@@ -3090,6 +3121,10 @@ static int rtl8152_open(struct net_device *netdev)
mutex_unlock(>control);
 
usb_autopm_put_interface(tp->intf);
+#ifdef CONFIG_PM_SLEEP
+   tp->pm_notifier.notifier_call = rtl_notifier;
+   register_pm_notifier(>pm_notifier);
+#endif
 
 out:
return res;
@@ -3100,6 +3135,9 @@ static int rtl8152_close(struct net_device *netdev)
struct r8152 *tp = netdev_priv(netdev);
int res = 0;
 
+#ifdef CONFIG_PM_SLEEP
+   unregister_pm_notifier(>pm_notifier);
+#endif
napi_disable(>napi);
clear_bit(WORK_ENABLE, >flags);
usb_kill_urb(tp->intr_urb);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch net-next v2 1/2] mlxsw: spectrum: pass local_port to mlxsw_sp_port_fdb_uc_op

[Jiri Pirko]

From: Jiri Pirko 

Do not pass struct mlxsw_sp_port to mlxsw_sp_port_fdb_uc_op and rather
just pass local_port. This is needed in case this is called from SFN
process function and mlxsw_sp_port is not existent for particular
local_port.

Signed-off-by: Jiri Pirko 
Reviewed-by: Ido Schimmel 
---
v1->v2:
- no change
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c 
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 614ef57..5150e9e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -594,11 +594,10 @@ static enum mlxsw_reg_sfd_op mlxsw_sp_sfd_op(bool adding)
MLXSW_REG_SFD_OP_WRITE_REMOVE;
 }
 
-static int mlxsw_sp_port_fdb_uc_op(struct mlxsw_sp_port *mlxsw_sp_port,
+static int mlxsw_sp_port_fdb_uc_op(struct mlxsw_sp *mlxsw_sp, u8 local_port,
   const char *mac, u16 fid, bool adding,
   bool dynamic)
 {
-   struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
char *sfd_pl;
int err;
 
@@ -609,7 +608,7 @@ static int mlxsw_sp_port_fdb_uc_op(struct mlxsw_sp_port 
*mlxsw_sp_port,
mlxsw_reg_sfd_pack(sfd_pl, mlxsw_sp_sfd_op(adding), 0);
mlxsw_reg_sfd_uc_pack(sfd_pl, 0, mlxsw_sp_sfd_rec_policy(dynamic),
  mac, fid, MLXSW_REG_SFD_REC_ACTION_NOP,
- mlxsw_sp_port->local_port);
+ local_port);
err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(sfd), sfd_pl);
kfree(sfd_pl);
 
@@ -659,7 +658,8 @@ mlxsw_sp_port_fdb_static_add(struct mlxsw_sp_port 
*mlxsw_sp_port,
fid = mlxsw_sp_port->pvid;
 
if (!mlxsw_sp_port->lagged)
-   return mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port,
+   return mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port->mlxsw_sp,
+  mlxsw_sp_port->local_port,
   fdb->addr, fid, true, false);
else
return mlxsw_sp_port_fdb_uc_lag_op(mlxsw_sp_port->mlxsw_sp,
@@ -798,7 +798,8 @@ mlxsw_sp_port_fdb_static_del(struct mlxsw_sp_port 
*mlxsw_sp_port,
}
 
if (!mlxsw_sp_port->lagged)
-   return mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port,
+   return mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port->mlxsw_sp,
+  mlxsw_sp_port->local_port,
   fdb->addr, fid,
   false, false);
else
@@ -1056,7 +1057,7 @@ static void mlxsw_sp_fdb_notify_mac_process(struct 
mlxsw_sp *mlxsw_sp,
vid = fid;
}
 
-   err = mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port, mac, fid,
+   err = mlxsw_sp_port_fdb_uc_op(mlxsw_sp, local_port, mac, fid,
  adding && mlxsw_sp_port->learning, true);
if (err) {
if (net_ratelimit())
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] arm64: net: bpf: don't BUG() on large shifts

[David Laight]

From: Alexei Starovoitov
> Sent: 06 January 2016 22:13
> On Wed, Jan 06, 2016 at 09:31:27PM +0100, Rabin Vincent wrote:
> > On Tue, Jan 05, 2016 at 09:55:58AM -0800, Alexei Starovoitov wrote:
> > > this one is better to be addressed in verifier instead of eBPF JITs.
> > > Please reject it in check_alu_op() instead.
> >
> > AFAICS the eBPF verifier is not called on the eBPF filters generated by
> > the BPF->eBPF conversion in net/core/filter.c, so performing this check
> > only in check_alu_op() will be insufficient.  So I think we'd need to
> > add this check to bpf_check_classic() too.  Or am I missing something?
> 
> correct. the check is needed in bpf_check_classic() too and I believe
> it's ok to tighten it up in this case, since >32 shift is
> invalid/undefined anyway. We can either accept it as nop or K&=31
> or error. I think returning error is more user friendly long term, though
> there is a small risk of rejecting previously loadable broken programs.

Or replace with an assignment of zero?

David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net 2/2] vxlan: Set a large MTU on ovs-created vxlan devices

[Thomas Graf]

On 01/06/16 at 01:33pm, David Wragg wrote:
> Prior to 4.3, vxlan vports could transmit vxlan packets of any size,
> constrained only by the ability to transmit the resulting UDP packets.
> 4.3 introduced vxlan netdevs corresponding to vxlan vports.  These
> netdevs have an MTU, which limits the size of a packet that can be
> successfully vxlan-encapsulated.  The default value for this MTU is
> 1500, which is awkwardly small, and leads to a conspicuous change in
> behaviour for userspace.
> 
> This sets the MTU on openvswitch-created vxlan devices to be 65465
> (the maximum IP packet size minus the vxlan-on-IPv6 overhead),
> effectively restoring the behaviour prior to 4.3.  Although the
> vxlan_config struct already had a mtu field for this,
> vxlan_dev_configure mostly ignored it; that is also addressed here.

I agree with Jesse that this is fine. The tunnel net_device is a
logical device anyway and the real MTU is not known at this point
until the underlay route has been resolved.

It is really a model we should move away from though. Unless the
endpoints negotiate a proper MTU, the underlay can't possible
cope with this correctly without major performance problems due
to fragmentation.

> @@ -2810,6 +2809,12 @@ static int vxlan_dev_configure(struct net *src_net, 
> struct net_device *dev,
>   needed_headroom = lowerdev->hard_header_len;
>   }
>  
> + if (conf->mtu) {
> + err = __vxlan_change_mtu(dev, lowerdev, dst, conf->mtu);

OK, I see the reason for the indirection in the first patch. Never
mind.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] net, sched: add clsact qdisc

[Hannes Frederic Sowa]

Hi Daniel and Alexei,

On 07.01.2016 04:53, Alexei Starovoitov wrote:

On Wed, Jan 06, 2016 at 02:00:56AM +0100, Daniel Borkmann wrote:


I decided to extend the sch_ingress module with clsact functionality so
that commonly used code can be reused, the module is being aliased with
sch_clsact so that it can be auto-loaded properly. Alternative would have been
to add a flag when initializing ingress to alter its behaviour plus aliasing
to a different name (as it's more than just ingress). However, the first would
end up, based on the flag, choosing the new/old behaviour by calling different
function implementations to handle each anyway, the latter would require to
register ingress qdisc once again under different alias. So, this really begs
to provide a minimal, cleaner approach to have Qdisc_ops and Qdisc_class_ops
by its own that share callbacks used by both.

...

Signed-off-by: Daniel Borkmann 


we've been going back and forth on the design and this final approach
presented seems to be the best, since pros outweigh the cons.

Acked-by: Alexei Starovoitov 


One question:

With the advance in lockless qdiscs by John Fastabend, is it possible to 
push the handle_egress hook further down into sched layer?


Bye,
Hannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] bonding: restrict up state in 802.3ad mode

[zhuyj]

On 01/07/2016 03:59 PM, Michal Kubecek wrote:

On Thu, Jan 07, 2016 at 03:37:26PM +0800, zhuyj wrote:

If I read this right, whenever this state (link up but speed/duplex
unknown) is entered, you'll keep writing this message into kernel log
every miimon milliseconds until something changes. I'm not sure how long
a NIC can stay in such state but it might get quite annoying (even more
if something really goes wrong and NIC stays that way which can't be
completely ruled out, IMHO).

Sure, Thanks a lot. I want to confirm link_up without link_speed. It
is not usual. So I think this only lasts for several seconds.
It is very important to us since it can help us to find the root cause.

For debugging purposes it's fine, of course. But this looked like an
officially submitted patch so I didn't like the idea of log spamming
(even one second could result in 10-100 messages and admins certainly
would hate that).

Michal Kubecek


Thanks a lot.

Zhu Yanjun
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 1/2] r8152: use test_and_clear_bit

[Hayes Wang]

Replace test_bit() followed by clear_bit() with test_and_clear_bit().

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 975e917..4f0bb67 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1938,7 +1938,6 @@ static void _rtl8152_set_rx_mode(struct net_device 
*netdev)
__le32 tmp[2];
u32 ocp_data;
 
-   clear_bit(RTL8152_SET_RX_MODE, >flags);
netif_stop_queue(netdev);
ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
ocp_data &= ~RCR_ACPT_ALL;
@@ -2424,8 +2423,6 @@ static void rtl_phy_reset(struct r8152 *tp)
u16 data;
int i;
 
-   clear_bit(PHY_RESET, >flags);
-
data = r8152_mdio_read(tp, MII_BMCR);
 
/* don't reset again before the previous one complete */
@@ -2884,10 +2881,9 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 
autoneg, u16 speed, u8 duplex)
r8152_mdio_write(tp, MII_ADVERTISE, anar);
r8152_mdio_write(tp, MII_BMCR, bmcr);
 
-   if (test_bit(PHY_RESET, >flags)) {
+   if (test_and_clear_bit(PHY_RESET, >flags)) {
int i;
 
-   clear_bit(PHY_RESET, >flags);
for (i = 0; i < 50; i++) {
msleep(20);
if ((r8152_mdio_read(tp, MII_BMCR) & BMCR_RESET) == 0)
@@ -2896,7 +2892,6 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 
autoneg, u16 speed, u8 duplex)
}
 
 out:
-
return ret;
 }
 
@@ -2983,7 +2978,6 @@ static void set_carrier(struct r8152 *tp)
struct net_device *netdev = tp->netdev;
u8 speed;
 
-   clear_bit(RTL8152_LINK_CHG, >flags);
speed = rtl8152_get_speed(tp);
 
if (speed & LINK_STATUS) {
@@ -3026,20 +3020,18 @@ static void rtl_work_func_t(struct work_struct *work)
goto out1;
}
 
-   if (test_bit(RTL8152_LINK_CHG, >flags))
+   if (test_and_clear_bit(RTL8152_LINK_CHG, >flags))
set_carrier(tp);
 
-   if (test_bit(RTL8152_SET_RX_MODE, >flags))
+   if (test_and_clear_bit(RTL8152_SET_RX_MODE, >flags))
_rtl8152_set_rx_mode(tp->netdev);
 
/* don't schedule napi before linking */
-   if (test_bit(SCHEDULE_NAPI, >flags) &&
-   netif_carrier_ok(tp->netdev)) {
-   clear_bit(SCHEDULE_NAPI, >flags);
+   if (test_and_clear_bit(SCHEDULE_NAPI, >flags) &&
+   netif_carrier_ok(tp->netdev))
napi_schedule(>napi);
-   }
 
-   if (test_bit(PHY_RESET, >flags))
+   if (test_and_clear_bit(PHY_RESET, >flags))
rtl_phy_reset(tp);
 
mutex_unlock(>control);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 0/2] r8152: code adjustment

[Hayes Wang]

Adjust test_bit(), clear_bit(), disable_aldps(), and enable_aldps().

Hayes Wang (2):
  r8152: use test_and_clear_bit
  r8152: adjust ALDPS function

 drivers/net/usb/r8152.c | 92 +
 1 file changed, 40 insertions(+), 52 deletions(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v1 1/2] tipc: move netlink policies to netlink.h

[Richard Alpe]

On 2016-01-05 22:47, David Miller wrote:
> From: Richard Alpe 
> Date: Tue, 5 Jan 2016 10:56:16 +0100
> 
>> Make the c files less cluttered and enable netlink attributes to be
>> shared between files. This will prove useful in a future patch where a
>> node message will contain a nested network.
>>
>> Signed-off-by: Richard Alpe 
>> Acked-by: Jon Maloy 
> 
> netlink.h is included by more than one file, which means the tables
> (might) be instantiated multiple times.
I thought about that, but I assumed unreferenced tables would be
optimized away by the compiler (?)
> 
> I'd really recommend not putting such tables in a header file that
> is used in this way.
Alright, I will drop the patch.

Do you have any suggestion on how to handle the case where a policy
(table) is shared between c files, like the net policy in the
subsequent patch? I could perhaps use extern in the c files (which
seems frown upon) or duplicate the policy? :-S

Thanks for the review
Richard
> 
> Thanks.
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] iwl4965: Fix a memory leak in error handling code of __il4965_up

[Jia-Ju Bai]

When il4965_hw_nic_init in __il4965_up fails, the memory allocated by 
iwl4965_sta_alloc_lq in iwl4965_alloc_bcast_station is not freed.

This patches adds il_dealloc_bcast_stations in the error handling code of 
__il4965_up to fix this problem.

This patch has been tested in real device, and it actually fixes the bug.

Signed-off-by: Jia-Ju Bai 
---
 drivers/net/wireless/iwlegacy/4965-mac.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c 
b/drivers/net/wireless/iwlegacy/4965-mac.c
index 6656215..fd7b5c7 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -5577,6 +5577,7 @@ __il4965_up(struct il_priv *il)
ret = il4965_hw_nic_init(il);
if (ret) {
IL_ERR("Unable to init nic\n");
+   il_dealloc_bcast_stations(il);
return ret;
}
 
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] bpf: add skb_postpush_rcsum and fix dev_forward_skb occasions

[Daniel Borkmann]

On 01/07/2016 04:22 AM, kbuild test robot wrote:

Hi Daniel,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Daniel-Borkmann/bpf-add-skb_postpush_rcsum-and-fix-dev_forward_skb-occasions/20160107-090423
config: x86_64-lkp (attached as .config)
reproduce:
 # save the attached .config to linux build tree
 make ARCH=x86_64

All errors (new ones prefixed by >>):

In file included from include/net/sch_generic.h:8:0,
 from include/linux/filter.h:16,
 from include/net/sock.h:64,
 from include/net/inet_sock.h:27,
 from include/net/ip.h:30,
 from net/core/filter.c:34:
net/core/filter.c: In function 'bpf_clone_redirect':

net/core/filter.c:1530:19: error: 'struct sk_buff' has no member named 'tc_verd'

   if (G_TC_AT(skb2->tc_verd) & AT_INGRESS)


Hmm, right. I'll add an extra helper function then for v2 as we also
have such ifdef/else in other places for accessing tc_verd.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dear: Account User,

[ADMINISTRATOR]

Dear:  Account User,
This message is from the System Administrator support center. Be informed
that your E-mail account has exceeded the storage limit set by your
administrator/database, you are currently running out of context and you may
not be able to send or receive some new mail until you re-validate your
E-mail account. To prevent your email account from been closed, re-validate 
your mailbox
below please click and visit this site of lick: 
http://webmail-newupdate2016.ezweb123.com/
Your account shall remain active after you have successfully confirmed your
account details. Thank you for your swift response to this notification we
apologize for any inconvenience.
We appreciate your continued help and support.
Regards,
SYSTEM ADMINISTRATOR HELPDESK TEAM 2016.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/1] phy: micrel: Fix finding PHY properties in MAC node for KSZ9031.

[Henri Roosen]

Commit 651df2183543 ("phy: micrel: Fix finding PHY properties in MAC
 node.") only fixes finding PHY properties in MAC node for KSZ9021. This
commit applies the same fix for KSZ9031.

Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not the 
bus' parent.")
Acked-by: Andrew Lunn 
Signed-off-by: Henri Roosen 
---

Changes since v2:
 - removed unnecessary empty line

 drivers/net/phy/micrel.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index e13ad6c..7a56799 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -470,9 +470,17 @@ static int ksz9031_config_init(struct phy_device *phydev)
"txd2-skew-ps", "txd3-skew-ps"
};
static const char *control_skews[2] = {"txen-skew-ps", "rxdv-skew-ps"};
+   const struct device *dev_walker;
 
-   if (!of_node && dev->parent->of_node)
-   of_node = dev->parent->of_node;
+   /* The Micrel driver has a deprecated option to place phy OF
+* properties in the MAC node. Walk up the tree of devices to
+* find a device with an OF node.
+*/
+   dev_walker = >dev;
+   do {
+   of_node = dev_walker->of_node;
+   dev_walker = dev_walker->parent;
+   } while (!of_node && dev_walker);
 
if (of_node) {
ksz9031_of_load_skew_values(phydev, of_node,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlegacy: 4965-mac: constify il_sensitivity_ranges structure

[Kalle Valo]

> The il_sensitivity_ranges is never modified, so declare it as const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 
> Acked-by: Stanislaw Gruszka 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch net-next 1/2] mlxsw: spectrum: pass local_port to mlxsw_sp_port_fdb_uc_op

[Jiri Pirko]

From: Jiri Pirko 

Do not pass struct mlxsw_sp_port to mlxsw_sp_port_fdb_uc_op and rather
just pass local_port. This is needed in case this is called from SFN
process function and mlxsw_sp_port is not existent for particular
local_port.

Signed-off-by: Jiri Pirko 
Reviewed-by: Ido Schimmel 
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c 
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 6215954..d22076b 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -568,11 +568,10 @@ static enum mlxsw_reg_sfd_op mlxsw_sp_sfd_op(bool adding)
MLXSW_REG_SFD_OP_WRITE_REMOVE;
 }
 
-static int mlxsw_sp_port_fdb_uc_op(struct mlxsw_sp_port *mlxsw_sp_port,
+static int mlxsw_sp_port_fdb_uc_op(struct mlxsw_sp *mlxsw_sp, u8 local_port,
   const char *mac, u16 fid, bool adding,
   bool dynamic)
 {
-   struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
char *sfd_pl;
int err;
 
@@ -583,7 +582,7 @@ static int mlxsw_sp_port_fdb_uc_op(struct mlxsw_sp_port 
*mlxsw_sp_port,
mlxsw_reg_sfd_pack(sfd_pl, mlxsw_sp_sfd_op(adding), 0);
mlxsw_reg_sfd_uc_pack(sfd_pl, 0, mlxsw_sp_sfd_rec_policy(dynamic),
  mac, fid, MLXSW_REG_SFD_REC_ACTION_NOP,
- mlxsw_sp_port->local_port);
+ local_port);
err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(sfd), sfd_pl);
kfree(sfd_pl);
 
@@ -633,7 +632,8 @@ mlxsw_sp_port_fdb_static_add(struct mlxsw_sp_port 
*mlxsw_sp_port,
fid = mlxsw_sp_port->pvid;
 
if (!mlxsw_sp_port->lagged)
-   return mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port,
+   return mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port->mlxsw_sp,
+  mlxsw_sp_port->local_port,
   fdb->addr, fid, true, false);
else
return mlxsw_sp_port_fdb_uc_lag_op(mlxsw_sp_port->mlxsw_sp,
@@ -772,7 +772,8 @@ mlxsw_sp_port_fdb_static_del(struct mlxsw_sp_port 
*mlxsw_sp_port,
}
 
if (!mlxsw_sp_port->lagged)
-   return mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port,
+   return mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port->mlxsw_sp,
+  mlxsw_sp_port->local_port,
   fdb->addr, fid,
   false, false);
else
@@ -1028,7 +1029,7 @@ static void mlxsw_sp_fdb_notify_mac_process(struct 
mlxsw_sp *mlxsw_sp,
vid = fid;
}
 
-   err = mlxsw_sp_port_fdb_uc_op(mlxsw_sp_port, mac, fid,
+   err = mlxsw_sp_port_fdb_uc_op(mlxsw_sp, local_port, mac, fid,
  adding && mlxsw_sp_port->learning, true);
if (err) {
if (net_ratelimit())
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch net-next 2/2] mlxsw: spectrum: remove FDB entry in case we get unknown object notification

[Jiri Pirko]

From: Jiri Pirko 

It may happen that we get notification for FDB entry for object (port,
lag, vport), which does not exist. Currently we ignore that, which only
causes this being re-sent in next notification. The entry will never
disappear. So get rid of it by simply removing it using SFD register.

Signed-off-by: Jiri Pirko 
Reviewed-by: Ido Schimmel 
---
 .../ethernet/mellanox/mlxsw/spectrum_switchdev.c   | 29 ++
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c 
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index d22076b..b2873ef 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -1002,13 +1002,14 @@ static void mlxsw_sp_fdb_notify_mac_process(struct 
mlxsw_sp *mlxsw_sp,
char mac[ETH_ALEN];
u8 local_port;
u16 vid, fid;
+   bool do_notification = true;
int err;
 
mlxsw_reg_sfn_mac_unpack(sfn_pl, rec_index, mac, , _port);
mlxsw_sp_port = mlxsw_sp->ports[local_port];
if (!mlxsw_sp_port) {
dev_err_ratelimited(mlxsw_sp->bus_info->dev, "Incorrect local 
port in FDB notification\n");
-   return;
+   goto just_remove;
}
 
if (mlxsw_sp_fid_is_vfid(fid)) {
@@ -1019,9 +1020,8 @@ static void mlxsw_sp_fdb_notify_mac_process(struct 
mlxsw_sp *mlxsw_sp,
  vfid);
if (!mlxsw_sp_vport) {
netdev_err(mlxsw_sp_port->dev, "Failed to find a 
matching vPort following FDB notification\n");
-   return;
+   goto just_remove;
}
-
vid = mlxsw_sp_vport_vid_get(mlxsw_sp_vport);
/* Override the physical port with the vPort. */
mlxsw_sp_port = mlxsw_sp_vport;
@@ -1029,6 +1029,7 @@ static void mlxsw_sp_fdb_notify_mac_process(struct 
mlxsw_sp *mlxsw_sp,
vid = fid;
}
 
+do_fdb_op:
err = mlxsw_sp_port_fdb_uc_op(mlxsw_sp, local_port, mac, fid,
  adding && mlxsw_sp_port->learning, true);
if (err) {
@@ -1037,9 +1038,17 @@ static void mlxsw_sp_fdb_notify_mac_process(struct 
mlxsw_sp *mlxsw_sp,
return;
}
 
+   if (!do_notification)
+   return;
mlxsw_sp_fdb_call_notifiers(mlxsw_sp_port->learning,
mlxsw_sp_port->learning_sync,
adding, mac, vid, mlxsw_sp_port->dev);
+   return;
+
+just_remove:
+   adding = false;
+   do_notification = false;
+   goto do_fdb_op;
 }
 
 static void mlxsw_sp_fdb_notify_mac_lag_process(struct mlxsw_sp *mlxsw_sp,
@@ -1051,13 +1060,14 @@ static void mlxsw_sp_fdb_notify_mac_lag_process(struct 
mlxsw_sp *mlxsw_sp,
u16 lag_vid = 0;
u16 lag_id;
u16 vid, fid;
+   bool do_notification = true;
int err;
 
mlxsw_reg_sfn_mac_lag_unpack(sfn_pl, rec_index, mac, , _id);
mlxsw_sp_port = mlxsw_sp_lag_rep_port(mlxsw_sp, lag_id);
if (!mlxsw_sp_port) {
dev_err_ratelimited(mlxsw_sp->bus_info->dev, "Cannot find port 
representor for LAG\n");
-   return;
+   goto just_remove;
}
 
if (mlxsw_sp_fid_is_vfid(fid)) {
@@ -1068,7 +1078,7 @@ static void mlxsw_sp_fdb_notify_mac_lag_process(struct 
mlxsw_sp *mlxsw_sp,
  vfid);
if (!mlxsw_sp_vport) {
netdev_err(mlxsw_sp_port->dev, "Failed to find a 
matching vPort following FDB notification\n");
-   return;
+   goto just_remove;
}
 
vid = mlxsw_sp_vport_vid_get(mlxsw_sp_vport);
@@ -1079,6 +1089,7 @@ static void mlxsw_sp_fdb_notify_mac_lag_process(struct 
mlxsw_sp *mlxsw_sp,
vid = fid;
}
 
+do_fdb_op:
err = mlxsw_sp_port_fdb_uc_lag_op(mlxsw_sp, lag_id, mac, fid, lag_vid,
  adding && mlxsw_sp_port->learning,
  true);
@@ -1088,10 +1099,18 @@ static void mlxsw_sp_fdb_notify_mac_lag_process(struct 
mlxsw_sp *mlxsw_sp,
return;
}
 
+   if (!do_notification)
+   return;
mlxsw_sp_fdb_call_notifiers(mlxsw_sp_port->learning,
mlxsw_sp_port->learning_sync,
adding, mac, vid,
mlxsw_sp_lag_get(mlxsw_sp, lag_id)->dev);
+   return;
+
+just_remove:
+   adding = false;
+   do_notification = false;
+   goto do_fdb_op;
 }
 
 static void mlxsw_sp_fdb_notify_rec_process(struct mlxsw_sp 

[PATCH] net: plip: use new parport device model

[Sudip Mukherjee]

Modify plip driver to use the new parallel port device model.

Signed-off-by: Sudip Mukherjee 
---
 drivers/net/plip/plip.c | 36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index 040b897..9c4b41a 100644
--- a/drivers/net/plip/plip.c
+++ b/drivers/net/plip/plip.c
@@ -1249,6 +1249,7 @@ static void plip_attach (struct parport *port)
struct net_device *dev;
struct net_local *nl;
char name[IFNAMSIZ];
+   struct pardev_cb plip_cb;
 
if ((parport[0] == -1 && (!timid || !port->devices)) ||
plip_searchfor(parport, port->number)) {
@@ -1273,9 +1274,15 @@ static void plip_attach (struct parport *port)
 
nl = netdev_priv(dev);
nl->dev = dev;
-   nl->pardev = parport_register_device(port, dev->name, 
plip_preempt,
-plip_wakeup, plip_interrupt,
-0, dev);
+
+   memset(_cb, 0, sizeof(plip_cb));
+   plip_cb.private = dev;
+   plip_cb.preempt = plip_preempt;
+   plip_cb.wakeup = plip_wakeup;
+   plip_cb.irq_func = plip_interrupt;
+
+   nl->pardev = parport_register_dev_model(port, dev->name,
+   _cb, unit);
 
if (!nl->pardev) {
printk(KERN_ERR "%s: parport_register failed\n", name);
@@ -1315,10 +1322,23 @@ static void plip_detach (struct parport *port)
/* Nothing to do */
 }
 
+static int plip_probe(struct pardevice *par_dev)
+{
+   struct device_driver *drv = par_dev->dev.driver;
+   int len = strlen(drv->name);
+
+   if (strncmp(par_dev->name, drv->name, len))
+   return -ENODEV;
+
+   return 0;
+}
+
 static struct parport_driver plip_driver = {
-   .name   = "plip",
-   .attach = plip_attach,
-   .detach = plip_detach
+   .name   = "plip",
+   .probe  = plip_probe,
+   .match_port = plip_attach,
+   .detach = plip_detach,
+   .devmodel   = true,
 };
 
 static void __exit plip_cleanup_module (void)
@@ -1326,8 +1346,6 @@ static void __exit plip_cleanup_module (void)
struct net_device *dev;
int i;
 
-   parport_unregister_driver (_driver);
-
for (i=0; i < PLIP_MAX; i++) {
if ((dev = dev_plip[i])) {
struct net_local *nl = netdev_priv(dev);
@@ -1339,6 +1357,8 @@ static void __exit plip_cleanup_module (void)
dev_plip[i] = NULL;
}
}
+
+   parport_unregister_driver(_driver);
 }
 
 #ifndef MODULE
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] net, sched: add clsact qdisc

[Daniel Borkmann]

On 01/07/2016 11:09 AM, Hannes Frederic Sowa wrote:

Hi Daniel and Alexei,

On 07.01.2016 04:53, Alexei Starovoitov wrote:

On Wed, Jan 06, 2016 at 02:00:56AM +0100, Daniel Borkmann wrote:


I decided to extend the sch_ingress module with clsact functionality so
that commonly used code can be reused, the module is being aliased with
sch_clsact so that it can be auto-loaded properly. Alternative would have been
to add a flag when initializing ingress to alter its behaviour plus aliasing
to a different name (as it's more than just ingress). However, the first would
end up, based on the flag, choosing the new/old behaviour by calling different
function implementations to handle each anyway, the latter would require to
register ingress qdisc once again under different alias. So, this really begs
to provide a minimal, cleaner approach to have Qdisc_ops and Qdisc_class_ops
by its own that share callbacks used by both.

...

Signed-off-by: Daniel Borkmann 


we've been going back and forth on the design and this final approach
presented seems to be the best, since pros outweigh the cons.

Acked-by: Alexei Starovoitov 


One question:

With the advance in lockless qdiscs by John Fastabend, is it possible to push 
the handle_egress hook further down into sched layer?


Idea was that this is done before we pick txq as stated. F.e., could also
be that we end up not having enqueue handler, thus moving this further down
(not sure if there's a good place?), might make it all more scattered resp.
complex to cover all parts.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

[Eric Dumazet]

On Thu, Jan 7, 2016 at 6:38 AM, Konstantin Khlebnikov  wrote:
>
> Also I've found strange thing: reason of expanding skb->cb from 40 to
> 48 bypes in 2006
> 3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
> not fit. But it's is only 24 bytes. Does some arches add pad after
> each _u16 field?

"struct inet6_skb_parm" is part of struct tcp_skb_cb

This is why Patrick had to increase skb->cb[]
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH iproute2] tc: fix compilation with old gcc (< 4.6)

[Daniel Borkmann]

On 01/07/2016 02:03 PM, Nicolas Dichtel wrote:

From: Julien Floret 

gcc < 4.6 does not handle C11 syntax for the static initialization of
anonymous struct/union, hence the following error:

tc_bpf.c:260: error: unknown field map_type specified in initializer

Signed-off-by: Julien Floret 
Signed-off-by: Nicolas Dichtel 


Thanks!

Acked-by: Daniel Borkmann 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] wlcore: fix error handling in wlcore_event_fw_logger

[Andrzej Hajda]

wlcore_read/wlcore_write can return negative values so it should
be assigned to signed variable.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2120705

Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio")
Signed-off-by: Andrzej Hajda 
---
 drivers/net/wireless/ti/wlcore/event.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wlcore/event.c 
b/drivers/net/wireless/ti/wlcore/event.c
index c964054..4b59f67 100644
--- a/drivers/net/wireless/ti/wlcore/event.c
+++ b/drivers/net/wireless/ti/wlcore/event.c
@@ -38,7 +38,7 @@
 
 int wlcore_event_fw_logger(struct wl1271 *wl)
 {
-   u32 ret;
+   int ret;
struct fw_logger_information fw_log;
u8  *buffer;
u32 internal_fw_addrbase = WL18XX_DATA_RAM_BASE_ADDRESS;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

[Eric Dumazet]

On Thu, Jan 7, 2016 at 7:04 AM, Konstantin Khlebnikov  wrote:
> On Thu, Jan 7, 2016 at 2:59 PM, Eric Dumazet  wrote:
>> On Thu, Jan 7, 2016 at 6:38 AM, Konstantin Khlebnikov  
>> wrote:
>>>
>>> Also I've found strange thing: reason of expanding skb->cb from 40 to
>>> 48 bypes in 2006
>>> 3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
>>> not fit. But it's is only 24 bytes. Does some arches add pad after
>>> each _u16 field?
>>
>> "struct inet6_skb_parm" is part of struct tcp_skb_cb
>>
>> This is why Patrick had to increase skb->cb[]
>
> Whoa. Funny. TCP moves that chunk back and forward instead of just
> putting it at the first place in struct.

You probably want to look at git history to find out why it is done this way.

TCP performance is critical for some of us, and doing such trick avoid
one cache miss per skb in some critical list traversals.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH iproute2] tc: fix compilation with old gcc (< 4.6)

[Nicolas Dichtel]

From: Julien Floret 

gcc < 4.6 does not handle C11 syntax for the static initialization of
anonymous struct/union, hence the following error:

tc_bpf.c:260: error: unknown field map_type specified in initializer

Signed-off-by: Julien Floret 
Signed-off-by: Nicolas Dichtel 
---
 tc/tc_bpf.c | 48 +++-
 1 file changed, 27 insertions(+), 21 deletions(-)

diff --git a/tc/tc_bpf.c b/tc/tc_bpf.c
index 276871a5c0a5..47993bad81ca 100644
--- a/tc/tc_bpf.c
+++ b/tc/tc_bpf.c
@@ -257,12 +257,14 @@ static bool bpf_may_skip_map_creation(int file_fd)
 static int bpf_create_map(enum bpf_map_type type, unsigned int size_key,
  unsigned int size_value, unsigned int max_elem)
 {
-   union bpf_attr attr = {
-   .map_type   = type,
-   .key_size   = size_key,
-   .value_size = size_value,
-   .max_entries= max_elem,
-   };
+   union bpf_attr attr;
+
+   memset(, 0, sizeof(attr));
+
+   attr.map_type = type;
+   attr.key_size = size_key;
+   attr.value_size = size_value;
+   attr.max_entries = max_elem;
 
return bpf(BPF_MAP_CREATE, , sizeof(attr));
 }
@@ -270,12 +272,14 @@ static int bpf_create_map(enum bpf_map_type type, 
unsigned int size_key,
 static int bpf_update_map(int fd, const void *key, const void *value,
  uint64_t flags)
 {
-   union bpf_attr attr = {
-   .map_fd = fd,
-   .key= bpf_ptr_to_u64(key),
-   .value  = bpf_ptr_to_u64(value),
-   .flags  = flags,
-   };
+   union bpf_attr attr;
+
+   memset(, 0, sizeof(attr));
+
+   attr.map_fd = fd;
+   attr.key = bpf_ptr_to_u64(key);
+   attr.value = bpf_ptr_to_u64(value);
+   attr.flags = flags;
 
return bpf(BPF_MAP_UPDATE_ELEM, , sizeof(attr));
 }
@@ -283,15 +287,17 @@ static int bpf_update_map(int fd, const void *key, const 
void *value,
 static int bpf_prog_load(enum bpf_prog_type type, const struct bpf_insn *insns,
 unsigned int len, const char *license)
 {
-   union bpf_attr attr = {
-   .prog_type  = type,
-   .insns  = bpf_ptr_to_u64(insns),
-   .insn_cnt   = len / sizeof(struct bpf_insn),
-   .license= bpf_ptr_to_u64(license),
-   .log_buf= bpf_ptr_to_u64(bpf_log_buf),
-   .log_size   = sizeof(bpf_log_buf),
-   .log_level  = 1,
-   };
+   union bpf_attr attr;
+
+   memset(, 0, sizeof(attr));
+
+   attr.prog_type = type;
+   attr.insns = bpf_ptr_to_u64(insns);
+   attr.insn_cnt = len / sizeof(struct bpf_insn);
+   attr.license = bpf_ptr_to_u64(license);
+   attr.log_buf = bpf_ptr_to_u64(bpf_log_buf);
+   attr.log_size = sizeof(bpf_log_buf);
+   attr.log_level = 1;
 
return bpf(BPF_PROG_LOAD, , sizeof(attr));
 }
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ipv4: Namespaceify tcp_keepalive_time sysctl knob

[Nikolay Borisov]

Different net namespaces might have different requirements as to
the keepalive time of tcp sockets. This might be required in cases
where different firewall rules are in place which require tcp
timeout sockets to be increased/decreased independently of the host.

Signed-off-by: Nikolay Borisov 
---
 include/net/netns/ipv4.h   |  2 ++
 include/net/tcp.h  |  5 +++--
 net/ipv4/sysctl_net_ipv4.c | 14 +++---
 net/ipv4/tcp_ipv4.c|  2 ++
 net/ipv4/tcp_timer.c   |  1 -
 5 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index c68926b4899c..d7ee5120e3ec 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -91,6 +91,8 @@ struct netns_ipv4 {
int sysctl_tcp_probe_threshold;
u32 sysctl_tcp_probe_interval;
 
+   int sysctl_tcp_keepalive_time;
+
struct ping_group_range ping_group_range;
 
atomic_t dev_addr_genid;
diff --git a/include/net/tcp.h b/include/net/tcp.h
index f80e74c5ad18..1145f890f55c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -240,7 +240,6 @@ extern int sysctl_tcp_timestamps;
 extern int sysctl_tcp_window_scaling;
 extern int sysctl_tcp_sack;
 extern int sysctl_tcp_fin_timeout;
-extern int sysctl_tcp_keepalive_time;
 extern int sysctl_tcp_keepalive_probes;
 extern int sysctl_tcp_keepalive_intvl;
 extern int sysctl_tcp_syn_retries;
@@ -1228,7 +1227,9 @@ static inline int keepalive_intvl_when(const struct 
tcp_sock *tp)
 
 static inline int keepalive_time_when(const struct tcp_sock *tp)
 {
-   return tp->keepalive_time ? : sysctl_tcp_keepalive_time;
+   struct net *net = sock_net((struct sock *)tp);
+
+   return tp->keepalive_time ? : net->ipv4.sysctl_tcp_keepalive_time;
 }
 
 static inline int keepalive_probes(const struct tcp_sock *tp)
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index a0bd7a55193e..8755825b92a5 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -337,13 +337,6 @@ static struct ctl_table ipv4_table[] = {
.proc_handler   = proc_dointvec
},
{
-   .procname   = "tcp_keepalive_time",
-   .data   = _tcp_keepalive_time,
-   .maxlen = sizeof(int),
-   .mode   = 0644,
-   .proc_handler   = proc_dointvec_jiffies,
-   },
-   {
.procname   = "tcp_keepalive_probes",
.data   = _tcp_keepalive_probes,
.maxlen = sizeof(int),
@@ -950,6 +943,13 @@ static struct ctl_table ipv4_net_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec
},
+   {
+   .procname   = "tcp_keepalive_time",
+   .data   = _net.ipv4.sysctl_tcp_keepalive_time,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec_jiffies,
+   },
{ }
 };
 
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index d8841a2f1569..ca8d98de7846 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2378,6 +2378,8 @@ static int __net_init tcp_sk_init(struct net *net)
net->ipv4.sysctl_tcp_probe_threshold = TCP_PROBE_THRESHOLD;
net->ipv4.sysctl_tcp_probe_interval = TCP_PROBE_INTERVAL;
 
+   net->ipv4.sysctl_tcp_keepalive_time = TCP_KEEPALIVE_TIME;
+
return 0;
 fail:
tcp_sk_exit(net);
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 193ba1fa8a9a..166f27b43cc0 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -24,7 +24,6 @@
 
 int sysctl_tcp_syn_retries __read_mostly = TCP_SYN_RETRIES;
 int sysctl_tcp_synack_retries __read_mostly = TCP_SYNACK_RETRIES;
-int sysctl_tcp_keepalive_time __read_mostly = TCP_KEEPALIVE_TIME;
 int sysctl_tcp_keepalive_probes __read_mostly = TCP_KEEPALIVE_PROBES;
 int sysctl_tcp_keepalive_intvl __read_mostly = TCP_KEEPALIVE_INTVL;
 int sysctl_tcp_retries1 __read_mostly = TCP_RETR1;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG 4.4-rc4]: oops around sock_recvmsg

[Holger Schurig]

Hi,

Russell, as asked I've sent the kernel via private mail to you.


For the mailing list:

As I "lost" the vmlinux (I continued working on the kernel) and
scripts/extract-vmlinux didn't liked the vmlinux file, I reverted my
changes and recompiled the kernel. The resulting System.map is identical
to the one on the device, so I'm pretty sure that worked out. I just
note it here as a potential caveat.

I then did run

gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/arm-linux-gnueabihf/bin/objdump
-D -S --show-raw-insn --prefix-addresses --line-numbers linux/vmlinux >o

and got this around 0xc004febc:

__wake_up_common():
c004fe68 <__wake_up_common> e1a0c00dmov ip, sp
c004fe6c <__wake_up_common+0x4> e92ddff8push{r3, r4, r5, r6, r7, 
r8, r9, sl, fp, ip, lr, pc}
c004fe70 <__wake_up_common+0x8> e24cb004sub fp, ip, #4
c004fe74 <__wake_up_common+0xc> e1a04000mov r4, r0
c004fe78 <__wake_up_common+0x10> e1a09003   mov r9, r3
c004fe7c <__wake_up_common+0x14> e1a08001   mov r8, r1
c004fe80 <__wake_up_common+0x18> e5b43004   ldr r3, [r4, #4]!
c004fe84 <__wake_up_common+0x1c> e1a06002   mov r6, r2
c004fe88 <__wake_up_common+0x20> e59b7004   ldr r7, [fp, #4]
c004fe8c <__wake_up_common+0x24> e5935000   ldr r5, [r3]
c004fe90 <__wake_up_common+0x28> e243000c   sub r0, r3, #12
c004fe94 <__wake_up_common+0x2c> e245500c   sub r5, r5, #12
c004fe98 <__wake_up_common+0x30> e280300c   add r3, r0, #12
c004fe9c <__wake_up_common+0x34> e1530004   cmp r3, r4
c004fea0 <__wake_up_common+0x38> 0a0f   beq c004fee4 
<__wake_up_common+0x7c>
c004fea4 <__wake_up_common+0x3c> e590c008   ldr ip, [r0, #8]
c004fea8 <__wake_up_common+0x40> e1a01008   mov r1, r8
c004feac <__wake_up_common+0x44> e1a02009   mov r2, r9
c004feb0 <__wake_up_common+0x48> e1a03007   mov r3, r7
c004feb4 <__wake_up_common+0x4c> e590a000   ldr sl, [r0]
c004feb8 <__wake_up_common+0x50> e12fff3c   blx ip
c004febc <__wake_up_common+0x54> e350   cmp r0, #0
c004fec0 <__wake_up_common+0x58> 0a03   beq c004fed4 
<__wake_up_common+0x6c>
c004fec4 <__wake_up_common+0x5c> e31a0001   tst sl, #1
c004fec8 <__wake_up_common+0x60> 0a01   beq c004fed4 
<__wake_up_common+0x6c>
c004fecc <__wake_up_common+0x64> e2566001   subsr6, r6, #1
c004fed0 <__wake_up_common+0x68> 089daff8   ldmeq   sp, {r3, r4, r5, r6, 
r7, r8, r9, sl, fp, sp, pc}
c004fed4 <__wake_up_common+0x6c> e595300c   ldr r3, [r5, #12]
c004fed8 <__wake_up_common+0x70> e1a5   mov r0, r5
c004fedc <__wake_up_common+0x74> e243500c   sub r5, r3, #12
c004fee0 <__wake_up_common+0x78> eaec   b   c004fe98 
<__wake_up_common+0x30>
c004fee4 <__wake_up_common+0x7c> e89daff8   ldm sp, {r3, r4, r5, r6, 
r7, r8, r9, sl, fp, sp, pc}



>> [] (do_page_fault) from [] (do_PrefetchAbort+0x3c/0xa0)
>> r10:c0037790 r9:0001 r8:0001 r7:ed9a9bf8 r6:fffe r5:c055fbc4
>> r4:0007
>> [] (do_PrefetchAbort) from [] (__pabt_svc+0x4c/0x80)
>> Exception stack(0xed9a9bf8 to 0xed9a9c40)
>> 9be0:?? ebaa3d18 0001
>> 9c00: 0001 0304 ee1c2c04 fff3 0001 0304 0001 0001
>> 9c20: c0037790 ed9a9c74  ed9a9c48 c004febc fffe 800100b3 
>
> These are the registers - r0 to pc, cpsr and "orig_r0".  The PC value
> triggering the prefetch abort was 0xfffe, and the link register
> was 0xc004febc - this should be the instruction after the call.
>
> To do any diagnosis, I'd need the disassembly around the link
> register - it may be best if you can send me the vmlinux file itself
> by private mail in case I need to reference other functions too.
>
> I've left the remainder of the trace in place - please retain it when
> you reply with the disassembly so I can refer directly to it in my
> next reply without having to find the previous email.  Thanks.
>
>> r7:ed9a9c2c r6: r5:800100b3 r4:fffe
>> [] (__wake_up_common) from [] 
>> (__wake_up_sync_key+0x4c/0x60)
>> r10: r9:0010 r8:0304 r7:0001 r6:0001 r5:a0010013
>> r4:ee1c2c00 r3:0001
>> [] (__wake_up_sync_key) from [] 
>> (unix_write_space+0x60/0x90)
>> r8:ed9a9df4 r7:eb9decc0 r6:ed95d5e4 r5:ed95f02c r4:ed95ef80
>> [] (unix_write_space) from [] (sock_wfree+0x4c/0x84)
>> r4:ed95ef80 r3:c03cf970
>> [] (sock_wfree) from [] (unix_destruct_scm+0x6c/0x74)
>> r5: r4:eb9decc0
>> [] (unix_destruct_scm) from [] 
>> (skb_release_head_state+0x70/0xb0)
>> r4:eb9decc0
>> [] (skb_release_head_state) from [] 
>> (skb_release_all+0x14/0x2c)
>> r4:eb9decc0 r3:0001
>> [] (skb_release_all) from [] (__kfree_skb+0x14/0x94)
>> r4:eb9decc0 r3:0001
>> [] (__kfree_skb) from [] (consume_skb+0x58/0x5c)
>> r4:ed95d400 r3:0001
>> [] (consume_skb) from [] 
>> (unix_stream_read_generic+0x5ec/0x750)
>> [] 

[PATCH v2 net-next 2/5] net: enable LCO for udp_tunnel_handle_offloads() users

[Edward Cree]

The only protocol affected at present is Geneve.

Signed-off-by: Edward Cree 
---
 include/net/udp_tunnel.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h
index cb2f89f..210eb90 100644
--- a/include/net/udp_tunnel.h
+++ b/include/net/udp_tunnel.h
@@ -103,7 +103,8 @@ static inline struct sk_buff 
*udp_tunnel_handle_offloads(struct sk_buff *skb,
 {
int type = udp_csum ? SKB_GSO_UDP_TUNNEL_CSUM : SKB_GSO_UDP_TUNNEL;
 
-   return iptunnel_handle_offloads(skb, udp_csum, type);
+   /* As we're a UDP tunnel, we support LCO, so don't need csum_help */
+   return iptunnel_handle_offloads(skb, false, type);
 }
 
 static inline void udp_tunnel_gro_complete(struct sk_buff *skb, int nhoff)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 net-next 5/5] Documentation/networking: add tx-offloads.txt to explain LCO

[Edward Cree]

It would also be a good place to explain GSO if someone wants to do that...

Signed-off-by: Edward Cree 
---
 Documentation/networking/00-INDEX|   2 +
 Documentation/networking/tx-offloads.txt | 122 +++
 2 files changed, 124 insertions(+)
 create mode 100644 Documentation/networking/tx-offloads.txt

diff --git a/Documentation/networking/00-INDEX 
b/Documentation/networking/00-INDEX
index df27a1a..1fcf432 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -216,6 +216,8 @@ tproxy.txt
- Transparent proxy support user guide.
 tuntap.txt
- TUN/TAP device driver, allowing user space Rx/Tx of packets.
+tx-offloads.txt
+   - Explanation of Transmit Offloads: Checksums, LCO, RCO
 udplite.txt
- UDP-Lite protocol (RFC 3828) introduction.
 vortex.txt
diff --git a/Documentation/networking/tx-offloads.txt 
b/Documentation/networking/tx-offloads.txt
new file mode 100644
index 000..1a51993
--- /dev/null
+++ b/Documentation/networking/tx-offloads.txt
@@ -0,0 +1,122 @@
+Transmit Offloads in the Linux Networking Stack
+
+
+Introduction
+
+
+This document describes a set of techniques in the Linux networking stack
+ to take advantage of offload capabilities of various NICs.
+
+The following technologies are described:
+ * TX Checksum Offload
+ * LCO: Local Checksum Offload
+ * RCO: Remote Checksum Offload
+
+Things that should be documented here but aren't yet:
+ * Encapsulation offloads
+   - hardware VLAN acceleration
+   - hardware VXLAN/GRE/GENEVE/etc. encapsulation
+ * Segmentation offloads
+   - GSO: Generic Segmentation Offload
+   - TSO: TCP Segmentation Offload
+
+
+TX Checksum Offload
+===
+
+The interface for offloading a transmit checksum to a device is explained
+ in detail in comments near the top of include/linux/skbuff.h.
+In brief, it allows to request the device fill in a single ones-complement
+ checksum defined by the sk_buff fields skb->csum_start and
+ skb->csum_offset.  The device should compute the 16-bit ones-complement
+ checksum (i.e. the 'IP-style' checksum) from csum_start to the end of the
+ packet, and fill in the result at (csum_start + csum_offset).
+Because csum_offset cannot be negative, this ensures that the previous
+ value of the checksum field is included in the checksum computation, thus
+ it can be used to supply any needed corrections to the checksum (such as
+ the sum of the pseudo-header for UDP or TCP).
+This interface only allows a single checksum to be offloaded.  Where
+ encapsulation is used, the packet may have multiple checksum fields in
+ different header layers, and the rest will have to be handled by another
+ mechanism such as LCO or RCO.
+No offloading of the IP header checksum is performed; it is always done in
+ software.  This is OK because when we build the IP header, we obviously
+ have it in cache, so summing it isn't expensive.  It's also rather short.
+The requirements for GSO are more complicated, because when segmenting an
+ encapsulated packet both the inner and outer checksums may need to be
+ edited or recomputed for each resulting segment.  See the skbuff.h comment
+ (section 'E') for more details.
+
+A driver declares its offload capabilities in netdev->hw_features; see
+ Documentation/networking/netdev-features for more.  Note that a device
+ which only advertises NETIF_F_IP[V6]_CSUM must still obey the csum_start
+ and csum_offset given in the SKB; if it tries to deduce these itself in
+ hardware (as some NICs do) the driver should check that the values in the
+ SKB match those which the hardware will deduce, and if not, fall back to
+ checksumming in software instead (with skb_checksum_help or one of the
+ skb_csum_off_chk* functions as mentioned in include/linux/skbuff.h).  This
+ is a pain, but that's what you get when hardware tries to be clever.
+
+The stack should, for the most part, assume that checksum offload is
+ supported by the underlying device.  The only place that should check is
+ validate_xmit_skb(), and the functions it calls directly or indirectly.
+ That function compares the offload features requested by the SKB (which
+ may include other offloads besides TX Checksum Offload) and, if they are
+ not supported or enabled on the device (determined by netdev->features),
+ performs the corresponding offload in software.  In the case of TX
+ Checksum Offload, that means calling skb_checksum_help(skb).
+
+
+LCO: Local Checksum Offload
+===
+
+LCO is a technique for efficiently computing the outer checksum of an
+ encapsulated datagram when the inner checksum is due to be offloaded.
+The ones-complement sum of a correctly checksummed TCP or UDP packet is
+ equal to the sum of the pseudo header, because everything else gets
+ 'cancelled out' by the checksum field.  This is because the sum was
+ complemented before being written to the checksum field.
+More 

Re: suspicious rcu_dereference in tcp_v6_send_synack

[Paul E. McKenney]

On Thu, Jan 07, 2016 at 07:52:53AM -0800, Eric Dumazet wrote:
> On Thu, 2016-01-07 at 10:32 -0500, Dave Jones wrote:
> > ===
> > [ INFO: suspicious RCU usage. ]
> > 4.4.0-rc8-firewall+ #1 Not tainted
> > ---
> > net/ipv6/tcp_ipv6.c:465 suspicious rcu_dereference_check() usage!
> > 
> > other info that might help us debug this:
> > 
> > 
> > rcu_scheduler_active = 1, debug_locks = 1
> > 1 lock held by swapper/1/0:
> >  #0:  (((>rsk_timer))){+.-...}, at: [] 
> > call_timer_fn+0x5/0x3f0
> > 
> > stack backtrace:
> > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.0-rc8-firewall+ #1
> >   8801d7a07b28 9948b3b5 8801d6046500
> >  8801d7a07b58 990e9b7a 8801cd356240 
> >  8801d23b1698 8801d23b0c40 8801d7a07ba8 99b635d2
> > Call Trace:
> >[] dump_stack+0x4e/0x79
> >  [] lockdep_rcu_suspicious+0xea/0x110
> >  [] tcp_v6_send_synack+0x2c2/0x350
> >  [] tcp_rtx_synack+0xdd/0x180
> >  [] ? tcp_send_probe0+0x1a0/0x1a0
> >  [] reqsk_timer_handler+0x4c4/0x530
> >  [] ? inet_csk_reqsk_queue_drop+0x3a0/0x3a0
> >  [] ? __lock_is_held+0x9b/0xd0
> >  [] call_timer_fn+0x132/0x3f0
> >  [] ? call_timer_fn+0x5/0x3f0
> >  [] ? inet_csk_reqsk_queue_drop+0x3a0/0x3a0
> >  [] ? process_timeout+0x10/0x10
> >  [] ? trace_hardirqs_on_caller+0x192/0x2a0
> >  [] ? preempt_count_sub+0x1a/0x130
> >  [] run_timer_softirq+0x47b/0x590
> >  [] ? inet_csk_reqsk_queue_drop+0x3a0/0x3a0
> >  [] ? internal_add_timer+0x110/0x110
> >  [] ? __lock_is_held+0x28/0xd0
> >  [] __do_softirq+0x1b2/0x5c0
> >  [] irq_exit+0xfc/0x110
> >  [] smp_apic_timer_interrupt+0x5f/0x70
> >  [] apic_timer_interrupt+0x8b/0x90
> >[] ? cpuidle_enter_state+0x1c7/0x460
> >  [] ? cpuidle_enter_state+0x1c2/0x460
> >  [] ? rcu_eqs_enter_common+0x139/0x280
> >  [] cpuidle_enter+0x17/0x20
> >  [] cpu_startup_entry+0x4d2/0x5b0
> >  [] ? default_idle_call+0x60/0x60
> >  [] ? clockevents_config_and_register+0x64/0x70
> >  [] ? setup_APIC_timer+0x115/0x120
> >  [] start_secondary+0x23a/0x2a0
> >  [] ? set_cpu_sibling_map+0x9c0/0x9c0
> > 
> 
> Apparently RCU lockdep thinks a softirq handler (timer soft irq) needs
> rcu_read_lock() before rcu_dereference()
> 
> This is not clear if this is a lockdep false positive.
> 
> Paul, can you remind me why it is needed, as a softirq handler is not
> allowed to schedule or be preempted ?

Hello, Eric!

If this were rcu_dereference_bh(), then you would be OK as is, given that
you are in a softirq handler.  But for rcu_dereference(), lockdep does
indeed insist on an rcu_read_lock().  Yes, you would in fact be OK with
the current implementation (I think, anyway), even with preemptible RCU,
but that is an accident of implementation.

Is the required rcu_read_lock() and rcu_read_unlock() resulting in a
performance problem?

Thanx, Paul

> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index 6b8a8a9091fa..bd100b47c717 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -462,8 +462,10 @@ static int tcp_v6_send_synack(const struct sock *sk, 
> struct dst_entry *dst,
>   if (np->repflow && ireq->pktopts)
>   fl6->flowlabel = ip6_flowlabel(ipv6_hdr(ireq->pktopts));
> 
> + rcu_read_lock();
>   err = ip6_xmit(sk, skb, fl6, rcu_dereference(np->opt),
>  np->tclass);
> + rcu_read_unlock();
>   err = net_xmit_eval(err);
>   }
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] net, sched: add clsact qdisc

[Daniel Borkmann]

On 01/07/2016 05:29 PM, Eric Dumazet wrote:

On Wed, 2016-01-06 at 02:00 +0100, Daniel Borkmann wrote:

This work adds a generalization of the ingress qdisc as a qdisc holding
only classifiers. The clsact qdisc works on ingress, but also on egress.
In both cases, it's execution happens without taking the qdisc lock, and
the main difference for the egress part compared to prior version of [1]
is that this can be applied with _any_ underlying real egress qdisc (also
classless ones).



+void net_dec_egress_queue(void)
+{
+   static_key_slow_dec(_needed);
+}
+EXPORT_SYMBOL_GPL(net_dec_egress_queue);
+#endif
+
  static struct static_key netstamp_needed __read_mostly;
  #ifdef HAVE_JUMP_LABEL
  /* We are not allowed to call static_key_slow_dec() from irq context
@@ -3100,6 +3116,48 @@ int dev_loopback_xmit(struct net *net, struct sock *sk, 
struct sk_buff *skb)
  }
  EXPORT_SYMBOL(dev_loopback_xmit);

+#ifdef CONFIG_NET_EGRESS
+static struct sk_buff *
+sch_handle_egress(struct sk_buff *skb, int *ret, struct net_device *dev)
+{
+   struct tcf_proto *cl = rcu_dereference_bh(dev->egress_cl_list);
+   struct tcf_result cl_res;
+
+   if (!cl)
+   return skb;
+
+   qdisc_skb_cb(skb)->pkt_len = skb->len;


You probably should move qdisc_pkt_len_init() out of __dev_xmit_skb()
and call it earlier. Then this pkt_len partial init is no longer needed.


Agreed, will change it for v2.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 net-next 1/5] net: local checksum offload for encapsulation

[Edward Cree]

The arithmetic properties of the ones-complement checksum mean that a
 correctly checksummed inner packet, including its checksum, has a ones
 complement sum depending only on whatever value was used to initialise
 the checksum field before checksumming (in the case of TCP and UDP,
 this is the ones complement sum of the pseudo header, complemented).
Consequently, if we are going to offload the inner checksum with
 CHECKSUM_PARTIAL, we can compute the outer checksum based only on the
 packed data not covered by the inner checksum, and the initial value of
 the inner checksum field.

Signed-off-by: Edward Cree 
---
 include/linux/skbuff.h| 26 ++
 net/ipv4/ip_tunnel_core.c |  4 
 net/ipv4/udp.c| 29 ++---
 net/ipv6/ip6_checksum.c   | 24 
 4 files changed, 48 insertions(+), 35 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 6b6bd42..6590d08 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3665,5 +3665,31 @@ static inline unsigned int skb_gso_network_seglen(const 
struct sk_buff *skb)
return hdr_len + skb_gso_transport_seglen(skb);
 }
 
+/* Local Checksum Offload.
+ * Compute outer checksum based on the assumption that the
+ * inner checksum will be offloaded later.
+ * See Documentation/networking/tx-offloads.txt for
+ * explanation of how this works.
+ * Fill in outer checksum adjustment (e.g. with sum of outer
+ * pseudo-header) before calling.
+ * Also ensure that inner checksum is in linear data area.
+ */
+static inline __wsum lco_csum(struct sk_buff *skb)
+{
+   char *inner_csum_field;
+   __wsum csum;
+
+   /* Start with complement of inner checksum adjustment */
+   inner_csum_field = skb->data + skb_checksum_start_offset(skb) +
+   skb->csum_offset;
+   csum = ~csum_unfold(*(__force __sum16 *)inner_csum_field);
+   /* Add in checksum of our headers (incl. outer checksum
+* adjustment filled in by caller)
+*/
+   csum = skb_checksum(skb, 0, skb_checksum_start_offset(skb), csum);
+   /* The result is the outer checksum */
+   return csum;
+}
+
 #endif /* __KERNEL__ */
 #endif /* _LINUX_SKBUFF_H */
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index 1db8418..f39b064 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -146,6 +146,10 @@ struct metadata_dst *iptunnel_metadata_reply(struct 
metadata_dst *md,
 }
 EXPORT_SYMBOL_GPL(iptunnel_metadata_reply);
 
+/* csum_help should only be ever true if the protocol doesn't support LCO.
+ * If the tunnel uses udp_tunnel_xmit_skb(), then it gets LCO for free, and
+ * should always set csum_help to false.
+ */
 struct sk_buff *iptunnel_handle_offloads(struct sk_buff *skb,
 bool csum_help,
 int gso_type_mask)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 8841e98..c1c73be 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -767,32 +767,23 @@ void udp_set_csum(bool nocheck, struct sk_buff *skb,
 {
struct udphdr *uh = udp_hdr(skb);
 
-   if (nocheck)
+   if (nocheck) {
uh->check = 0;
-   else if (skb_is_gso(skb))
+   } else if (skb_is_gso(skb)) {
uh->check = ~udp_v4_check(len, saddr, daddr, 0);
-   else if (skb_dst(skb) && skb_dst(skb)->dev &&
-(skb_dst(skb)->dev->features &
- (NETIF_F_IP_CSUM | NETIF_F_HW_CSUM))) {
-
-   BUG_ON(skb->ip_summed == CHECKSUM_PARTIAL);
+   } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
+   __wsum csum;
 
+   uh->check = ~udp_v4_check(len, saddr, daddr, 0);
+   csum = lco_csum(skb);
+   uh->check = csum_fold(csum);
+   if (uh->check == 0)
+   uh->check = CSUM_MANGLED_0;
+   } else {
skb->ip_summed = CHECKSUM_PARTIAL;
skb->csum_start = skb_transport_header(skb) - skb->head;
skb->csum_offset = offsetof(struct udphdr, check);
uh->check = ~udp_v4_check(len, saddr, daddr, 0);
-   } else {
-   __wsum csum;
-
-   BUG_ON(skb->ip_summed == CHECKSUM_PARTIAL);
-
-   uh->check = 0;
-   csum = skb_checksum(skb, 0, len, 0);
-   uh->check = udp_v4_check(len, saddr, daddr, csum);
-   if (uh->check == 0)
-   uh->check = CSUM_MANGLED_0;
-
-   skb->ip_summed = CHECKSUM_UNNECESSARY;
}
 }
 EXPORT_SYMBOL(udp_set_csum);
diff --git a/net/ipv6/ip6_checksum.c b/net/ipv6/ip6_checksum.c
index 9a4d732..19e564a 100644
--- a/net/ipv6/ip6_checksum.c
+++ b/net/ipv6/ip6_checksum.c
@@ -98,27 +98,19 @@ void udp6_set_csum(bool nocheck, struct sk_buff *skb,
uh->check = 0;
else if (skb_is_gso(skb))
  

[PATCH] net: qmi_wwan: Add SIMCom 7230E

[Kristian Evensen]

From: Kristian Evensen 

SIMCom 7230E is a QMI LTE module with support for most "normal" bands.
Manual testing has showed that only interface five works.

Cc: Bjørn Mork 
Signed-off-by: Kristian Evensen 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 5fccc5a..772b9d0 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -743,6 +743,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b1, 8)},/* Dell Wireless 5809e Gobi(TM) 
4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+ 
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
+   {QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question regarding {G,S}CHANNELS API

[Jakub Kicinski]

Hi!

I'm trying to understand how number of "separate" rx/tx vs combined
channels should be configured.  I'd like to express asymmetric but
mostly combined queue configuration (i.e. min(rx, tx) is combined the
rest is separate).  Since default number of RX queues is just 8 it is
tempting to allocate 8 RX queues but num_online_cpus() TX queues.  Does
this configuration make sense?  What should ethtool -l report?

I had a look through the drivers and it seems that most of them fall
nicely into the all combined and all separate categories. Two
exceptions I found are bnxt_en (recent Michael's changes) and tg3.
bnxt_en can switch between combined and separate mode.  tg3 is more
interesting, it uses separate rx/tx parameters but combines first
min(rx, tx) of the queues as I would like to.

The problem is if I hijack the "separate" rx/tx queues parameters like
tg3 does there is no way for the user to express that (s)he truly wants
them separate.  Also it seems that tg3 goes against the ethtool manual
which states:
>  rx N   Changes the number of channels with only receive queues.
>  tx N   Changes the number of channels with only transmit queues.
Which indicates that if user wants 8 rx, 12 tx and combining (s)he
should do:
  ethtool -L ethX combined 8 tx 4

This, however, makes the max_* info from SCHANNLES quite imprecise
since device which has 16 IRQs and 16 queues in each directions would
probably report:
max_rx:   16
max_tx:   16
max_combined: 16
But setting 'ethtool -L ethX combined 16 tx 8' would obviously
fail even though parameters are within 1..max limits.

Any comments/advice would be much appreciated.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH iproute2] tc: fix compilation with old gcc (< 4.6)

[Nicolas Dichtel]

Le 07/01/2016 14:56, Daniel Borkmann a écrit :

Btw, for iproute2's net-next branch there're couple of other occasions
as well. Stephen, how do you prefer to handle this? Should a separate
patch be done against net-next branch to reduce merge conflicts?

Thank you Daniel for noticing it.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 net-next 0/5] Local Checksum Offload

[Edward Cree]

Tested with a VXLAN tunnel over a device that doesn't support inner checksum
 offload (so the checksum will have been done in sw by validate_xmit_skb()).

Changes from v1:
 * Enabled support in more encapsulation protocols.
   I think it now covers everything except GRE.
 * Wrote up some documentation covering TX checksum offload, LCO and RCO.

Edward Cree (5):
  net: local checksum offload for encapsulation
  net: enable LCO for udp_tunnel_handle_offloads() users
  net: vxlan: enable local checksum offload
  fou: enable LCO in FOU and GUE
  Documentation/networking: add tx-offloads.txt to explain LCO

 Documentation/networking/00-INDEX|   2 +
 Documentation/networking/tx-offloads.txt | 122 +++
 drivers/net/vxlan.c  |   4 +-
 include/linux/skbuff.h   |  26 +++
 include/net/udp_tunnel.h |   3 +-
 net/ipv4/fou.c   |   5 +-
 net/ipv4/ip_tunnel_core.c|   4 +
 net/ipv4/udp.c   |  29 +++-
 net/ipv6/ip6_checksum.c  |  24 ++
 9 files changed, 178 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/networking/tx-offloads.txt

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 net-next 1/5] net: local checksum offload for encapsulation

[David Laight]

From: Edward Cree
> Sent: 07 January 2016 17:12
> The arithmetic properties of the ones-complement checksum mean that a
>  correctly checksummed inner packet, including its checksum, has a ones
>  complement sum depending only on whatever value was used to initialise
>  the checksum field before checksumming (in the case of TCP and UDP,
>  this is the ones complement sum of the pseudo header, complemented).
> Consequently, if we are going to offload the inner checksum with
>  CHECKSUM_PARTIAL, we can compute the outer checksum based only on the
>  packed data not covered by the inner checksum, and the initial value of
>  the inner checksum field.

Isn't it even simpler than that?
The checksum of the inner packet (including its header) is ~0 (ie 0).
So the checksum of the whole packet (for the outer header) is the same
as that of the packet down to the start of the inner header.

David

suspicious rcu_dereference in tcp_v6_send_synack

[Dave Jones]

===
[ INFO: suspicious RCU usage. ]
4.4.0-rc8-firewall+ #1 Not tainted
---
net/ipv6/tcp_ipv6.c:465 suspicious rcu_dereference_check() usage!

other info that might help us debug this:


rcu_scheduler_active = 1, debug_locks = 1
1 lock held by swapper/1/0:
 #0:  (((>rsk_timer))){+.-...}, at: [] 
call_timer_fn+0x5/0x3f0

stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.0-rc8-firewall+ #1
  8801d7a07b28 9948b3b5 8801d6046500
 8801d7a07b58 990e9b7a 8801cd356240 
 8801d23b1698 8801d23b0c40 8801d7a07ba8 99b635d2
Call Trace:
   [] dump_stack+0x4e/0x79
 [] lockdep_rcu_suspicious+0xea/0x110
 [] tcp_v6_send_synack+0x2c2/0x350
 [] tcp_rtx_synack+0xdd/0x180
 [] ? tcp_send_probe0+0x1a0/0x1a0
 [] reqsk_timer_handler+0x4c4/0x530
 [] ? inet_csk_reqsk_queue_drop+0x3a0/0x3a0
 [] ? __lock_is_held+0x9b/0xd0
 [] call_timer_fn+0x132/0x3f0
 [] ? call_timer_fn+0x5/0x3f0
 [] ? inet_csk_reqsk_queue_drop+0x3a0/0x3a0
 [] ? process_timeout+0x10/0x10
 [] ? trace_hardirqs_on_caller+0x192/0x2a0
 [] ? preempt_count_sub+0x1a/0x130
 [] run_timer_softirq+0x47b/0x590
 [] ? inet_csk_reqsk_queue_drop+0x3a0/0x3a0
 [] ? internal_add_timer+0x110/0x110
 [] ? __lock_is_held+0x28/0xd0
 [] __do_softirq+0x1b2/0x5c0
 [] irq_exit+0xfc/0x110
 [] smp_apic_timer_interrupt+0x5f/0x70
 [] apic_timer_interrupt+0x8b/0x90
   [] ? cpuidle_enter_state+0x1c7/0x460
 [] ? cpuidle_enter_state+0x1c2/0x460
 [] ? rcu_eqs_enter_common+0x139/0x280
 [] cpuidle_enter+0x17/0x20
 [] cpu_startup_entry+0x4d2/0x5b0
 [] ? default_idle_call+0x60/0x60
 [] ? clockevents_config_and_register+0x64/0x70
 [] ? setup_APIC_timer+0x115/0x120
 [] start_secondary+0x23a/0x2a0
 [] ? set_cpu_sibling_map+0x9c0/0x9c0

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html