1. 20 Mar, 2019 8 commits
    • 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
  2. 19 Mar, 2019 32 commits