1. 21 Mar, 2019 5 commits
  2. 20 Mar, 2019 12 commits
    • Ioana Ciocoi Radulescu's avatar
      dpaa2-eth: Fix possible access beyond end of array · 64447506
      Ioana Ciocoi Radulescu authored
      Make sure we don't try to enqueue XDP_REDIRECT frames to an
      inexistent FQ.
      
      While it is guaranteed not to have more than one queue per core,
      having fewer queues than CPUs on an interface is a valid
      configuration.
      
      Fixes: d678be1d ("dpaa2-eth: add XDP_REDIRECT support")
      Reported-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarIoana Radulescu <ruxandra.radulescu@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64447506
    • David S. Miller's avatar
      Merge branch 'ks8851-fixes' · cb8075d9
      David S. Miller authored
      Lukas Wunner says:
      
      ====================
      ks8851 fixes & cleanups
      
      Four fixes and two cleanups for the Microchip (formerly Micrel) KSZ8851
      SPI Ethernet driver.
      
      Some of the fixes might even pass as stable material, but I haven't marked
      them as such for cautiousness: Doesn't hurt letting them bake in linux-next
      for a few weeks to raise the confidence, even though we've tested them
      extensively on our Revolution Pi open source PLCs.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb8075d9
    • Lukas Wunner's avatar
      net: ks8851: Deduplicate register macros · aae079aa
      Lukas Wunner authored
      The ks8851 chip is sold either with an SPI interface (KSZ8851SNL) or
      with a so-called non-PCI interface (KSZ8851-16MLL).  When the driver
      for the latter was introduced with commit a55c0a0e ("drivers/net:
      ks8851_mll ethernet network driver"), it duplicated the register macros
      introduced by the driver for the former with commit 3ba81f3e ("net:
      Micrel KS8851 SPI network driver").
      
      The chips are almost identical, so the duplication seems unwarranted.
      There are a handful of bits which are in use on the KSZ8851-16MLL but
      reserved on the KSZ8851SNL, and vice-versa, but there are no actual
      collisions.
      
      Thus, remove the duplicate definitions from the KSZ8851-16MLL driver.
      Mark all bits which differ between the two chips.  Move the SPI frame
      opcodes, which are specific to KSZ8851SNL, to its driver.
      
      The KSZ8851-16MLL driver added a RXFCTR_THRESHOLD_MASK macro which is a
      duplication of the RXFCTR_RXFCT_MASK macro, rename it where it's used.
      Same for P1MBCR_FORCE_FDX, which duplicates the BMCR_FULLDPLX macro and
      OBCR_ODS_16MA, which duplicates OBCR_ODS_16mA.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aae079aa
    • Lukas Wunner's avatar
      net: ks8851: Fix register macro misnomers · cbda74a1
      Lukas Wunner authored
      In the header file accompanying the ks8851 driver, the P1SCLMD register
      macros are misnamed, they actually pertain to the P1CR register.
      
      The P1CR macros in turn pertain to the P1SR register, see pages 65 to 68
      of the spec:
      http://www.hqchip.com/uploads/pdf/201703/47c98946d6c97a4766e14db3f24955f2.pdf
      
      The misnomers have no negative consequences so far because the macros
      aren't used by ks8851.c, but that's about to change.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cbda74a1
    • Lukas Wunner's avatar
      net: ks8851: Set initial carrier state to down · 9624bafa
      Lukas Wunner authored
      The ks8851 chip's initial carrier state is down. A Link Change Interrupt
      is signaled once interrupts are enabled if the carrier is up.
      
      The ks8851 driver has it backwards by assuming that the initial carrier
      state is up. The state is therefore misrepresented if the interface is
      opened with no cable attached. Fix it.
      
      The Link Change interrupt is sometimes not signaled unless the P1MBSR
      register (which contains the Link Status bit) is read on ->ndo_open().
      This might be a hardware erratum. Read the register by calling
      mii_check_link(), which has the desirable side effect of setting the
      carrier state to down if the cable was detached while the interface was
      closed.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9624bafa
    • Lukas Wunner's avatar
      net: ks8851: Delay requesting IRQ until opened · d268f315
      Lukas Wunner authored
      The ks8851 driver currently requests the IRQ before registering the
      net_device.  Because the net_device name is used as IRQ name and is
      still "eth%d" when the IRQ is requested, it's impossibe to tell IRQs
      apart if multiple ks8851 chips are present.  Most other drivers delay
      requesting the IRQ until the net_device is opened.  Do the same.
      
      The driver doesn't enable interrupts on the chip before opening the
      net_device and disables them when closing it, so there doesn't seem to
      be a need to request the IRQ already on probe.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d268f315
    • Lukas Wunner's avatar
      net: ks8851: Reassert reset pin if chip ID check fails · 761cfa97
      Lukas Wunner authored
      Commit 73fdeb82 ("net: ks8851: Add optional vdd_io regulator and
      reset gpio") amended the ks8851 driver to briefly assert the chip's
      reset pin on probe. It also amended the probe routine's error path to
      reassert the reset pin if a subsequent initialization step fails.
      
      However the commit misplaced reassertion of the reset pin in the error
      path such that it is not performed if the check of the Chip ID and
      Enable Register (CIDER) fails. The error path is therefore slightly
      asymmetrical to the probe routine's body. Fix it.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      761cfa97
    • Lukas Wunner's avatar
      net: ks8851: Dequeue RX packets explicitly · 536d3680
      Lukas Wunner authored
      The ks8851 driver lets the chip auto-dequeue received packets once they
      have been read in full. It achieves that by setting the ADRFE flag in
      the RXQCR register ("Auto-Dequeue RXQ Frame Enable").
      
      However if allocation of a packet's socket buffer or retrieval of the
      packet over the SPI bus fails, the packet will not have been read in
      full and is not auto-dequeued. Such partial retrieval of a packet
      confuses the chip's RX queue management:  On the next RX interrupt,
      the first packet read from the queue will be the one left there
      previously and this one can be retrieved without issues. But for any
      newly received packets, the frame header status and byte count registers
      (RXFHSR and RXFHBCR) contain bogus values, preventing their retrieval.
      
      The chip allows explicitly dequeueing a packet from the RX queue by
      setting the RRXEF flag in the RXQCR register ("Release RX Error Frame").
      This could be used to dequeue the packet in case of an error, but if
      that error is a failed SPI transfer, it is unknown if the packet was
      transferred in full and was auto-dequeued or if it was only transferred
      in part and requires an explicit dequeue. The safest approach is thus
      to always dequeue packets explicitly and forgo auto-dequeueing.
      
      Without this change, I've witnessed packet retrieval break completely
      when an SPI DMA transfer fails, requiring a chip reset. Explicit
      dequeueing magically fixes this and makes packet retrieval absolutely
      robust for me.
      
      The chip's documentation suggests auto-dequeuing and uses the RRXEF
      flag only to dequeue error frames which the driver doesn't want to
      retrieve. But that seems to be a fair-weather approach.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      536d3680
    • Xin Long's avatar
      sctp: use memdup_user instead of vmemdup_user · ef82bcfa
      Xin Long authored
      In sctp_setsockopt_bindx()/__sctp_setsockopt_connectx(), it allocates
      memory with addrs_size which is passed from userspace. We used flag
      GFP_USER to put some more restrictions on it in Commit cacc0621
      ("sctp: use GFP_USER for user-controlled kmalloc").
      
      However, since Commit c981f254 ("sctp: use vmemdup_user() rather
      than badly open-coding memdup_user()"), vmemdup_user() has been used,
      which doesn't check GFP_USER flag when goes to vmalloc_*(). So when
      addrs_size is a huge value, it could exhaust memory and even trigger
      oom killer.
      
      This patch is to use memdup_user() instead, in which GFP_USER would
      work to limit the memory allocation with a huge addrs_size.
      
      Note we can't fix it by limiting 'addrs_size', as there's no demand
      for it from RFC.
      
      Reported-by: syzbot+ec1b7575afef85a0e5ca@syzkaller.appspotmail.com
      Fixes: c981f254 ("sctp: use vmemdup_user() rather than badly open-coding memdup_user()")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef82bcfa
    • Xin Long's avatar
      ipv6: make ip6_create_rt_rcu return ip6_null_entry instead of NULL · 1c87e79a
      Xin Long authored
      Jianlin reported a crash:
      
        [  381.484332] BUG: unable to handle kernel NULL pointer dereference at 0000000000000068
        [  381.619802] RIP: 0010:fib6_rule_lookup+0xa3/0x160
        [  382.009615] Call Trace:
        [  382.020762]  <IRQ>
        [  382.030174]  ip6_route_redirect.isra.52+0xc9/0xf0
        [  382.050984]  ip6_redirect+0xb6/0xf0
        [  382.066731]  icmpv6_notify+0xca/0x190
        [  382.083185]  ndisc_redirect_rcv+0x10f/0x160
        [  382.102569]  ndisc_rcv+0xfb/0x100
        [  382.117725]  icmpv6_rcv+0x3f2/0x520
        [  382.133637]  ip6_input_finish+0xbf/0x460
        [  382.151634]  ip6_input+0x3b/0xb0
        [  382.166097]  ipv6_rcv+0x378/0x4e0
      
      It was caused by the lookup function __ip6_route_redirect() returns NULL in
      fib6_rule_lookup() when ip6_create_rt_rcu() returns NULL.
      
      So we fix it by simply making ip6_create_rt_rcu() return ip6_null_entry
      instead of NULL.
      
      v1->v2:
        - move down 'fallback:' to make it more readable.
      
      Fixes: e873e4b9 ("ipv6: use fib6_info_hold_safe() when necessary")
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Suggested-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Acked-by: default avatarWei Wang <weiwan@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c87e79a
    • Christoph Paasch's avatar
      net/packet: Set __GFP_NOWARN upon allocation in alloc_pg_vec · 398f0132
      Christoph Paasch authored
      Since commit fc62814d ("net/packet: fix 4gb buffer limit due to overflow check")
      one can now allocate packet ring buffers >= UINT_MAX. However, syzkaller
      found that that triggers a warning:
      
      [   21.100000] WARNING: CPU: 2 PID: 2075 at mm/page_alloc.c:4584 __alloc_pages_nod0
      [   21.101490] Modules linked in:
      [   21.101921] CPU: 2 PID: 2075 Comm: syz-executor.0 Not tainted 5.0.0 #146
      [   21.102784] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
      [   21.103887] RIP: 0010:__alloc_pages_nodemask+0x2a0/0x630
      [   21.104640] Code: fe ff ff 65 48 8b 04 25 c0 de 01 00 48 05 90 0f 00 00 41 bd 01 00 00 00 48 89 44 24 48 e9 9c fe 3
      [   21.107121] RSP: 0018:ffff88805e1cf920 EFLAGS: 00010246
      [   21.107819] RAX: 0000000000000000 RBX: ffffffff85a488a0 RCX: 0000000000000000
      [   21.108753] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000000
      [   21.109699] RBP: 1ffff1100bc39f28 R08: ffffed100bcefb67 R09: ffffed100bcefb67
      [   21.110646] R10: 0000000000000001 R11: ffffed100bcefb66 R12: 000000000000000d
      [   21.111623] R13: 0000000000000000 R14: ffff88805e77d888 R15: 000000000000000d
      [   21.112552] FS:  00007f7c7de05700(0000) GS:ffff88806d100000(0000) knlGS:0000000000000000
      [   21.113612] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   21.114405] CR2: 000000000065c000 CR3: 000000005e58e006 CR4: 00000000001606e0
      [   21.115367] Call Trace:
      [   21.115705]  ? __alloc_pages_slowpath+0x21c0/0x21c0
      [   21.116362]  alloc_pages_current+0xac/0x1e0
      [   21.116923]  kmalloc_order+0x18/0x70
      [   21.117393]  kmalloc_order_trace+0x18/0x110
      [   21.117949]  packet_set_ring+0x9d5/0x1770
      [   21.118524]  ? packet_rcv_spkt+0x440/0x440
      [   21.119094]  ? lock_downgrade+0x620/0x620
      [   21.119646]  ? __might_fault+0x177/0x1b0
      [   21.120177]  packet_setsockopt+0x981/0x2940
      [   21.120753]  ? __fget+0x2fb/0x4b0
      [   21.121209]  ? packet_release+0xab0/0xab0
      [   21.121740]  ? sock_has_perm+0x1cd/0x260
      [   21.122297]  ? selinux_secmark_relabel_packet+0xd0/0xd0
      [   21.123013]  ? __fget+0x324/0x4b0
      [   21.123451]  ? selinux_netlbl_socket_setsockopt+0x101/0x320
      [   21.124186]  ? selinux_netlbl_sock_rcv_skb+0x3a0/0x3a0
      [   21.124908]  ? __lock_acquire+0x529/0x3200
      [   21.125453]  ? selinux_socket_setsockopt+0x5d/0x70
      [   21.126075]  ? __sys_setsockopt+0x131/0x210
      [   21.126533]  ? packet_release+0xab0/0xab0
      [   21.127004]  __sys_setsockopt+0x131/0x210
      [   21.127449]  ? kernel_accept+0x2f0/0x2f0
      [   21.127911]  ? ret_from_fork+0x8/0x50
      [   21.128313]  ? do_raw_spin_lock+0x11b/0x280
      [   21.128800]  __x64_sys_setsockopt+0xba/0x150
      [   21.129271]  ? lockdep_hardirqs_on+0x37f/0x560
      [   21.129769]  do_syscall_64+0x9f/0x450
      [   21.130182]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      We should allocate with __GFP_NOWARN to handle this.
      
      Cc: Kal Conley <kal.conley@dectris.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Fixes: fc62814d ("net/packet: fix 4gb buffer limit due to overflow check")
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      398f0132
    • Taehee Yoo's avatar
      netfilter: nf_tables: add missing ->release_ops() in error path of newrule() · b25a31bf
      Taehee Yoo authored
      ->release_ops() callback releases resources and this is used in error path.
      If nf_tables_newrule() fails after ->select_ops(), it should release
      resources. but it can not call ->destroy() because that should be called
      after ->init().
      At this point, ->release_ops() should be used for releasing resources.
      
      Test commands:
         modprobe -rv xt_tcpudp
         iptables-nft -I INPUT -m tcp   <-- error command
         lsmod
      
      Result:
         Module                  Size  Used by
         xt_tcpudp              20480  2      <-- it should be 0
      
      Fixes: b8e20400 ("netfilter: nft_compat: use .release_ops and remove list of extension")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      b25a31bf
  3. 19 Mar, 2019 23 commits
    • Vinay K Nallamothu's avatar
      mpls: Fix 6PE forwarding · f84532ce
      Vinay K Nallamothu authored
      This patch adds support for 6PE (RFC 4798) which uses IPv4-mapped IPv6
      nexthop to connect IPv6 islands over IPv4 only MPLS network core.
      
      Prior to this fix, to find the link-layer destination mac address, 6PE
      enabled host/router was sending IPv6 ND requests for IPv4-mapped IPv6
      nexthop address over the interface facing the IPv4 only core which
      wouldn't success as the core is IPv6 free.
      
      This fix changes that behavior on 6PE host to treat the nexthop as IPv4
      address and send ARP requests whenever the next-hop address is an
      IPv4-mapped IPv6 address.
      
      Below topology illustrates the issue and how the patch addresses it.
      
      abcd::1.1.1.1 (lo)                                              abcd::2.2.2.2 (lo)
      R0 (PE/host)------------------------R1--------------------------------R2 (PE/host)
                  <--- IPv4 MPLS core --->   <------ IPv4 MPLS core -------->
                 eth1               eth2       eth3                       eth4
                172.18.0.10     172.18.0.11   172.19.0.11              172.19.0.12
          ffff::172.18.0.10                                      ffff::172.19.0.12
                  <------------------IPv6 MPLS tunnel ---------------------->
      
      R0 and R2 act as 6PE routers of IPv6 islands. R1 is IPv4 only with MPLS tunnels
      between R0,R1 and R1,R2.
      
       docker exec r0 ip -f inet6 route add abcd::2.2.2.2/128 nexthop encap mpls 100 via ::ffff:172.18.0.11 dev eth1
       docker exec r2 ip -f inet6 route add abcd::1.1.1.1/128 nexthop encap mpls 200 via ::ffff:172.19.0.11 dev eth4
      
       docker exec r1 ip -f mpls route add 100 via inet 172.19.0.12 dev eth3
       docker exec r1 ip -f mpls route add 200 via inet 172.18.0.10 dev eth2
      
      With the change, when R0 sends an IPv6 packet over MPLS tunnel to abcd::2.2.2.2,
      using ::ffff:172.18.0.11 as the nexthop, it does neighbor discovery for
      172.18.18.0.11.
      Signed-off-by: default avatarVinay K Nallamothu <nvinay@juniper.net>
      Tested-by: default avatarAvinash Lingala <ar977m@att.com>
      Tested-by: default avatarAravind Srinivas Srinivasa Prabhakar <aprabh@juniper.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f84532ce
    • Arnd Bergmann's avatar
      3c515: fix integer overflow warning · fb6fafbc
      Arnd Bergmann authored
      clang points out a harmless signed integer overflow:
      
      drivers/net/ethernet/3com/3c515.c:1530:66: error: implicit conversion from 'int' to 'short' changes value from 32783 to -32753 [-Werror,-Wconstant-conversion]
                      new_mode = SetRxFilter | RxStation | RxMulticast | RxBroadcast | RxProm;
                               ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      drivers/net/ethernet/3com/3c515.c:1532:52: error: implicit conversion from 'int' to 'short' changes value from 32775 to -32761 [-Werror,-Wconstant-conversion]
                      new_mode = SetRxFilter | RxStation | RxMulticast | RxBroadcast;
                               ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
      drivers/net/ethernet/3com/3c515.c:1534:38: error: implicit conversion from 'int' to 'short' changes value from 32773 to -32763 [-Werror,-Wconstant-conversion]
                      new_mode = SetRxFilter | RxStation | RxBroadcast;
                               ~ ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
      
      Make the variable unsigned to avoid the overflow.
      
      Fixes: Linux-2.1.128pre1
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb6fafbc
    • Eric Dumazet's avatar
      dccp: do not use ipv6 header for ipv4 flow · e0aa6770
      Eric Dumazet authored
      When a dual stack dccp listener accepts an ipv4 flow,
      it should not attempt to use an ipv6 header or
      inet6_iif() helper.
      
      Fixes: 3df80d93 ("[DCCP]: Introduce DCCPv6")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0aa6770
    • Eric Dumazet's avatar
      tcp: do not use ipv6 header for ipv4 flow · 89e41309
      Eric Dumazet authored
      When a dual stack tcp listener accepts an ipv4 flow,
      it should not attempt to use an ipv6 header or tcp_v6_iif() helper.
      
      Fixes: 1397ed35 ("ipv6: add flowinfo for tcp6 pkt_options for all cases")
      Fixes: df3687ff ("ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89e41309
    • Aditya Pakki's avatar
      nfc: Fix to check for kmemdup failure · d7737d42
      Aditya Pakki authored
      In case of kmemdup failure while setting the service name the patch
      returns -ENOMEM upstream for processing.
      Signed-off-by: default avatarAditya Pakki <pakki001@umn.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7737d42
    • YueHaibing's avatar
      net-sysfs: call dev_hold if kobject_init_and_add success · a3e23f71
      YueHaibing authored
      In netdev_queue_add_kobject and rx_queue_add_kobject,
      if sysfs_create_group failed, kobject_put will call
      netdev_queue_release to decrease dev refcont, however
      dev_hold has not be called. So we will see this while
      unregistering dev:
      
      unregister_netdevice: waiting for bcsh0 to become free. Usage count = -1
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: d0d66837 ("net: don't decrement kobj reference count on init failure")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a3e23f71
    • Aaro Koskinen's avatar
      net: stmmac: fix memory corruption with large MTUs · 223a960c
      Aaro Koskinen authored
      When using 16K DMA buffers and ring mode, the DES3 refill is not working
      correctly as the function is using a bogus pointer for checking the
      private data. As a result stale pointers will remain in the RX descriptor
      ring, so DMA will now likely overwrite/corrupt some already freed memory.
      
      As simple reproducer, just receive some UDP traffic:
      
      	# ifconfig eth0 down; ifconfig eth0 mtu 9000; ifconfig eth0 up
      	# iperf3 -c 192.168.253.40 -u -b 0 -R
      
      If you didn't crash by now check the RX descriptors to find non-contiguous
      RX buffers:
      
      	cat /sys/kernel/debug/stmmaceth/eth0/descriptors_status
      	[...]
      	1 [0x2be5020]: 0xa3220321 0x9ffc1ffc 0x72d70082 0x130e207e
      					     ^^^^^^^^^^^^^^^^^^^^^
      	2 [0x2be5040]: 0xa3220321 0x9ffc1ffc 0x72998082 0x1311a07e
      					     ^^^^^^^^^^^^^^^^^^^^^
      
      A simple ping test will now report bad data:
      
      	# ping -s 8200 192.168.253.40
      	PING 192.168.253.40 (192.168.253.40) 8200(8228) bytes of data.
      	8208 bytes from 192.168.253.40: icmp_seq=1 ttl=64 time=1.00 ms
      	wrong data byte #8144 should be 0xd0 but was 0x88
      
      Fix the wrong pointer. Also we must refill DES3 only if the DMA buffer
      size is 16K.
      
      Fixes: 54139cf3 ("net: stmmac: adding multiple buffers for rx")
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Acked-by: default avatarJose Abreu <joabreu@synopsys.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      223a960c
    • Arnd Bergmann's avatar
      mlxsw: core: mlxsw: core: avoid -Wint-in-bool-context warning · 7442c483
      Arnd Bergmann authored
      A recently added function in mlxsw triggers a harmless compiler warning:
      
      In file included from drivers/net/ethernet/mellanox/mlxsw/core.h:17,
                       from drivers/net/ethernet/mellanox/mlxsw/core_env.c:7:
      drivers/net/ethernet/mellanox/mlxsw/core_env.c: In function 'mlxsw_env_module_temp_thresholds_get':
      drivers/net/ethernet/mellanox/mlxsw/reg.h:8015:45: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context]
       #define MLXSW_REG_MTMP_TEMP_TO_MC(val) (val * 125)
                                              ~~~~~^~~~~~
      drivers/net/ethernet/mellanox/mlxsw/core_env.c:116:8: note: in expansion of macro 'MLXSW_REG_MTMP_TEMP_TO_MC'
         if (!MLXSW_REG_MTMP_TEMP_TO_MC(module_temp)) {
              ^~~~~~~~~~~~~~~~~~~~~~~~~
      
      The warning is normally disabled, but it would be nice to enable
      it to find real bugs, and there are no other known instances at
      the moment.
      
      Replace the negation with a zero-comparison, which also matches
      the comment above it.
      
      Fixes: d93c19a1 ("mlxsw: core: Add API for QSFP module temperature thresholds reading")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7442c483
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2019-03-19' of... · 22781f07
      David S. Miller authored
      Merge tag 'wireless-drivers-for-davem-2019-03-19' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 5.1
      
      First set of fixes for 5.1. Lots of fixes for mt76 this time.
      
      iwlwifi
      
      * fix warning with do_div()
      
      mt7601u
      
      * avoid using hardware which is supported by mt76
      
      mt76
      
      * more fixes for hweight8() usage
      
      * fix hardware restart for mt76x2
      
      * fix writing txwi on USB devices
      
      * fix (and disable by default) ED/CCA support on 76x2
      
      * fix powersave issues on 7603
      
      * fix return value check for ioremap on 7603
      
      * fix duplicate USB device IDs
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22781f07
    • David S. Miller's avatar
      Merge branch 'ieee802154-for-davem-2019-03-19' of... · e8629d29
      David S. Miller authored
      Merge branch 'ieee802154-for-davem-2019-03-19' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan
      
      Stefan Schmidt says:
      
      ====================
      pull-request: ieee802154 for net 2019-03-19
      
      An update from ieee802154 for your *net* tree.
      
      Kangjie Lu fixed a potential NULL pointer deref in the adf7242 driver and Li
      RongQing make sure we propagate a netlink return code to the caller.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8629d29
    • Stanislaw Gruszka's avatar
      mt76x02: do not enable RTS/CTS by default · 7dfc45e6
      Stanislaw Gruszka authored
      My commit 26a7b547 ("mt76x02: set protection according to ht
      operation element") enabled by default RTS/CTS protection for OFDM
      and CCK traffic, because MT_TX_RTS_CFG_THRESH is configured to non
      0xffff by initvals and .set_rts_threshold callback is not called by
      mac80211 on initialization, only on user request or during
      ieee80211_reconfig() (suspend/resuem or restart_hw).
      
      Enabling RTS/CTS cause some problems when sending probe request
      frames by hcxdumptool penetration tool, but I expect it can cause
      other issues on different scenarios.
      
      Restore previous setting of RTS/CTS being disabled by default for
      OFDM/CCK by changing MT_TX_RTS_CFG_THRESH initvals to 0xffff.
      
      Fixes: 26a7b547 ("mt76x02: set protection according to ht operation element")
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      7dfc45e6
    • Lorenzo Bianconi's avatar
      mt76: fix schedule while atomic in mt76x02_reset_state · 13f61dfc
      Lorenzo Bianconi authored
      Fix following schedule while atomic in mt76x02_reset_state
      since synchronize_rcu is run inside a RCU section
      
      [44036.944222] mt76x2e 0000:06:00.0: MCU message 31 (seq 3) timed out
      [44036.944281] BUG: sleeping function called from invalid context at kernel/rcu/tree_exp.h:818
      [44036.944284] in_atomic(): 1, irqs_disabled(): 0, pid: 28066, name: kworker/u4:1
      [44036.944287] INFO: lockdep is turned off.
      [44036.944292] CPU: 1 PID: 28066 Comm: kworker/u4:1 Tainted: G        W         5.0.0-rc7-wdn-t1+ #7
      [44036.944294] Hardware name: Dell Inc. Studio XPS 1340/0K183D, BIOS A11 09/08/2009
      [44036.944305] Workqueue: phy1 mt76x02_wdt_work [mt76x02_lib]
      [44036.944308] Call Trace:
      [44036.944317]  dump_stack+0x67/0x90
      [44036.944322]  ___might_sleep.cold.88+0x9f/0xaf
      [44036.944327]  rcu_blocking_is_gp+0x13/0x50
      [44036.944330]  synchronize_rcu+0x17/0x80
      [44036.944337]  mt76_sta_state+0x138/0x1d0 [mt76]
      [44036.944349]  mt76x02_wdt_work+0x1c9/0x610 [mt76x02_lib]
      [44036.944355]  process_one_work+0x2a5/0x620
      [44036.944361]  worker_thread+0x35/0x3e0
      [44036.944368]  kthread+0x11c/0x140
      [44036.944376]  ret_from_fork+0x3a/0x50
      [44036.944384] BUG: scheduling while atomic: kworker/u4:1/28066/0x00000002
      [44036.944387] INFO: lockdep is turned off.
      [44036.944389] Modules linked in: cmac ctr ccm af_packet snd_hda_codec_hdmi
      
      Introduce __mt76_sta_remove in order to run sta_remove without holding dev->mutex.
      Move __mt76_sta_remove outside of RCU section in mt76x02_reset_state
      
      Fixes: e4ebb8b403d1 ("mt76: mt76x2: implement full device restart on watchdog reset")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      13f61dfc
    • Felix Fietkau's avatar
      mt76: mt7603: use the correct hweight8() function · f2a00a82
      Felix Fietkau authored
      __sw_hweight8() is only defined if CONFIG_GENERIC_HWEIGHT is enabled.
      The function that works on all architectures is hweight8().
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      f2a00a82
    • Stanislaw Gruszka's avatar
      mt76x02u: check chip version on probe · 40b94161
      Stanislaw Gruszka authored
      Since some USB device IDs are duplicated between mt76x0u, mt7601u
      and mt76x2u device, check chip version on probe and return error if
      not match the driver.
      
      Don't think this is serious issue, probe most likely will fail at
      some other point for wrong device, but we do not have to configure
      it if we know is not our device.
      Reported-by: default avatarXose Vazquez Perez <xose.vazquez@gmail.com>
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      40b94161
    • Stanislaw Gruszka's avatar
      mt7601u: check chip version on probe · c0316470
      Stanislaw Gruszka authored
      Since some USB device IDs are duplicated between mt7601u and mt76x0u
      devices, check chip version on probe and return error if not match
      0x7601.
      
      Don't think this is serious issue, probe most likely will fail at
      some other point for wrong device, but we do not have to configure
      it if we know is not mt7601u device.
      Reported-by: default avatarXose Vazquez Perez <xose.vazquez@gmail.com>
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: default avatarJakub Kicinski <kubakici@wp.pl>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      c0316470
    • Stefan Schmidt's avatar
      Merge remote-tracking branch 'net/master' · 86008304
      Stefan Schmidt authored
      86008304
    • Pablo Neira Ayuso's avatar
      netfilter: nf_flowtable: remove duplicated transition in diagram · 7c9abe12
      Pablo Neira Ayuso authored
      No direct transition from prerouting to forward hook, routing lookup
      needs to happen first.
      
      Fixes: 19b351f1 ("netfilter: add flowtable documentation")
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      7c9abe12
    • Florian Fainelli's avatar
      Documentation: networking: Update netdev-FAQ regarding patches · ffa91253
      Florian Fainelli authored
      Provide an explanation of what is expected with respect to sending new
      versions of specific patches within a patch series, as well as what
      happens if an earlier patch series accidentally gets merged).
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ffa91253
    • David S. Miller's avatar
      Merge branch 's390-qeth-fixes' · d0645cfd
      David S. Miller authored
      Julian Wiedmann says:
      
      ====================
      s390/qeth: fixes 2019-03-18
      
      please apply the following three patches to -net. The first two are fixes
      for minor race conditions in the probe code, while the third one gets
      dropwatch working (again).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0645cfd
    • Julian Wiedmann's avatar
      s390/qeth: be drop monitor friendly · 104b4859
      Julian Wiedmann authored
      As part of the TX completion path, qeth_release_skbs() frees the completed
      skbs with __skb_queue_purge(). This ends in kfree_skb(), reporting every
      completed skb as dropped.
      On the other hand when dropping an skb in .ndo_start_xmit, we end up
      calling consume_skb()... where we should be using kfree_skb() so that
      drop monitors get notified.
      
      Switch the drop/consume logic around, and also don't accumulate dropped
      packets in the tx_errors statistics.
      
      Fixes: dc149e37 ("s390/qeth: replace open-coded skb_queue_walk()")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      104b4859
    • Julian Wiedmann's avatar
      s390/qeth: fix race when initializing the IP address table · 7221b727
      Julian Wiedmann authored
      The ucast IP table is utilized by some of the L3-specific sysfs attributes
      that qeth_l3_create_device_attributes() provides. So initialize the table
      _before_ registering the attributes.
      
      Fixes: ebccc739 ("s390/qeth: add missing hash table initializations")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7221b727
    • Julian Wiedmann's avatar
      s390/qeth: don't erase configuration while probing · 12b409dd
      Julian Wiedmann authored
      The HW trap and VNICC configuration is exposed via sysfs, and may have
      already been modified when qeth_l?_probe_device() attempts to initialize
      them. So (1) initialize the VNICC values a little earlier, and (2) don't
      bother about the HW trap mode, it was already initialized before.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      12b409dd
    • Bjorn Helgaas's avatar
      mISDN: hfcpci: Test both vendor & device ID for Digium HFC4S · fae846e2
      Bjorn Helgaas authored
      The device ID alone does not uniquely identify a device.  Test both the
      vendor and device ID to make sure we don't mistakenly think some other
      vendor's 0xB410 device is a Digium HFC4S.  Also, instead of the bare hex
      ID, use the same constant (PCI_DEVICE_ID_DIGIUM_HFC4S) used in the device
      ID table.
      
      No functional change intended.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fae846e2