1. 15 Jun, 2019 9 commits
    • Vlad Buslov's avatar
      net: sched: flower: don't call synchronize_rcu() on mask creation · 99815f50
      Vlad Buslov authored
      Current flower mask creating code assumes that temporary mask that is used
      when inserting new filter is stack allocated. To prevent race condition
      with data patch synchronize_rcu() is called every time fl_create_new_mask()
      replaces temporary stack allocated mask. As reported by Jiri, this
      increases runtime of creating 20000 flower classifiers from 4 seconds to
      163 seconds. However, this design is no longer necessary since temporary
      mask was converted to be dynamically allocated by commit 2cddd201
      ("net/sched: cls_flower: allocate mask dynamically in fl_change()").
      
      Remove synchronize_rcu() calls from mask creation code. Instead, refactor
      fl_change() to always deallocate temporary mask with rcu grace period.
      
      Fixes: 195c234d ("net: sched: flower: handle concurrent mask insertion")
      Reported-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarVlad Buslov <vladbu@mellanox.com>
      Tested-by: default avatarJiri Pirko <jiri@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99815f50
    • Anders Roxell's avatar
      net: dsa: fix warning same module names · f0c03ee0
      Anders Roxell authored
      When building with CONFIG_NET_DSA_REALTEK_SMI and CONFIG_REALTEK_PHY
      enabled as loadable modules, we see the following warning:
      
      warning: same module names found:
        drivers/net/phy/realtek.ko
        drivers/net/dsa/realtek.ko
      
      Rework so the driver name is realtek-smi instead of realtek.
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f0c03ee0
    • Neil Horman's avatar
      sctp: Free cookie before we memdup a new one · ce950f10
      Neil Horman authored
      Based on comments from Xin, even after fixes for our recent syzbot
      report of cookie memory leaks, its possible to get a resend of an INIT
      chunk which would lead to us leaking cookie memory.
      
      To ensure that we don't leak cookie memory, free any previously
      allocated cookie first.
      
      Change notes
      v1->v2
      update subsystem tag in subject (davem)
      repeat kfree check for peer_random and peer_hmacs (xin)
      
      v2->v3
      net->sctp
      also free peer_chunks
      
      v3->v4
      fix subject tags
      
      v4->v5
      remove cut line
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: syzbot+f7e9153b037eac9b1df8@syzkaller.appspotmail.com
      CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      CC: Xin Long <lucien.xin@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce950f10
    • Robert Hancock's avatar
      net: dsa: microchip: Don't try to read stats for unused ports · 6bb9e376
      Robert Hancock authored
      If some of the switch ports were not listed in the device tree, due to
      being unused, the ksz_mib_read_work function ended up accessing a NULL
      dp->slave pointer and causing an oops. Skip checking statistics for any
      unused ports.
      
      Fixes: 7c6ff470 ("net: dsa: microchip: add MIB counter reading support")
      Signed-off-by: default avatarRobert Hancock <hancock@sedsystems.ca>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6bb9e376
    • David S. Miller's avatar
      Merge branch 'qmi_wwan-fix-QMAP-handling' · 2309f517
      David S. Miller authored
      Reinhard Speyerer says:
      
      ====================
      qmi_wwan: fix QMAP handling
      
      This series addresses the following issues observed when using the
      QMAP support of the qmi_wwan driver:
      
      1. The QMAP code in the qmi_wwan driver is based on the CodeAurora
         GobiNet driver ([1], [2]) which does not process QMAP padding
         in the RX path correctly. This causes qmimux_rx_fixup() to pass
         incorrect data to the IP stack when padding is used.
      
      2. qmimux devices currently lack proper network device usage statistics.
      
      3. RCU stalls on device disconnect with QMAP activated like this
      
         # echo Y > /sys/class/net/wwan0/qmi/raw_ip
         # echo 1 > /sys/class/net/wwan0/qmi/add_mux
         # echo 2 > /sys/class/net/wwan0/qmi/add_mux
         # echo 3 > /sys/class/net/wwan0/qmi/add_mux
      
         have been observed in certain setups:
      
         [ 2273.676593] option1 ttyUSB16: GSM modem (1-port) converter now disconnected from ttyUSB16
         [ 2273.676617] option 6-1.2:1.0: device disconnected
         [ 2273.676774] WARNING: CPU: 1 PID: 141 at kernel/rcu/tree_plugin.h:342 rcu_note_context_switch+0x2a/0x3d0
         [ 2273.676776] Modules linked in: option qmi_wwan cdc_mbim cdc_ncm qcserial cdc_wdm usb_wwan sierra sierra_net usbnet mii edd coretemp iptable_mangle ip6_tables iptable_filter ip_tables cdc_acm dm_mod dax iTCO_wdt evdev iTCO_vendor_support sg ftdi_sio usbserial e1000e ptp pps_core i2c_i801 ehci_pci button lpc_ich i2c_core mfd_core uhci_hcd ehci_hcd rtc_cmos usbcore usb_common sd_mod fan ata_piix thermal
         [ 2273.676817] CPU: 1 PID: 141 Comm: kworker/1:1 Not tainted 4.19.38-rsp-1 #1
         [ 2273.676819] Hardware name: Not Applicable   Not Applicable  /CX-GS/GM45-GL40             , BIOS V1.11      03/23/2011
         [ 2273.676828] Workqueue: usb_hub_wq hub_event [usbcore]
         [ 2273.676832] EIP: rcu_note_context_switch+0x2a/0x3d0
         [ 2273.676834] Code: 55 89 e5 57 56 89 c6 53 83 ec 14 89 45 f0 e8 5d ff ff ff 89 f0 64 8b 3d 24 a6 86 c0 84 c0 8b 87 04 02 00 00 75 7a 85 c0 7e 7a <0f> 0b 80 bf 08 02 00 00 00 0f 84 87 00 00 00 e8 b2 e2 ff ff bb dc
         [ 2273.676836] EAX: 00000001 EBX: f614bc00 ECX: 00000001 EDX: c0715b81
         [ 2273.676838] ESI: 00000000 EDI: f18beb40 EBP: f1a3dc20 ESP: f1a3dc00
         [ 2273.676840] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010002
         [ 2273.676842] CR0: 80050033 CR2: b7e97230 CR3: 2f9c4000 CR4: 000406b0
         [ 2273.676843] Call Trace:
         [ 2273.676847]  ? preempt_count_add+0xa5/0xc0
         [ 2273.676852]  __schedule+0x4e/0x4f0
         [ 2273.676855]  ? __queue_work+0xf1/0x2a0
         [ 2273.676858]  ? _raw_spin_lock_irqsave+0x14/0x40
         [ 2273.676860]  ? preempt_count_add+0x52/0xc0
         [ 2273.676862]  schedule+0x33/0x80
         [ 2273.676865]  _synchronize_rcu_expedited+0x24e/0x280
         [ 2273.676867]  ? rcu_accelerate_cbs_unlocked+0x70/0x70
         [ 2273.676871]  ? wait_woken+0x70/0x70
         [ 2273.676873]  ? rcu_accelerate_cbs_unlocked+0x70/0x70
         [ 2273.676875]  ? _synchronize_rcu_expedited+0x280/0x280
         [ 2273.676877]  synchronize_rcu_expedited+0x22/0x30
         [ 2273.676881]  synchronize_net+0x25/0x30
         [ 2273.676885]  dev_deactivate_many+0x133/0x230
         [ 2273.676887]  ? preempt_count_add+0xa5/0xc0
         [ 2273.676890]  __dev_close_many+0x4d/0xc0
         [ 2273.676892]  ? skb_dequeue+0x40/0x50
         [ 2273.676895]  dev_close_many+0x5d/0xd0
         [ 2273.676898]  rollback_registered_many+0xbf/0x4c0
         [ 2273.676901]  ? raw_notifier_call_chain+0x1a/0x20
         [ 2273.676904]  ? call_netdevice_notifiers_info+0x23/0x60
         [ 2273.676906]  ? netdev_master_upper_dev_get+0xe/0x70
         [ 2273.676908]  rollback_registered+0x1f/0x30
         [ 2273.676911]  unregister_netdevice_queue+0x47/0xb0
         [ 2273.676915]  qmimux_unregister_device+0x1f/0x30 [qmi_wwan]
         [ 2273.676917]  qmi_wwan_disconnect+0x5d/0x90 [qmi_wwan]
         ...
         [ 2273.677001] ---[ end trace 0fcc5f88496b485a ]---
         [ 2294.679136] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
         [ 2294.679140] rcu: 	Tasks blocked on level-0 rcu_node (CPUs 0-1): P141
         [ 2294.679144] rcu: 	(detected by 0, t=21002 jiffies, g=265857, q=8446)
         [ 2294.679148] kworker/1:1     D    0   141      2 0x80000000
      
      In addition the permitted QMAP mux_id value range is extended for
      compatibility with ip(8) and the rmnet driver.
      
      Reinhard
      
      [1]: https://portland.source.codeaurora.org/patches/quic/gobi
      [2]: https://portland.source.codeaurora.org/quic/qsdk/oss/lklm/gobinet/
      ====================
      Tested-by: default avatarDaniele Palmas <dnlplm@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2309f517
    • Reinhard Speyerer's avatar
      qmi_wwan: extend permitted QMAP mux_id value range · 36815b41
      Reinhard Speyerer authored
      Permit mux_id values up to 254 to be used in qmimux_register_device()
      for compatibility with ip(8) and the rmnet driver.
      
      Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support")
      Cc: Daniele Palmas <dnlplm@gmail.com>
      Signed-off-by: default avatarReinhard Speyerer <rspmn@arcor.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      36815b41
    • Reinhard Speyerer's avatar
      qmi_wwan: avoid RCU stalls on device disconnect when in QMAP mode · a8fdde1c
      Reinhard Speyerer authored
      Switch qmimux_unregister_device() and qmi_wwan_disconnect() to
      use unregister_netdevice_queue() and unregister_netdevice_many()
      instead of unregister_netdevice(). This avoids RCU stalls which
      have been observed on device disconnect in certain setups otherwise.
      
      Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support")
      Cc: Daniele Palmas <dnlplm@gmail.com>
      Signed-off-by: default avatarReinhard Speyerer <rspmn@arcor.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8fdde1c
    • Reinhard Speyerer's avatar
      qmi_wwan: add network device usage statistics for qmimux devices · 44f82312
      Reinhard Speyerer authored
      Add proper network device usage statistics for qmimux devices
      instead of reporting all-zero values for them.
      
      Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support")
      Cc: Daniele Palmas <dnlplm@gmail.com>
      Signed-off-by: default avatarReinhard Speyerer <rspmn@arcor.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      44f82312
    • Reinhard Speyerer's avatar
      qmi_wwan: add support for QMAP padding in the RX path · 61356088
      Reinhard Speyerer authored
      The QMAP code in the qmi_wwan driver is based on the CodeAurora GobiNet
      driver which does not process QMAP padding in the RX path correctly.
      Add support for QMAP padding to qmimux_rx_fixup() according to the
      description of the rmnet driver.
      
      Fixes: c6adf779 ("net: usb: qmi_wwan: add qmap mux protocol support")
      Cc: Daniele Palmas <dnlplm@gmail.com>
      Signed-off-by: default avatarReinhard Speyerer <rspmn@arcor.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61356088
  2. 14 Jun, 2019 10 commits
  3. 12 Jun, 2019 16 commits
  4. 11 Jun, 2019 5 commits
    • David S. Miller's avatar
      Merge branch 'vxlan-geneve-linear' · 93c65f83
      David S. Miller authored
      Stefano Brivio says:
      
      ====================
      Don't assume linear buffers in error handlers for VXLAN and GENEVE
      
      Guillaume noticed the same issue fixed by commit 26fc181e ("fou, fou6:
      do not assume linear skbs") for fou and fou6 is also present in VXLAN and
      GENEVE error handlers: we can't assume linear buffers there, we need to
      use pskb_may_pull() instead.
      ====================
      Acked-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93c65f83
    • Stefano Brivio's avatar
      geneve: Don't assume linear buffers in error handler · eccc73a6
      Stefano Brivio authored
      In commit a0796644 ("geneve: ICMP error lookup handler") I wrongly
      assumed buffers from icmp_socket_deliver() would be linear. This is not
      the case: icmp_socket_deliver() only guarantees we have 8 bytes of linear
      data.
      
      Eric fixed this same issue for fou and fou6 in commits 26fc181e
      ("fou, fou6: do not assume linear skbs") and 5355ed63 ("fou, fou6:
      avoid uninit-value in gue_err() and gue6_err()").
      
      Use pskb_may_pull() instead of checking skb->len, and take into account
      the fact we later access the GENEVE header with udp_hdr(), so we also
      need to sum skb_transport_header() here.
      Reported-by: default avatarGuillaume Nault <gnault@redhat.com>
      Fixes: a0796644 ("geneve: ICMP error lookup handler")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eccc73a6
    • Stefano Brivio's avatar
      vxlan: Don't assume linear buffers in error handler · 8399a693
      Stefano Brivio authored
      In commit c3a43b9f ("vxlan: ICMP error lookup handler") I wrongly
      assumed buffers from icmp_socket_deliver() would be linear. This is not
      the case: icmp_socket_deliver() only guarantees we have 8 bytes of linear
      data.
      
      Eric fixed this same issue for fou and fou6 in commits 26fc181e
      ("fou, fou6: do not assume linear skbs") and 5355ed63 ("fou, fou6:
      avoid uninit-value in gue_err() and gue6_err()").
      
      Use pskb_may_pull() instead of checking skb->len, and take into account
      the fact we later access the VXLAN header with udp_hdr(), so we also
      need to sum skb_transport_header() here.
      Reported-by: default avatarGuillaume Nault <gnault@redhat.com>
      Fixes: c3a43b9f ("vxlan: ICMP error lookup handler")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8399a693
    • Taehee Yoo's avatar
      net: openvswitch: do not free vport if register_netdevice() is failed. · 309b6697
      Taehee Yoo authored
      In order to create an internal vport, internal_dev_create() is used and
      that calls register_netdevice() internally.
      If register_netdevice() fails, it calls dev->priv_destructor() to free
      private data of netdev. actually, a private data of this is a vport.
      
      Hence internal_dev_create() should not free and use a vport after failure
      of register_netdevice().
      
      Test command
          ovs-dpctl add-dp bonding_masters
      
      Splat looks like:
      [ 1035.667767] kasan: GPF could be caused by NULL-ptr deref or user memory access
      [ 1035.675958] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [ 1035.676916] CPU: 1 PID: 1028 Comm: ovs-vswitchd Tainted: G    B             5.2.0-rc3+ #240
      [ 1035.676916] RIP: 0010:internal_dev_create+0x2e5/0x4e0 [openvswitch]
      [ 1035.676916] Code: 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4c 8b 23 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 60 05 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 86 01 00 00 49 8b bc 24 60 05 00 00 e8 e4 68 f4
      [ 1035.713720] RSP: 0018:ffff88810dcb7578 EFLAGS: 00010206
      [ 1035.713720] RAX: dffffc0000000000 RBX: ffff88810d13fe08 RCX: ffffffff84297704
      [ 1035.713720] RDX: 00000000000000ac RSI: 0000000000000000 RDI: 0000000000000560
      [ 1035.713720] RBP: 00000000ffffffef R08: fffffbfff0d3b881 R09: fffffbfff0d3b881
      [ 1035.713720] R10: 0000000000000001 R11: fffffbfff0d3b880 R12: 0000000000000000
      [ 1035.768776] R13: 0000607ee460b900 R14: ffff88810dcb7690 R15: ffff88810dcb7698
      [ 1035.777709] FS:  00007f02095fc980(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000
      [ 1035.777709] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1035.777709] CR2: 00007ffdf01d2f28 CR3: 0000000108258000 CR4: 00000000001006e0
      [ 1035.777709] Call Trace:
      [ 1035.777709]  ovs_vport_add+0x267/0x4f0 [openvswitch]
      [ 1035.777709]  new_vport+0x15/0x1e0 [openvswitch]
      [ 1035.777709]  ovs_vport_cmd_new+0x567/0xd10 [openvswitch]
      [ 1035.777709]  ? ovs_dp_cmd_dump+0x490/0x490 [openvswitch]
      [ 1035.777709]  ? __kmalloc+0x131/0x2e0
      [ 1035.777709]  ? genl_family_rcv_msg+0xa54/0x1030
      [ 1035.777709]  genl_family_rcv_msg+0x63a/0x1030
      [ 1035.777709]  ? genl_unregister_family+0x630/0x630
      [ 1035.841681]  ? debug_show_all_locks+0x2d0/0x2d0
      [ ... ]
      
      Fixes: cf124db5 ("net: Fix inconsistent teardown and release of private netdev state.")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      309b6697
    • Willem de Bruijn's avatar
      net: correct udp zerocopy refcnt also when zerocopy only on append · 522924b5
      Willem de Bruijn authored
      The below patch fixes an incorrect zerocopy refcnt increment when
      appending with MSG_MORE to an existing zerocopy udp skb.
      
        send(.., MSG_ZEROCOPY | MSG_MORE);	// refcnt 1
        send(.., MSG_ZEROCOPY | MSG_MORE);	// refcnt still 1 (bar frags)
      
      But it missed that zerocopy need not be passed at the first send. The
      right test whether the uarg is newly allocated and thus has extra
      refcnt 1 is not !skb, but !skb_zcopy.
      
        send(.., MSG_MORE);			// <no uarg>
        send(.., MSG_ZEROCOPY);		// refcnt 1
      
      Fixes: 100f6d8e ("net: correct zerocopy refcnt with udp MSG_MORE")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      522924b5