1. 16 Nov, 2020 10 commits
  2. 15 Nov, 2020 17 commits
  3. 14 Nov, 2020 9 commits
    • Sven Van Asbroeck's avatar
      lan743x: prevent entire kernel HANG on open, for some platforms · 796a2665
      Sven Van Asbroeck authored
      On arm imx6, when opening the chip's netdev, the whole Linux
      kernel intermittently hangs/freezes.
      
      This is caused by a bug in the driver code which tests if pcie
      interrupts are working correctly, using the software interrupt:
      
      1. open: enable the software interrupt
      2. open: tell the chip to assert the software interrupt
      3. open: wait for flag
      4. ISR: acknowledge s/w interrupt, set flag
      5. open: notice flag, disable the s/w interrupt, continue
      
      Unfortunately the ISR only acknowledges the s/w interrupt, but
      does not disable it. This will re-trigger the ISR in a tight
      loop.
      
      On some (lucky) platforms, open proceeds to disable the s/w
      interrupt even while the ISR is 'spinning'. On arm imx6,
      the spinning ISR does not allow open to proceed, resulting
      in a hung Linux kernel.
      
      Fix minimally by disabling the s/w interrupt in the ISR, which
      will prevent it from spinning. This won't break anything because
      the s/w interrupt is used as a one-shot interrupt.
      
      Note that this is a minimal fix, overlooking many possible
      cleanups, e.g.:
      - lan743x_intr_software_isr() is completely redundant and reads
        INT_STS twice for no apparent reason
      - disabling the s/w interrupt in lan743x_intr_test_isr() is now
        redundant, but harmless
      - waiting on software_isr_flag can be converted from a sleeping
        poll loop to wait_event_timeout()
      
      Fixes: 23f0703c ("lan743x: Add main source files for new lan743x driver")
      Tested-by: Sven Van Asbroeck <thesven73@gmail.com> # arm imx6 lan7430
      Signed-off-by: default avatarSven Van Asbroeck <thesven73@gmail.com>
      Link: https://lore.kernel.org/r/20201112204741.12375-1-TheSven73@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      796a2665
    • Sven Van Asbroeck's avatar
      lan743x: fix issue causing intermittent kernel log warnings · e35df62e
      Sven Van Asbroeck authored
      When running this chip on arm imx6, we intermittently observe
      the following kernel warning in the log, especially when the
      system is under high load:
      
      [   50.119484] ------------[ cut here ]------------
      [   50.124377] WARNING: CPU: 0 PID: 303 at kernel/softirq.c:169 __local_bh_enable_ip+0x100/0x184
      [   50.132925] IRQs not enabled as expected
      [   50.159250] CPU: 0 PID: 303 Comm: rngd Not tainted 5.7.8 #1
      [   50.164837] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      [   50.171395] [<c0111a38>] (unwind_backtrace) from [<c010be28>] (show_stack+0x10/0x14)
      [   50.179162] [<c010be28>] (show_stack) from [<c05b9dec>] (dump_stack+0xac/0xd8)
      [   50.186408] [<c05b9dec>] (dump_stack) from [<c0122e40>] (__warn+0xd0/0x10c)
      [   50.193391] [<c0122e40>] (__warn) from [<c0123238>] (warn_slowpath_fmt+0x98/0xc4)
      [   50.200892] [<c0123238>] (warn_slowpath_fmt) from [<c012b010>] (__local_bh_enable_ip+0x100/0x184)
      [   50.209860] [<c012b010>] (__local_bh_enable_ip) from [<bf09ecbc>] (destroy_conntrack+0x48/0xd8 [nf_conntrack])
      [   50.220038] [<bf09ecbc>] (destroy_conntrack [nf_conntrack]) from [<c0ac9b58>] (nf_conntrack_destroy+0x94/0x168)
      [   50.230160] [<c0ac9b58>] (nf_conntrack_destroy) from [<c0a4aaa0>] (skb_release_head_state+0xa0/0xd0)
      [   50.239314] [<c0a4aaa0>] (skb_release_head_state) from [<c0a4aadc>] (skb_release_all+0xc/0x24)
      [   50.247946] [<c0a4aadc>] (skb_release_all) from [<c0a4b4cc>] (consume_skb+0x74/0x17c)
      [   50.255796] [<c0a4b4cc>] (consume_skb) from [<c081a2dc>] (lan743x_tx_release_desc+0x120/0x124)
      [   50.264428] [<c081a2dc>] (lan743x_tx_release_desc) from [<c081a98c>] (lan743x_tx_napi_poll+0x5c/0x18c)
      [   50.273755] [<c081a98c>] (lan743x_tx_napi_poll) from [<c0a6b050>] (net_rx_action+0x118/0x4a4)
      [   50.282306] [<c0a6b050>] (net_rx_action) from [<c0101364>] (__do_softirq+0x13c/0x53c)
      [   50.290157] [<c0101364>] (__do_softirq) from [<c012b29c>] (irq_exit+0x150/0x17c)
      [   50.297575] [<c012b29c>] (irq_exit) from [<c0196a08>] (__handle_domain_irq+0x60/0xb0)
      [   50.305423] [<c0196a08>] (__handle_domain_irq) from [<c05d44fc>] (gic_handle_irq+0x4c/0x90)
      [   50.313790] [<c05d44fc>] (gic_handle_irq) from [<c0100ed4>] (__irq_usr+0x54/0x80)
      [   50.321287] Exception stack(0xecd99fb0 to 0xecd99ff8)
      [   50.326355] 9fa0:                                     1cf1aa74 00000001 00000001 00000000
      [   50.334547] 9fc0: 00000001 00000000 00000000 00000000 00000000 00000000 00004097 b6d17d14
      [   50.342738] 9fe0: 00000001 b6d17c60 00000000 b6e71f94 800b0010 ffffffff
      [   50.349364] irq event stamp: 2525027
      [   50.352955] hardirqs last  enabled at (2525026): [<c0a6afec>] net_rx_action+0xb4/0x4a4
      [   50.360892] hardirqs last disabled at (2525027): [<c0d6d2fc>] _raw_spin_lock_irqsave+0x1c/0x50
      [   50.369517] softirqs last  enabled at (2524660): [<c01015b4>] __do_softirq+0x38c/0x53c
      [   50.377446] softirqs last disabled at (2524693): [<c012b29c>] irq_exit+0x150/0x17c
      [   50.385027] ---[ end trace c0b571db4bc8087d ]---
      
      The driver is calling dev_kfree_skb() from code inside a spinlock,
      where h/w interrupts are disabled. This is forbidden, as documented
      in include/linux/netdevice.h. The correct function to use
      dev_kfree_skb_irq(), or dev_kfree_skb_any().
      
      Fix by using the correct dev_kfree_skb_xxx() functions:
      
      in lan743x_tx_release_desc():
        called by lan743x_tx_release_completed_descriptors()
          called by in lan743x_tx_napi_poll()
          which holds a spinlock
        called by lan743x_tx_release_all_descriptors()
          called by lan743x_tx_close()
          which can-sleep
      conclusion: use dev_kfree_skb_any()
      
      in lan743x_tx_xmit_frame():
        which holds a spinlock
      conclusion: use dev_kfree_skb_irq()
      
      in lan743x_tx_close():
        which can-sleep
      conclusion: use dev_kfree_skb()
      
      in lan743x_rx_release_ring_element():
        called by lan743x_rx_close()
          which can-sleep
        called by lan743x_rx_open()
          which can-sleep
      conclusion: use dev_kfree_skb()
      
      Fixes: 23f0703c ("lan743x: Add main source files for new lan743x driver")
      Signed-off-by: default avatarSven Van Asbroeck <thesven73@gmail.com>
      Link: https://lore.kernel.org/r/20201112185949.11315-1-TheSven73@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e35df62e
    • Paul Moore's avatar
      netlabel: fix an uninitialized warning in netlbl_unlabel_staticlist() · 1ba86d43
      Paul Moore authored
      Static checking revealed that a previous fix to
      netlbl_unlabel_staticlist() leaves a stack variable uninitialized,
      this patches fixes that.
      
      Fixes: 866358ec ("netlabel: fix our progress tracking in netlbl_unlabel_staticlist()")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Reviewed-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      Link: https://lore.kernel.org/r/160530304068.15651.18355773009751195447.stgit@siflSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1ba86d43
    • Xin Long's avatar
      sctp: change to hold/put transport for proto_unreach_timer · 057a10fa
      Xin Long authored
      A call trace was found in Hangbin's Codenomicon testing with debug kernel:
      
        [ 2615.981988] ODEBUG: free active (active state 0) object type: timer_list hint: sctp_generate_proto_unreach_event+0x0/0x3a0 [sctp]
        [ 2615.995050] WARNING: CPU: 17 PID: 0 at lib/debugobjects.c:328 debug_print_object+0x199/0x2b0
        [ 2616.095934] RIP: 0010:debug_print_object+0x199/0x2b0
        [ 2616.191533] Call Trace:
        [ 2616.194265]  <IRQ>
        [ 2616.202068]  debug_check_no_obj_freed+0x25e/0x3f0
        [ 2616.207336]  slab_free_freelist_hook+0xeb/0x140
        [ 2616.220971]  kfree+0xd6/0x2c0
        [ 2616.224293]  rcu_do_batch+0x3bd/0xc70
        [ 2616.243096]  rcu_core+0x8b9/0xd00
        [ 2616.256065]  __do_softirq+0x23d/0xacd
        [ 2616.260166]  irq_exit+0x236/0x2a0
        [ 2616.263879]  smp_apic_timer_interrupt+0x18d/0x620
        [ 2616.269138]  apic_timer_interrupt+0xf/0x20
        [ 2616.273711]  </IRQ>
      
      This is because it holds asoc when transport->proto_unreach_timer starts
      and puts asoc when the timer stops, and without holding transport the
      transport could be freed when the timer is still running.
      
      So fix it by holding/putting transport instead for proto_unreach_timer
      in transport, just like other timers in transport.
      
      v1->v2:
        - Also use sctp_transport_put() for the "out_unlock:" path in
          sctp_generate_proto_unreach_event(), as Marcelo noticed.
      
      Fixes: 50b5d6ad ("sctp: Fix a race between ICMP protocol unreachable and connect()")
      Reported-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Link: https://lore.kernel.org/r/102788809b554958b13b95d33440f5448113b8d6.1605331373.git.lucien.xin@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      057a10fa
    • Stefano Garzarella's avatar
      vsock: forward all packets to the host when no H2G is registered · 65b422d9
      Stefano Garzarella authored
      Before commit c0cfa2d8 ("vsock: add multi-transports support"),
      if a G2H transport was loaded (e.g. virtio transport), every packets
      was forwarded to the host, regardless of the destination CID.
      The H2G transports implemented until then (vhost-vsock, VMCI) always
      responded with an error, if the destination CID was not
      VMADDR_CID_HOST.
      
      From that commit, we are using the remote CID to decide which
      transport to use, so packets with remote CID > VMADDR_CID_HOST(2)
      are sent only through H2G transport. If no H2G is available, packets
      are discarded directly in the guest.
      
      Some use cases (e.g. Nitro Enclaves [1]) rely on the old behaviour
      to implement sibling VMs communication, so we restore the old
      behavior when no H2G is registered.
      It will be up to the host to discard packets if the destination is
      not the right one. As it was already implemented before adding
      multi-transport support.
      
      Tested with nested QEMU/KVM by me and Nitro Enclaves by Andra.
      
      [1] Documentation/virt/ne_overview.rst
      
      Cc: Jorgen Hansen <jhansen@vmware.com>
      Cc: Dexuan Cui <decui@microsoft.com>
      Fixes: c0cfa2d8 ("vsock: add multi-transports support")
      Reported-by: default avatarAndra Paraschiv <andraprs@amazon.com>
      Tested-by: default avatarAndra Paraschiv <andraprs@amazon.com>
      Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Link: https://lore.kernel.org/r/20201112133837.34183-1-sgarzare@redhat.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      65b422d9
    • Tobias Waldekranz's avatar
      net: dsa: mv88e6xxx: Avoid VTU corruption on 6097 · 92307069
      Tobias Waldekranz authored
      As soon as you add the second port to a VLAN, all other port
      membership configuration is overwritten with zeroes. The HW interprets
      this as all ports being "unmodified members" of the VLAN.
      
      In the simple case when all ports belong to the same VLAN, switching
      will still work. But using multiple VLANs or trying to set multiple
      ports as tagged members will not work.
      
      On the 6352, doing a VTU GetNext op, followed by an STU GetNext op
      will leave you with both the member- and state- data in the VTU/STU
      data registers. But on the 6097 (which uses the same implementation),
      the STU GetNext will override the information gathered from the VTU
      GetNext.
      
      Separate the two stages, parsing the result of the VTU GetNext before
      doing the STU GetNext.
      
      We opt to update the existing implementation for all applicable chips,
      as opposed to creating a separate callback for 6097, because although
      the previous implementation did work for (at least) 6352, the
      datasheet does not mention the masking behavior.
      
      Fixes: ef6fcea3 ("net: dsa: mv88e6xxx: get STU entry on VTU GetNext")
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Link: https://lore.kernel.org/r/20201112114335.27371-1-tobias@waldekranz.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      92307069
    • Zhang Changzhong's avatar
      net: phy: smsc: add missed clk_disable_unprepare in smsc_phy_probe() · 37344718
      Zhang Changzhong authored
      Add the missing clk_disable_unprepare() before return from
      smsc_phy_probe() in the error handling case.
      
      Fixes: bedd8d78 ("net: phy: smsc: LAN8710/20: add phy refclk in support")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
      Link: https://lore.kernel.org/r/1605180239-1792-1-git-send-email-zhangchangzhong@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      37344718
    • Zhang Qilong's avatar
      ipv6: Fix error path to cancel the meseage · ceb736e1
      Zhang Qilong authored
      genlmsg_cancel() needs to be called in the error path of
      inet6_fill_ifmcaddr and inet6_fill_ifacaddr to cancel
      the message.
      
      Fixes: 6ecf4c37 ("ipv6: enable IFA_TARGET_NETNSID for RTM_GETADDR")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarZhang Qilong <zhangqilong3@huawei.com>
      Link: https://lore.kernel.org/r/20201112080950.1476302-1-zhangqilong3@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ceb736e1
    • Yi-Hung Wei's avatar
      ip_tunnels: Set tunnel option flag when tunnel metadata is present · 9c2e14b4
      Yi-Hung Wei authored
      Currently, we may set the tunnel option flag when the size of metadata
      is zero.  For example, we set TUNNEL_GENEVE_OPT in the receive function
      no matter the geneve option is present or not.  As this may result in
      issues on the tunnel flags consumers, this patch fixes the issue.
      
      Related discussion:
      * https://lore.kernel.org/netdev/1604448694-19351-1-git-send-email-yihung.wei@gmail.com/T/#u
      
      Fixes: 256c87c1 ("net: check tunnel option type in tunnel flags")
      Signed-off-by: default avatarYi-Hung Wei <yihung.wei@gmail.com>
      Link: https://lore.kernel.org/r/1605053800-74072-1-git-send-email-yihung.wei@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9c2e14b4
  4. 13 Nov, 2020 4 commits