1. Dec 04, 2018
    • Qian Cai's avatar
      net/core: tidy up an error message · bf29e9e9
      Qian Cai authored
      
      
      netif_napi_add() could report an error like this below due to it allows
      to pass a format string for wildcarding before calling
      dev_get_valid_name(),
      
      "netif_napi_add() called with weight 256 on device eth%d"
      
      For example, hns_enet_drv module does this.
      
      hns_nic_try_get_ae
        hns_nic_init_ring_data
          netif_napi_add
        register_netdev
          dev_get_valid_name
      
      Hence, make it a bit more human-readable by using netdev_err_once()
      instead.
      
      Signed-off-by: default avatarQian Cai <cai@gmx.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf29e9e9
    • Anderson Luiz Alves's avatar
      mv88e6060: disable hardware level MAC learning · a7451560
      Anderson Luiz Alves authored
      
      
      Disable hardware level MAC learning because it breaks station roaming.
      When enabled it drops all frames that arrive from a MAC address
      that is on a different port at learning table.
      
      Signed-off-by: default avatarAnderson Luiz Alves <alacn1@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7451560
    • Matteo Croce's avatar
      macvlan: return correct error value · 59f997b0
      Matteo Croce authored
      
      
      A MAC address must be unique among all the macvlan devices with the same
      lower device. The only exception is the passthru [sic] mode,
      which shares the lower device address.
      
      When duplicate addresses are detected, EBUSY is returned when bringing
      the interface up:
      
          # ip link add macvlan0 link eth0 type macvlan
          # read addr </sys/class/net/eth0/address
          # ip link set macvlan0 address $addr
          # ip link set macvlan0 up
          RTNETLINK answers: Device or resource busy
      
      Use correct error code which is EADDRINUSE, and do the check also
      earlier, on address change:
      
          # ip link set macvlan0 address $addr
          RTNETLINK answers: Address already in use
      
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59f997b0
    • Xin Long's avatar
      sctp: kfree_rcu asoc · fb6df5a6
      Xin Long authored
      In sctp_hash_transport/sctp_epaddr_lookup_transport, it dereferences
      a transport's asoc under rcu_read_lock while asoc is freed not after
      a grace period, which leads to a use-after-free panic.
      
      This patch fixes it by calling kfree_rcu to make asoc be freed after
      a grace period.
      
      Note that only the asoc's memory is delayed to free in the patch, it
      won't cause sk to linger longer.
      
      Thanks Neil and Marcelo to make this clear.
      
      Fixes: 7fda702f ("sctp: use new rhlist interface on sctp transport rhashtable")
      Fixes: cd2b7087
      
       ("sctp: check duplicate node before inserting a new transport")
      Reported-by: default avatar <syzbot+0b05d8aa7cb185107483@syzkaller.appspotmail.com>
      Reported-by: default avatar <syzbot+aad231d51b1923158444@syzkaller.appspotmail.com>
      Suggested-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb6df5a6
    • Thomas Falcon's avatar
      net/ibmvnic: Fix RTNL deadlock during device reset · 986103e7
      Thomas Falcon authored
      Commit a5681e20 ("net/ibmnvic: Fix deadlock problem
      in reset") made the change to hold the RTNL lock during
      driver reset but still calls netdev_notify_peers, which
      results in a deadlock. Instead, use call_netdevice_notifiers,
      which is functionally the same except that it does not
      take the RTNL lock again.
      
      Fixes: a5681e20
      
       ("net/ibmnvic: Fix deadlock problem in reset")
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      986103e7
    • Jean-Philippe Brucker's avatar
      vhost: fix IOTLB locking · e3f78718
      Jean-Philippe Brucker authored
      Commit 78139c94 ("net: vhost: lock the vqs one by one") moved the vq
      lock to improve scalability, but introduced a possible deadlock in
      vhost-iotlb. vhost_iotlb_notify_vq() now takes vq->mutex while holding
      the device's IOTLB spinlock. And on the vhost_iotlb_miss() path, the
      spinlock is taken while holding vq->mutex.
      
      Since calling vhost_poll_queue() doesn't require any lock, avoid the
      deadlock by not taking vq->mutex.
      
      Fixes: 78139c94
      
       ("net: vhost: lock the vqs one by one")
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3f78718
    • David S. Miller's avatar
      Merge branch 'phy-micrel-toggling-reset' · 4763c9f9
      David S. Miller authored
      
      
      Yoshihiro Shimoda says:
      
      ====================
      net: phy: micrel: add toggling phy reset
      
      This patch set is for R-Car Gen3 Salvator-XS boards. If we do
      the following method, the phy cannot link up correctly.
      
       1) Kernel boots by using initramfs.
       --> No open the nic, so phy_device_register() and phy_probe()
           deasserts the reset.
       2) Kernel enters the suspend.
       --> So, keep the reset signal as deassert.
       --> On R-Car Salvator-XS board, unfortunately, the board power is
           turned off.
       3) Kernel returns from suspend.
       4) ifconfig eth0 up
       --> Then, since edge signal of the reset doesn't happen,
           it cannot link up.
       5) ifconfig eth0 down
       6) ifconfig eth0 up
       --> In this case, it can link up.
      
      When resolving this issue after I got feedback from Andrew and Heiner,
      I found an issue that the phy_device.c didn't call phy_resume()
      if the PHY was not attached. So, patch 1 fixes it and add toggling
      the phy reset to the micrel phy driver.
      
      Changes from v1 (as RFC):
       - No remove the current code of phy_device.c to avoid any side effects.
       - Fix the mdio_bus_phy_resume() in phy_device.c.
       - Add toggling the phy reset in micrel.c if the PHY is not attached.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4763c9f9
    • Yoshihiro Shimoda's avatar
      net: phy: micrel: add toggling phy reset if PHY is not attached · 8c85f4b8
      Yoshihiro Shimoda authored
      
      
      This patch adds toggling phy reset if PHY is not attached. Otherwise,
      some boards (e.g. R-Car H3 Salvator-XS) cannot link up correctly if
      we do the following method:
      
       1) Kernel boots by using initramfs.
       --> No open the nic, so phy_device_register() and phy_probe()
           deasserts the reset.
       2) Kernel enters the suspend.
       --> So, keep the reset signal as deassert.
       --> On R-Car Salvator-XS board, unfortunately, the board power is
           turned off.
       3) Kernel returns from suspend.
       4) ifconfig eth0 up
       --> Then, since edge signal of the reset doesn't happen,
           it cannot link up.
       5) ifconfig eth0 down
       6) ifconfig eth0 up
       --> In this case, it can link up.
      
      Reported-by: default avatarHiromitsu Yamasaki <hiromitsu.yamasaki.ym@renesas.com>
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c85f4b8
    • Yoshihiro Shimoda's avatar
      net: phy: Fix not to call phy_resume() if PHY is not attached · ef1b5bf5
      Yoshihiro Shimoda authored
      This patch fixes an issue that mdio_bus_phy_resume() doesn't call
      phy_resume() if the PHY is not attached.
      
      Fixes: 803dd9c7
      
       ("net: phy: avoid suspending twice a PHY")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef1b5bf5
    • Prashant Bhole's avatar
      tun: remove skb access after netif_receive_skb · 4e4b08e5
      Prashant Bhole authored
      In tun.c skb->len was accessed while doing stats accounting after a
      call to netif_receive_skb. We can not access skb after this call
      because buffers may be dropped.
      
      The fix for this bug would be to store skb->len in local variable and
      then use it after netif_receive_skb(). IMO using xdp data size for
      accounting bytes will be better because input for tun_xdp_one() is
      xdp_buff.
      
      Hence this patch:
      - fixes a bug by removing skb access after netif_receive_skb()
      - uses xdp data size for accounting bytes
      
      [613.019057] BUG: KASAN: use-after-free in tun_sendmsg+0x77c/0xc50 [tun]
      [613.021062] Read of size 4 at addr ffff8881da9ab7c0 by task vhost-1115/1155
      [613.023073]
      [613.024003] CPU: 0 PID: 1155 Comm: vhost-1115 Not tainted 4.20.0-rc3-vm+ #232
      [613.026029] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [613.029116] Call Trace:
      [613.031145]  dump_stack+0x5b/0x90
      [613.032219]  print_address_description+0x6c/0x23c
      [613.034156]  ? tun_sendmsg+0x77c/0xc50 [tun]
      [613.036141]  kasan_report.cold.5+0x241/0x308
      [613.038125]  tun_sendmsg+0x77c/0xc50 [tun]
      [613.040109]  ? tun_get_user+0x1960/0x1960 [tun]
      [613.042094]  ? __isolate_free_page+0x270/0x270
      [613.045173]  vhost_tx_batch.isra.14+0xeb/0x1f0 [vhost_net]
      [613.047127]  ? peek_head_len.part.13+0x90/0x90 [vhost_net]
      [613.049096]  ? get_tx_bufs+0x5a/0x2c0 [vhost_net]
      [613.051106]  ? vhost_enable_notify+0x2d8/0x420 [vhost]
      [613.053139]  handle_tx_copy+0x2d0/0x8f0 [vhost_net]
      [613.053139]  ? vhost_net_buf_peek+0x340/0x340 [vhost_net]
      [613.053139]  ? __mutex_lock+0x8d9/0xb30
      [613.053139]  ? finish_task_switch+0x8f/0x3f0
      [613.053139]  ? handle_tx+0x32/0x120 [vhost_net]
      [613.053139]  ? mutex_trylock+0x110/0x110
      [613.053139]  ? finish_task_switch+0xcf/0x3f0
      [613.053139]  ? finish_task_switch+0x240/0x3f0
      [613.053139]  ? __switch_to_asm+0x34/0x70
      [613.053139]  ? __switch_to_asm+0x40/0x70
      [613.053139]  ? __schedule+0x506/0xf10
      [613.053139]  handle_tx+0xc7/0x120 [vhost_net]
      [613.053139]  vhost_worker+0x166/0x200 [vhost]
      [613.053139]  ? vhost_dev_init+0x580/0x580 [vhost]
      [613.053139]  ? __kthread_parkme+0x77/0x90
      [613.053139]  ? vhost_dev_init+0x580/0x580 [vhost]
      [613.053139]  kthread+0x1b1/0x1d0
      [613.053139]  ? kthread_park+0xb0/0xb0
      [613.053139]  ret_from_fork+0x35/0x40
      [613.088705]
      [613.088705] Allocated by task 1155:
      [613.088705]  kasan_kmalloc+0xbf/0xe0
      [613.088705]  kmem_cache_alloc+0xdc/0x220
      [613.088705]  __build_skb+0x2a/0x160
      [613.088705]  build_skb+0x14/0xc0
      [613.088705]  tun_sendmsg+0x4f0/0xc50 [tun]
      [613.088705]  vhost_tx_batch.isra.14+0xeb/0x1f0 [vhost_net]
      [613.088705]  handle_tx_copy+0x2d0/0x8f0 [vhost_net]
      [613.088705]  handle_tx+0xc7/0x120 [vhost_net]
      [613.088705]  vhost_worker+0x166/0x200 [vhost]
      [613.088705]  kthread+0x1b1/0x1d0
      [613.088705]  ret_from_fork+0x35/0x40
      [613.088705]
      [613.088705] Freed by task 1155:
      [613.088705]  __kasan_slab_free+0x12e/0x180
      [613.088705]  kmem_cache_free+0xa0/0x230
      [613.088705]  ip6_mc_input+0x40f/0x5a0
      [613.088705]  ipv6_rcv+0xc9/0x1e0
      [613.088705]  __netif_receive_skb_one_core+0xc1/0x100
      [613.088705]  netif_receive_skb_internal+0xc4/0x270
      [613.088705]  br_pass_frame_up+0x2b9/0x2e0
      [613.088705]  br_handle_frame_finish+0x2fb/0x7a0
      [613.088705]  br_handle_frame+0x30f/0x6c0
      [613.088705]  __netif_receive_skb_core+0x61a/0x15b0
      [613.088705]  __netif_receive_skb_one_core+0x8e/0x100
      [613.088705]  netif_receive_skb_internal+0xc4/0x270
      [613.088705]  tun_sendmsg+0x738/0xc50 [tun]
      [613.088705]  vhost_tx_batch.isra.14+0xeb/0x1f0 [vhost_net]
      [613.088705]  handle_tx_copy+0x2d0/0x8f0 [vhost_net]
      [613.088705]  handle_tx+0xc7/0x120 [vhost_net]
      [613.088705]  vhost_worker+0x166/0x200 [vhost]
      [613.088705]  kthread+0x1b1/0x1d0
      [613.088705]  ret_from_fork+0x35/0x40
      [613.088705]
      [613.088705] The buggy address belongs to the object at ffff8881da9ab740
      [613.088705]  which belongs to the cache skbuff_head_cache of size 232
      
      Fixes: 043d222f
      
       ("tuntap: accept an array of XDP buffs through sendmsg()")
      Reviewed-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e4b08e5
    • Su Yanjun's avatar
      net: 8139cp: fix a BUG triggered by changing mtu with network traffic · a5d4a892
      Su Yanjun authored
      When changing mtu many times with traffic, a bug is triggered:
      
      [ 1035.684037] kernel BUG at lib/dynamic_queue_limits.c:26!
      [ 1035.684042] invalid opcode: 0000 [#1] SMP
      [ 1035.684049] Modules linked in: loop binfmt_misc 8139cp(OE) macsec
      tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag tcp_lp
      fuse uinput xt_CHECKSUM iptable_mangle ipt_MASQUERADE
      nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
      nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun
      bridge stp llc ebtable_filter ebtables ip6table_filter devlink
      ip6_tables iptable_filter sunrpc snd_hda_codec_generic snd_hda_intel
      snd_hda_codec snd_hda_core snd_hwdep ppdev snd_seq iosf_mbi crc32_pclmul
      parport_pc snd_seq_device ghash_clmulni_intel parport snd_pcm
      aesni_intel joydev lrw snd_timer virtio_balloon sg gf128mul glue_helper
      ablk_helper cryptd snd soundcore i2c_piix4 pcspkr ip_tables xfs
      libcrc32c sr_mod sd_mod cdrom crc_t10dif crct10dif_generic ata_generic
      [ 1035.684102]  pata_acpi virtio_console qxl drm_kms_helper syscopyarea
      sysfillrect sysimgblt floppy fb_sys_fops crct10dif_pclmul
      crct10dif_common ttm crc32c_intel serio_raw ata_piix drm libata 8139too
      virtio_pci drm_panel_orientation_quirks virtio_ring virtio mii dm_mirror
      dm_region_hash dm_log dm_mod [last unloaded: 8139cp]
      [ 1035.684132] CPU: 9 PID: 25140 Comm: if-mtu-change Kdump: loaded
      Tainted: G           OE  ------------ T 3.10.0-957.el7.x86_64 #1
      [ 1035.684134] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      [ 1035.684136] task: ffff8f59b1f5a080 ti: ffff8f5a2e32c000 task.ti:
      ffff8f5a2e32c000
      [ 1035.684149] RIP: 0010:[<ffffffffba3a40d0>]  [<ffffffffba3a40d0>]
      dql_completed+0x180/0x190
      [ 1035.684162] RSP: 0000:ffff8f5a75483e50  EFLAGS: 00010093
      [ 1035.684162] RAX: 00000000000000c2 RBX: ffff8f5a6f91c000 RCX:
      0000000000000000
      [ 1035.684162] RDX: 0000000000000000 RSI: 0000000000000184 RDI:
      ffff8f599fea3ec0
      [ 1035.684162] RBP: ffff8f5a75483ea8 R08: 00000000000000c2 R09:
      0000000000000000
      [ 1035.684162] R10: 00000000000616ef R11: ffff8f5a75483b56 R12:
      ffff8f599fea3e00
      [ 1035.684162] R13: 0000000000000001 R14: 0000000000000000 R15:
      0000000000000184
      [ 1035.684162] FS:  00007fa8434de740(0000) GS:ffff8f5a75480000(0000)
      knlGS:0000000000000000
      [ 1035.684162] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1035.684162] CR2: 00000000004305d0 CR3: 000000024eb66000 CR4:
      00000000001406e0
      [ 1035.684162] Call Trace:
      [ 1035.684162]  <IRQ>
      [ 1035.684162]  [<ffffffffc08cbaf8>] ? cp_interrupt+0x478/0x580 [8139cp]
      [ 1035.684162]  [<ffffffffba14a294>]
      __handle_irq_event_percpu+0x44/0x1c0
      [ 1035.684162]  [<ffffffffba14a442>] handle_irq_event_percpu+0x32/0x80
      [ 1035.684162]  [<ffffffffba14a4cc>] handle_irq_event+0x3c/0x60
      [ 1035.684162]  [<ffffffffba14db29>] handle_fasteoi_irq+0x59/0x110
      [ 1035.684162]  [<ffffffffba02e554>] handle_irq+0xe4/0x1a0
      [ 1035.684162]  [<ffffffffba7795dd>] do_IRQ+0x4d/0xf0
      [ 1035.684162]  [<ffffffffba76b362>] common_interrupt+0x162/0x162
      [ 1035.684162]  <EOI>
      [ 1035.684162]  [<ffffffffba0c2ae4>] ? __wake_up_bit+0x24/0x70
      [ 1035.684162]  [<ffffffffba1e46f5>] ? do_set_pte+0xd5/0x120
      [ 1035.684162]  [<ffffffffba1b64fb>] unlock_page+0x2b/0x30
      [ 1035.684162]  [<ffffffffba1e4879>] do_read_fault.isra.61+0x139/0x1b0
      [ 1035.684162]  [<ffffffffba1e9134>] handle_pte_fault+0x2f4/0xd10
      [ 1035.684162]  [<ffffffffba1ebc6d>] handle_mm_fault+0x39d/0x9b0
      [ 1035.684162]  [<ffffffffba76f5e3>] __do_page_fault+0x203/0x500
      [ 1035.684162]  [<ffffffffba76f9c6>] trace_do_page_fault+0x56/0x150
      [ 1035.684162]  [<ffffffffba76ef42>] do_async_page_fault+0x22/0xf0
      [ 1035.684162]  [<ffffffffba76b788>] async_page_fault+0x28/0x30
      [ 1035.684162] Code: 54 c7 47 54 ff ff ff ff 44 0f 49 ce 48 8b 35 48 2f
      9c 00 48 89 77 58 e9 fe fe ff ff 0f 1f 80 00 00 00 00 41 89 d1 e9 ef fe
      ff ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 55 8d 42 ff 48
      [ 1035.684162] RIP  [<ffffffffba3a40d0>] dql_completed+0x180/0x190
      [ 1035.684162]  RSP <ffff8f5a75483e50>
      
      It's not the same as in 7fe0ee09
      
       patch described.
      As 8139cp uses shared irq mode, other device irq will trigger
      cp_interrupt to execute.
      
      cp_change_mtu
       -> cp_close
       -> cp_open
      
      In cp_close routine  just before free_irq(), some interrupt may occur.
      In my environment, cp_interrupt exectutes and IntrStatus is 0x4,
      exactly TxOk. That will cause cp_tx to wake device queue.
      
      As device queue is started, cp_start_xmit and cp_open will run at same
      time which will cause kernel BUG.
      
      For example:
      [#] for tx descriptor
      
      At start:
      
      [#][#][#]
      num_queued=3
      
      After cp_init_hw->cp_start_hw->netdev_reset_queue:
      
      [#][#][#]
      num_queued=0
      
      When 8139cp starts to work then cp_tx will check
      num_queued mismatchs the complete_bytes.
      
      The patch will check IntrMask before check IntrStatus in cp_interrupt.
      When 8139cp interrupt is disabled, just return.
      
      Signed-off-by: default avatarSu Yanjun <suyj.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5d4a892
    • Heiner Kallweit's avatar
      net: phy: don't allow __set_phy_supported to add unsupported modes · d2a36971
      Heiner Kallweit authored
      Currently __set_phy_supported allows to add modes w/o checking whether
      the PHY supports them. This is wrong, it should never add modes but
      only remove modes we don't want to support.
      
      The commit marked as fixed didn't do anything wrong, it just copied
      existing functionality to the helper which is being fixed now.
      
      Fixes: f3a6bd39
      
       ("phylib: Add phy_set_max_speed helper")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d2a36971
  2. Dec 01, 2018
  3. Nov 30, 2018
    • Christoph Paasch's avatar
      net: Prevent invalid access to skb->prev in __qdisc_drop_all · 9410d386
      Christoph Paasch authored
      __qdisc_drop_all() accesses skb->prev to get to the tail of the
      segment-list.
      
      With commit 68d2f84a ("net: gro: properly remove skb from list")
      the skb-list handling has been changed to set skb->next to NULL and set
      the list-poison on skb->prev.
      
      With that change, __qdisc_drop_all() will panic when it tries to
      dereference skb->prev.
      
      Since commit 992cba7e ("net: Add and use skb_list_del_init().")
      __list_del_entry is used, leaving skb->prev unchanged (thus,
      pointing to the list-head if it's the first skb of the list).
      This will make __qdisc_drop_all modify the next-pointer of the list-head
      and result in a panic later on:
      
      [   34.501053] general protection fault: 0000 [#1] SMP KASAN PTI
      [   34.501968] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.20.0-rc2.mptcp #108
      [   34.502887] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
      [   34.504074] RIP: 0010:dev_gro_receive+0x343/0x1f90
      [   34.504751] Code: e0 48 c1 e8 03 42 80 3c 30 00 0f 85 4a 1c 00 00 4d 8b 24 24 4c 39 65 d0 0f 84 0a 04 00 00 49 8d 7c 24 38 48 89 f8 48 c1 e8 03 <42> 0f b6 04 30 84 c0 74 08 3c 04
      [   34.507060] RSP: 0018:ffff8883af507930 EFLAGS: 00010202
      [   34.507761] RAX: 0000000000000007 RBX: ffff8883970b2c80 RCX: 1ffff11072e165a6
      [   34.508640] RDX: 1ffff11075867008 RSI: ffff8883ac338040 RDI: 0000000000000038
      [   34.509493] RBP: ffff8883af5079d0 R08: ffff8883970b2d40 R09: 0000000000000062
      [   34.510346] R10: 0000000000000034 R11: 0000000000000000 R12: 0000000000000000
      [   34.511215] R13: 0000000000000000 R14: dffffc0000000000 R15: ffff8883ac338008
      [   34.512082] FS:  0000000000000000(0000) GS:ffff8883af500000(0000) knlGS:0000000000000000
      [   34.513036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   34.513741] CR2: 000055ccc3e9d020 CR3: 00000003abf32000 CR4: 00000000000006e0
      [   34.514593] Call Trace:
      [   34.514893]  <IRQ>
      [   34.515157]  napi_gro_receive+0x93/0x150
      [   34.515632]  receive_buf+0x893/0x3700
      [   34.516094]  ? __netif_receive_skb+0x1f/0x1a0
      [   34.516629]  ? virtnet_probe+0x1b40/0x1b40
      [   34.517153]  ? __stable_node_chain+0x4d0/0x850
      [   34.517684]  ? kfree+0x9a/0x180
      [   34.518067]  ? __kasan_slab_free+0x171/0x190
      [   34.518582]  ? detach_buf+0x1df/0x650
      [   34.519061]  ? lapic_next_event+0x5a/0x90
      [   34.519539]  ? virtqueue_get_buf_ctx+0x280/0x7f0
      [   34.520093]  virtnet_poll+0x2df/0xd60
      [   34.520533]  ? receive_buf+0x3700/0x3700
      [   34.521027]  ? qdisc_watchdog_schedule_ns+0xd5/0x140
      [   34.521631]  ? htb_dequeue+0x1817/0x25f0
      [   34.522107]  ? sch_direct_xmit+0x142/0xf30
      [   34.522595]  ? virtqueue_napi_schedule+0x26/0x30
      [   34.523155]  net_rx_action+0x2f6/0xc50
      [   34.523601]  ? napi_complete_done+0x2f0/0x2f0
      [   34.524126]  ? kasan_check_read+0x11/0x20
      [   34.524608]  ? _raw_spin_lock+0x7d/0xd0
      [   34.525070]  ? _raw_spin_lock_bh+0xd0/0xd0
      [   34.525563]  ? kvm_guest_apic_eoi_write+0x6b/0x80
      [   34.526130]  ? apic_ack_irq+0x9e/0xe0
      [   34.526567]  __do_softirq+0x188/0x4b5
      [   34.527015]  irq_exit+0x151/0x180
      [   34.527417]  do_IRQ+0xdb/0x150
      [   34.527783]  common_interrupt+0xf/0xf
      [   34.528223]  </IRQ>
      
      This patch makes sure that skb->prev is set to NULL when entering
      netem_enqueue.
      
      Cc: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Fixes: 68d2f84a
      
       ("net: gro: properly remove skb from list")
      Suggested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9410d386
    • Martin Schiller's avatar
      net/x25: handle call collisions · b020fcf6
      Martin Schiller authored
      
      
      If a session in X25_STATE_1 (Awaiting Call Accept) receives a call
      request, the session will be closed (x25_disconnect), cause=0x01
      (Number Busy) and diag=0x48 (Call Collision) will be set and a clear
      request will be send.
      
      Signed-off-by: default avatarMartin Schiller <ms@dev.tdt.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b020fcf6
    • Martin Schiller's avatar
      net/x25: fix null_x25_address handling · 06137619
      Martin Schiller authored
      
      
      o x25_find_listener(): the compare for the null_x25_address was wrong.
         We have to check the x25_addr of the listener socket instead of the
         x25_addr of the incomming call.
      
       o x25_bind(): it was not possible to bind a socket to null_x25_address
      
      Signed-off-by: default avatarMartin Schiller <ms@dev.tdt.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06137619
    • Martin Schiller's avatar
      net/x25: fix called/calling length calculation in x25_parse_address_block · d449ba3d
      Martin Schiller authored
      
      
      The length of the called and calling address was not calculated
      correctly (BCD encoding).
      
      Signed-off-by: default avatarMartin Schiller <ms@dev.tdt.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d449ba3d
    • Baruch Siach's avatar
      net: phy: sfp: correct location of SFP standards · 90230968
      Baruch Siach authored
      
      
      SFP standards are now available from the SNIA (Storage Networking
      Industry Association) website.
      
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90230968
    • David S. Miller's avatar
      Merge branch 'xps-fixes' · e869e7b5
      David S. Miller authored
      
      
      Sabrina Dubroca says:
      
      ====================
      fixes for XPS configuration after Symmetric queue selection
      
      This fixes some bugs introduced by the "Symmetric queue selection
      using XPS for Rx queues".
      
      First, the refactoring of the cleanup function skipped resetting the
      queue's NUMA node under some conditions.
      
      Second, the accounting on static keys for XPS and RXQS-XPS is
      unbalanced, so the static key for XPS won't actually disable itself,
      once enabled. The RXQS-XPS static key can actually be disabled by
      reconfiguring a device that didn't have RXQS-XPS configured at all.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e869e7b5
    • Sabrina Dubroca's avatar
      net: fix XPS static_key accounting · 867d0ad4
      Sabrina Dubroca authored
      Commit 04157469 ("net: Use static_key for XPS maps") introduced a
      static key for XPS, but the increments/decrements don't match.
      
      First, the static key's counter is incremented once for each queue, but
      only decremented once for a whole batch of queues, leading to large
      unbalances.
      
      Second, the xps_rxqs_needed key is decremented whenever we reset a batch
      of queues, whether they had any rxqs mapping or not, so that if we setup
      cpu-XPS on em1 and RXQS-XPS on em2, resetting the queues on em1 would
      decrement the xps_rxqs_needed key.
      
      This reworks the accounting scheme so that the xps_needed key is
      incremented only once for each type of XPS for all the queues on a
      device, and the xps_rxqs_needed key is incremented only once for all
      queues. This is sufficient to let us retrieve queues via
      get_xps_queue().
      
      This patch introduces a new reset_xps_maps(), which reinitializes and
      frees the appropriate map (xps_rxqs_map or xps_cpus_map), and drops a
      reference to the needed keys:
       - both xps_needed and xps_rxqs_needed, in case of rxqs maps,
       - only xps_needed, in case of CPU maps.
      
      Now, we also need to call reset_xps_maps() at the end of
      __netif_set_xps_queue() when there's no active map left, for example
      when writing '00000000,00000000' to all queues' xps_rxqs setting.
      
      Fixes: 04157469
      
       ("net: Use static_key for XPS maps")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      867d0ad4
    • Sabrina Dubroca's avatar
      net: restore call to netdev_queue_numa_node_write when resetting XPS · f28c020f
      Sabrina Dubroca authored
      Before commit 80d19669 ("net: Refactor XPS for CPUs and Rx queues"),
      netif_reset_xps_queues() did netdev_queue_numa_node_write() for all the
      queues being reset. Now, this is only done when the "active" variable in
      clean_xps_maps() is false, ie when on all the CPUs, there's no active
      XPS mapping left.
      
      Fixes: 80d19669
      
       ("net: Refactor XPS for CPUs and Rx queues")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f28c020f
    • Baruch Siach's avatar
      net: phy: sfp: correct store of detected link modes · d7f7e001
      Baruch Siach authored
      The link modes that sfp_parse_support() detects are stored in the
      'modes' bitmap. There is no reason to make an exception for 1000Base-PX
      or 1000Base-BX10.
      
      Fixes: 03145864
      
       ("sfp: support 1G BiDi (eg, FiberStore SFP-GE-BX) modules")
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7f7e001
    • David S. Miller's avatar
      Merge branch 'ave-fixes' · f1c0f591
      David S. Miller authored
      
      
      Kunihiko Hayashi says:
      
      ====================
      fixup AVE ethernet driver
      
      This series adds fixup for AVE ethernet driver that includes increse of
      descriptors, replacing macro for linux-next, and adding missing author
      information.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1c0f591