Skip to content
Snippets Groups Projects
  1. Apr 15, 2022
  2. Apr 14, 2022
  3. Apr 12, 2022
    • Igor Pylypiv's avatar
      Revert "module, async: async_synchronize_full() on module init iff async is used" · dc8da50c
      Igor Pylypiv authored
      
      stable inclusion
      from linux-4.19.231
      commit a0c66ac8b72f816d5631fde0ca0b39af602dce48
      
      --------------------------------
      
      [ Upstream commit 67d6212afda218d564890d1674bab28e8612170f ]
      
      This reverts commit 774a1221.
      
      We need to finish all async code before the module init sequence is
      done.  In the reverted commit the PF_USED_ASYNC flag was added to mark a
      thread that called async_schedule().  Then the PF_USED_ASYNC flag was
      used to determine whether or not async_synchronize_full() needs to be
      invoked.  This works when modprobe thread is calling async_schedule(),
      but it does not work if module dispatches init code to a worker thread
      which then calls async_schedule().
      
      For example, PCI driver probing is invoked from a worker thread based on
      a node where device is attached:
      
      	if (cpu < nr_cpu_ids)
      		error = work_on_cpu(cpu, local_pci_probe, &ddi);
      	else
      		error = local_pci_probe(&ddi);
      
      We end up in a situation where a worker thread gets the PF_USED_ASYNC
      flag set instead of the modprobe thread.  As a result,
      async_synchronize_full() is not invoked and modprobe completes without
      waiting for the async code to finish.
      
      The issue was discovered while loading the pm80xx driver:
      (scsi_mod.scan=async)
      
      modprobe pm80xx                      worker
      ...
        do_init_module()
        ...
          pci_call_probe()
            work_on_cpu(local_pci_probe)
                                           local_pci_probe()
                                             pm8001_pci_probe()
                                               scsi_scan_host()
                                                 async_schedule()
                                                 worker->flags |= PF_USED_ASYNC;
                                           ...
            < return from worker >
        ...
        if (current->flags & PF_USED_ASYNC) <--- false
        	async_synchronize_full();
      
      Commit 21c3c5d2 ("block: don't request module during elevator init")
      fixed the deadlock issue which the reverted commit 774a1221
      ("module, async: async_synchronize_full() on module init iff async is
      used") tried to fix.
      
      Since commit 0fdff3ec ("async, kmod: warn on synchronous
      request_module() from async workers") synchronous module loading from
      async is not allowed.
      
      Given that the original deadlock issue is fixed and it is no longer
      allowed to call synchronous request_module() from async we can remove
      PF_USED_ASYNC flag to make module init consistently invoke
      async_synchronize_full() unless async module probe is requested.
      
      Signed-off-by: default avatarIgor Pylypiv <ipylypiv@google.com>
      Reviewed-by: default avatarChangyuan Lyu <changyuanl@google.com>
      Reviewed-by: default avatarLuis Chamberlain <mcgrof@kernel.org>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
    • daniel.starke@siemens.com's avatar
      tty: n_gsm: fix encoding of control signal octet bit DV · be439c06
      daniel.starke@siemens.com authored
      stable inclusion
      from linux-4.19.232
      commit 28ca082153794cf5c98e7bb93d7f30f8ba46bec4
      
      --------------------------------
      
      commit 737b0ef3be6b319d6c1fd64193d1603311969326 upstream.
      
      n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010.
      See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516
      
      
      The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to
      the newer 27.010 here. Chapter 5.4.6.3.7 describes the encoding of the
      control signal octet used by the MSC (modem status command). The same
      encoding is also used in convergence layer type 2 as described in chapter
      5.5.2. Table 7 and 24 both require the DV (data valid) bit to be set 1 for
      outgoing control signal octets sent by the DTE (data terminal equipment),
      i.e. for the initiator side.
      Currently, the DV bit is only set if CD (carrier detect) is on, regardless
      of the side.
      
      This patch fixes this behavior by setting the DV bit on the initiator side
      unconditionally.
      
      Fixes: e1eaea46 ("tty: n_gsm line discipline")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Starke <daniel.starke@siemens.com>
      Link: https://lore.kernel.org/r/20220218073123.2121-1-daniel.starke@siemens.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      be439c06
    • Linus Torvalds's avatar
      fget: clarify and improve __fget_files() implementation · 8e227868
      Linus Torvalds authored
      stable inclusion
      from linux-4.19.232
      commit 400c2f361c25bc092d0636cfa32d0549a181e653
      
      --------------------------------
      
      commit e386dfc56f837da66d00a078e5314bc8382fab83 upstream.
      
      Commit 054aa8d439b9 ("fget: check that the fd still exists after getting
      a ref to it") fixed a race with getting a reference to a file just as it
      was being closed.  It was a fairly minimal patch, and I didn't think
      re-checking the file pointer lookup would be a measurable overhead,
      since it was all right there and cached.
      
      But I was wrong, as pointed out by the kernel test robot.
      
      The 'poll2' case of the will-it-scale.per_thread_ops benchmark regressed
      quite noticeably.  Admittedly it seems to be a very artificial test:
      doing "poll()" system calls on regular files in a very tight loop in
      multiple threads.
      
      That means that basically all the time is spent just looking up file
      descriptors without ever doing anything useful with them (not that doing
      'poll()' on a regular file is useful to begin with).  And as a result it
      shows the extra "re-check fd" cost as a sore thumb.
      
      Happily, the regression is fixable by just writing the code to loook up
      the fd to be better and clearer.  There's still a cost to verify the
      file pointer, but now it's basically in the noise even for that
      benchmark that does nothing else - and the code is more understandable
      and has better comments too.
      
      [ Side note: this patch is also a classic case of one that looks very
        messy with the default greedy Myers diff - it's much more legible with
        either the patience of histogram diff algorithm ]
      
      Link: https://lore.kernel.org/lkml/20211210053743.GA36420@xsang-OptiPlex-9020/
      Link: https://lore.kernel.org/lkml/20211213083154.GA20853@linux.intel.com/
      
      
      Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
      Tested-by: default avatarCarel Si <beibei.si@intel.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Miklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBaokun Li <libaokun1@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      8e227868
    • Miaohe Lin's avatar
      memblock: use kfree() to release kmalloced memblock regions · 7287cbc1
      Miaohe Lin authored
      
      stable inclusion
      from linux-4.19.232
      commit a6fcced73d15ab57cd97813999edf6f19d3032f8
      
      --------------------------------
      
      commit c94afc46cae7ad41b2ad6a99368147879f4b0e56 upstream.
      
      memblock.{reserved,memory}.regions may be allocated using kmalloc() in
      memblock_double_array(). Use kfree() to release these kmalloced regions
      indicated by memblock_{reserved,memory}_in_slab.
      
      Signed-off-by: default avatarMiaohe Lin <linmiaohe@huawei.com>
      Fixes: 3010f876 ("mm: discard memblock data later")
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      7287cbc1
    • daniel.starke@siemens.com's avatar
      tty: n_gsm: fix proper link termination after failed open · 99c367d7
      daniel.starke@siemens.com authored
      
      stable inclusion
      from linux-4.19.232
      commit 337e49675ce55c23a50b92aae889ec5d910d6dc7
      
      --------------------------------
      
      commit e3b7468f082d106459e86e8dc6fb9bdd65553433 upstream.
      
      Trying to open a DLCI by sending a SABM frame may fail with a timeout.
      The link is closed on the initiator side without informing the responder
      about this event. The responder assumes the link is open after sending a
      UA frame to answer the SABM frame. The link gets stuck in a half open
      state.
      
      This patch fixes this by initiating the proper link termination procedure
      after link setup timeout instead of silently closing it down.
      
      Fixes: e1eaea46 ("tty: n_gsm line discipline")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Starke <daniel.starke@siemens.com>
      Link: https://lore.kernel.org/r/20220218073123.2121-3-daniel.starke@siemens.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      99c367d7
    • Tao Liu's avatar
      gso: do not skip outer ip header in case of ipip and net_failover · df2f0cf3
      Tao Liu authored
      
      stable inclusion
      from linux-4.19.232
      commit e9ffbe63f6f32f526a461756309b61c395168d73
      
      --------------------------------
      
      commit cc20cced0598d9a5ff91ae4ab147b3b5e99ee819 upstream.
      
      We encounter a tcp drop issue in our cloud environment. Packet GROed in
      host forwards to a VM virtio_net nic with net_failover enabled. VM acts
      as a IPVS LB with ipip encapsulation. The full path like:
      host gro -> vm virtio_net rx -> net_failover rx -> ipvs fullnat
       -> ipip encap -> net_failover tx -> virtio_net tx
      
      When net_failover transmits a ipip pkt (gso_type = 0x0103, which means
      SKB_GSO_TCPV4, SKB_GSO_DODGY and SKB_GSO_IPXIP4), there is no gso
      did because it supports TSO and GSO_IPXIP4. But network_header points to
      inner ip header.
      
      Call Trace:
       tcp4_gso_segment        ------> return NULL
       inet_gso_segment        ------> inner iph, network_header points to
       ipip_gso_segment
       inet_gso_segment        ------> outer iph
       skb_mac_gso_segment
      
      Afterwards virtio_net transmits the pkt, only inner ip header is modified.
      And the outer one just keeps unchanged. The pkt will be dropped in remote
      host.
      
      Call Trace:
       inet_gso_segment        ------> inner iph, outer iph is skipped
       skb_mac_gso_segment
       __skb_gso_segment
       validate_xmit_skb
       validate_xmit_skb_list
       sch_direct_xmit
       __qdisc_run
       __dev_queue_xmit        ------> virtio_net
       dev_hard_start_xmit
       __dev_queue_xmit        ------> net_failover
       ip_finish_output2
       ip_output
       iptunnel_xmit
       ip_tunnel_xmit
       ipip_tunnel_xmit        ------> ipip
       dev_hard_start_xmit
       __dev_queue_xmit
       ip_finish_output2
       ip_output
       ip_forward
       ip_rcv
       __netif_receive_skb_one_core
       netif_receive_skb_internal
       napi_gro_receive
       receive_buf
       virtnet_poll
       net_rx_action
      
      The root cause of this issue is specific with the rare combination of
      SKB_GSO_DODGY and a tunnel device that adds an SKB_GSO_ tunnel option.
      SKB_GSO_DODGY is set from external virtio_net. We need to reset network
      header when callbacks.gso_segment() returns NULL.
      
      This patch also includes ipv6_gso_segment(), considering SIT, etc.
      
      Fixes: cb32f511 ("ipip: add GSO/TSO support")
      Signed-off-by: default avatarTao Liu <thomas.liu@ucloud.cn>
      Reviewed-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      df2f0cf3
    • Eric Dumazet's avatar
      net: __pskb_pull_tail() & pskb_carve_frag_list() drop_monitor friends · 220832c5
      Eric Dumazet authored
      
      stable inclusion
      from linux-4.19.232
      commit 1f4ae0f158dafa74133108bfa07b8053eb2a7898
      
      --------------------------------
      
      commit ef527f968ae05c6717c39f49c8709a7e2c19183a upstream.
      
      Whenever one of these functions pull all data from an skb in a frag_list,
      use consume_skb() instead of kfree_skb() to avoid polluting drop
      monitoring.
      
      Fixes: 6fa01ccd ("skbuff: Add pskb_extract() helper function")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20220220154052.1308469-1-eric.dumazet@gmail.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      220832c5
    • Zhang Qiao's avatar
      cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug · 6d17be8f
      Zhang Qiao authored
      stable inclusion
      from linux-4.19.232
      commit 4eec5fe1c680a6c47a9bc0cde00960a4eb663342
      
      --------------------------------
      
      commit 05c7b7a92cc87ff8d7fde189d0fade250697573c upstream.
      
      As previously discussed(https://lkml.org/lkml/2022/1/20/51
      
      ),
      cpuset_attach() is affected with similar cpu hotplug race,
      as follow scenario:
      
           cpuset_attach()				cpu hotplug
          ---------------------------            ----------------------
          down_write(cpuset_rwsem)
          guarantee_online_cpus() // (load cpus_attach)
      					sched_cpu_deactivate
      					  set_cpu_active()
      					  // will change cpu_active_mask
          set_cpus_allowed_ptr(cpus_attach)
            __set_cpus_allowed_ptr_locked()
             // (if the intersection of cpus_attach and
               cpu_active_mask is empty, will return -EINVAL)
          up_write(cpuset_rwsem)
      
      To avoid races such as described above, protect cpuset_attach() call
      with cpu_hotplug_lock.
      
      Fixes: be367d09 ("cgroups: let ss->can_attach and ss->attach do whole threadgroups at a time")
      Cc: stable@vger.kernel.org # v2.6.32+
      Reported-by: default avatarZhao Gongyi <zhaogongyi@huawei.com>
      Signed-off-by: default avatarZhang Qiao <zhangqiao22@huawei.com>
      Acked-by: default avatarWaiman Long <longman@redhat.com>
      Reviewed-by: default avatarMichal Koutný <mkoutny@suse.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      6d17be8f
    • JaeSang Yoo's avatar
      tracing: Fix tp_printk option related with tp_printk_stop_on_boot · 8dff553c
      JaeSang Yoo authored
      stable inclusion
      from linux-4.19.231
      commit 8f8c9e71e192823e4d76fdc53b4391642291bafc
      
      --------------------------------
      
      [ Upstream commit 3203ce39ac0b2a57a84382ec184c7d4a0bede175 ]
      
      The kernel parameter "tp_printk_stop_on_boot" starts with "tp_printk" which is
      the same as another kernel parameter "tp_printk". If "tp_printk" setup is
      called before the "tp_printk_stop_on_boot", it will override the latter
      and keep it from being set.
      
      This is similar to other kernel parameter issues, such as:
        Commit 745a600c ("um: console: Ignore console= option")
      or init/do_mounts.c:45 (setup function of "ro" kernel param)
      
      Fix it by checking for a "_" right after the "tp_printk" and if that
      exists do not process the parameter.
      
      Link: https://lkml.kernel.org/r/20220208195421.969326-1-jsyoo5b@gmail.com
      
      
      
      Signed-off-by: default avatarJaeSang Yoo <jsyoo5b@gmail.com>
      [ Fixed up change log and added space after if condition ]
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      8dff553c
    • Jiasheng Jiang's avatar
      dmaengine: sh: rcar-dmac: Check for error num after setting mask · 397e43da
      Jiasheng Jiang authored
      
      stable inclusion
      from linux-4.19.231
      commit 783d70c94e513ca715643c00c6c275d9eb3b1a9e
      
      --------------------------------
      
      commit 2d21543efe332cd8c8f212fb7d365bc8b0690bfa upstream.
      
      Because of the possible failure of the dma_supported(), the
      dma_set_mask_and_coherent() may return error num.
      Therefore, it should be better to check it and return the error if
      fails.
      
      Fixes: dc312349 ("dmaengine: rcar-dmac: Widen DMA mask to 40 bits")
      Signed-off-by: default avatarJiasheng Jiang <jiasheng@iscas.ac.cn>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Link: https://lore.kernel.org/r/20220106030939.2644320-1-jiasheng@iscas.ac.cn
      
      
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      397e43da
    • Eric Dumazet's avatar
      net: sched: limit TC_ACT_REPEAT loops · b4a48e80
      Eric Dumazet authored
      
      stable inclusion
      from linux-4.19.231
      commit f63c9fa36bd7548fd07792127057cccb68a7e274
      
      --------------------------------
      
      commit 5740d068909676d4bdb5c9c00c37a83df7728909 upstream.
      
      We have been living dangerously, at the mercy of malicious users,
      abusing TC_ACT_REPEAT, as shown by this syzpot report [1].
      
      Add an arbitrary limit (32) to the number of times an action can
      return TC_ACT_REPEAT.
      
      v2: switch the limit to 32 instead of 10.
          Use net_warn_ratelimited() instead of pr_err_once().
      
      [1] (C repro available on demand)
      
      rcu: INFO: rcu_preempt self-detected stall on CPU
      rcu:    1-...!: (10500 ticks this GP) idle=021/1/0x4000000000000000 softirq=5592/5592 fqs=0
              (t=10502 jiffies g=5305 q=190)
      rcu: rcu_preempt kthread timer wakeup didn't happen for 10502 jiffies! g5305 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
      rcu:    Possible timer handling issue on cpu=0 timer-softirq=3527
      rcu: rcu_preempt kthread starved for 10505 jiffies! g5305 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
      rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
      rcu: RCU grace-period kthread stack dump:
      task:rcu_preempt     state:I stack:29344 pid:   14 ppid:     2 flags:0x00004000
      Call Trace:
       <TASK>
       context_switch kernel/sched/core.c:4986 [inline]
       __schedule+0xab2/0x4db0 kernel/sched/core.c:6295
       schedule+0xd2/0x260 kernel/sched/core.c:6368
       schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881
       rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c:1963
       rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2136
       kthread+0x2e9/0x3a0 kernel/kthread.c:377
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
       </TASK>
      rcu: Stack dump where RCU GP kthread last ran:
      Sending NMI from CPU 1 to CPUs 0:
      NMI backtrace for cpu 0
      CPU: 0 PID: 3646 Comm: syz-executor358 Not tainted 5.17.0-rc3-syzkaller-00149-gbf8e59fd315f #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:rep_nop arch/x86/include/asm/vdso/processor.h:13 [inline]
      RIP: 0010:cpu_relax arch/x86/include/asm/vdso/processor.h:18 [inline]
      RIP: 0010:pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:437 [inline]
      RIP: 0010:__pv_queued_spin_lock_slowpath+0x3b8/0xb40 kernel/locking/qspinlock.c:508
      Code: 48 89 eb c6 45 01 01 41 bc 00 80 00 00 48 c1 e9 03 83 e3 07 41 be 01 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8d 2c 01 eb 0c <f3> 90 41 83 ec 01 0f 84 72 04 00 00 41 0f b6 45 00 38 d8 7f 08 84
      RSP: 0018:ffffc9000283f1b0 EFLAGS: 00000206
      RAX: 0000000000000003 RBX: 0000000000000000 RCX: 1ffff1100fc0071e
      RDX: 0000000000000001 RSI: 0000000000000201 RDI: 0000000000000000
      RBP: ffff88807e0038f0 R08: 0000000000000001 R09: ffffffff8ffbf9ff
      R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000004c1e
      R13: ffffed100fc0071e R14: 0000000000000001 R15: ffff8880b9c3aa80
      FS:  00005555562bf300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffdbfef12b8 CR3: 00000000723c2000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:591 [inline]
       queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline]
       queued_spin_lock include/asm-generic/qspinlock.h:85 [inline]
       do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:115
       spin_lock_bh include/linux/spinlock.h:354 [inline]
       sch_tree_lock include/net/sch_generic.h:610 [inline]
       sch_tree_lock include/net/sch_generic.h:605 [inline]
       prio_tune+0x3b9/0xb50 net/sched/sch_prio.c:211
       prio_init+0x5c/0x80 net/sched/sch_prio.c:244
       qdisc_create.constprop.0+0x44a/0x10f0 net/sched/sch_api.c:1253
       tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660
       rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5594
       netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494
       netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
       netlink_unicast+0x539/0x7e0 net/netlink/af_netlink.c:1343
       netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1919
       sock_sendmsg_nosec net/socket.c:705 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:725
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2413
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2467
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2496
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x7f7ee98aae99
      Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007ffdbfef12d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007ffdbfef1300 RCX: 00007f7ee98aae99
      RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000003
      RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d
      R10: 000000000000000d R11: 0000000000000246 R12: 00007ffdbfef12f0
      R13: 00000000000f4240 R14: 000000000004ca47 R15: 00007ffdbfef12e4
       </TASK>
      INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 2.293 msecs
      NMI backtrace for cpu 1
      CPU: 1 PID: 3260 Comm: kworker/1:3 Not tainted 5.17.0-rc3-syzkaller-00149-gbf8e59fd315f #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: mld mld_ifc_work
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
       nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111
       nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62
       trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
       rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343
       print_cpu_stall kernel/rcu/tree_stall.h:604 [inline]
       check_cpu_stall kernel/rcu/tree_stall.h:688 [inline]
       rcu_pending kernel/rcu/tree.c:3919 [inline]
       rcu_sched_clock_irq.cold+0x5c/0x759 kernel/rcu/tree.c:2617
       update_process_times+0x16d/0x200 kernel/time/timer.c:1785
       tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226
       tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428
       __run_hrtimer kernel/time/hrtimer.c:1685 [inline]
       __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749
       hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811
       local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline]
       __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103
       sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097
       </IRQ>
       <TASK>
       asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638
      RIP: 0010:__sanitizer_cov_trace_const_cmp4+0xc/0x70 kernel/kcov.c:286
      Code: 00 00 00 48 89 7c 30 e8 48 89 4c 30 f0 4c 89 54 d8 20 48 89 10 5b c3 0f 1f 80 00 00 00 00 41 89 f8 bf 03 00 00 00 4c 8b 14 24 <89> f1 65 48 8b 34 25 00 70 02 00 e8 14 f9 ff ff 84 c0 74 4b 48 8b
      RSP: 0018:ffffc90002c5eea8 EFLAGS: 00000246
      RAX: 0000000000000007 RBX: ffff88801c625800 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
      RBP: ffff8880137d3100 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffffff874fcd88 R11: 0000000000000000 R12: ffff88801d692dc0
      R13: ffff8880137d3104 R14: 0000000000000000 R15: ffff88801d692de8
       tcf_police_act+0x358/0x11d0 net/sched/act_police.c:256
       tcf_action_exec net/sched/act_api.c:1049 [inline]
       tcf_action_exec+0x1a6/0x530 net/sched/act_api.c:1026
       tcf_exts_exec include/net/pkt_cls.h:326 [inline]
       route4_classify+0xef0/0x1400 net/sched/cls_route.c:179
       __tcf_classify net/sched/cls_api.c:1549 [inline]
       tcf_classify+0x3e8/0x9d0 net/sched/cls_api.c:1615
       prio_classify net/sched/sch_prio.c:42 [inline]
       prio_enqueue+0x3a7/0x790 net/sched/sch_prio.c:75
       dev_qdisc_enqueue+0x40/0x300 net/core/dev.c:3668
       __dev_xmit_skb net/core/dev.c:3756 [inline]
       __dev_queue_xmit+0x1f61/0x3660 net/core/dev.c:4081
       neigh_hh_output include/net/neighbour.h:533 [inline]
       neigh_output include/net/neighbour.h:547 [inline]
       ip_finish_output2+0x14dc/0x2170 net/ipv4/ip_output.c:228
       __ip_finish_output net/ipv4/ip_output.c:306 [inline]
       __ip_finish_output+0x396/0x650 net/ipv4/ip_output.c:288
       ip_finish_output+0x32/0x200 net/ipv4/ip_output.c:316
       NF_HOOK_COND include/linux/netfilter.h:296 [inline]
       ip_output+0x196/0x310 net/ipv4/ip_output.c:430
       dst_output include/net/dst.h:451 [inline]
       ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:126
       iptunnel_xmit+0x628/0xa50 net/ipv4/ip_tunnel_core.c:82
       geneve_xmit_skb drivers/net/geneve.c:966 [inline]
       geneve_xmit+0x10c8/0x3530 drivers/net/geneve.c:1077
       __netdev_start_xmit include/linux/netdevice.h:4683 [inline]
       netdev_start_xmit include/linux/netdevice.h:4697 [inline]
       xmit_one net/core/dev.c:3473 [inline]
       dev_hard_start_xmit+0x1eb/0x920 net/core/dev.c:3489
       __dev_queue_xmit+0x2985/0x3660 net/core/dev.c:4116
       neigh_hh_output include/net/neighbour.h:533 [inline]
       neigh_output include/net/neighbour.h:547 [inline]
       ip6_finish_output2+0xf7a/0x14f0 net/ipv6/ip6_output.c:126
       __ip6_finish_output net/ipv6/ip6_output.c:191 [inline]
       __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170
       ip6_finish_output+0x32/0x200 net/ipv6/ip6_output.c:201
       NF_HOOK_COND include/linux/netfilter.h:296 [inline]
       ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224
       dst_output include/net/dst.h:451 [inline]
       NF_HOOK include/linux/netfilter.h:307 [inline]
       NF_HOOK include/linux/netfilter.h:301 [inline]
       mld_sendpack+0x9a3/0xe40 net/ipv6/mcast.c:1826
       mld_send_cr net/ipv6/mcast.c:2127 [inline]
       mld_ifc_work+0x71c/0xdc0 net/ipv6/mcast.c:2659
       process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307
       worker_thread+0x657/0x1110 kernel/workqueue.c:2454
       kthread+0x2e9/0x3a0 kernel/kthread.c:377
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
       </TASK>
      ----------------
      Code disassembly (best guess):
         0:   48 89 eb                mov    %rbp,%rbx
         3:   c6 45 01 01             movb   $0x1,0x1(%rbp)
         7:   41 bc 00 80 00 00       mov    $0x8000,%r12d
         d:   48 c1 e9 03             shr    $0x3,%rcx
        11:   83 e3 07                and    $0x7,%ebx
        14:   41 be 01 00 00 00       mov    $0x1,%r14d
        1a:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
        21:   fc ff df
        24:   4c 8d 2c 01             lea    (%rcx,%rax,1),%r13
        28:   eb 0c                   jmp    0x36
      * 2a:   f3 90                   pause <-- trapping instruction
        2c:   41 83 ec 01             sub    $0x1,%r12d
        30:   0f 84 72 04 00 00       je     0x4a8
        36:   41 0f b6 45 00          movzbl 0x0(%r13),%eax
        3b:   38 d8                   cmp    %bl,%al
        3d:   7f 08                   jg     0x47
        3f:   84                      .byte 0x84
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Link: https://lore.kernel.org/r/20220215235305.3272331-1-eric.dumazet@gmail.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      b4a48e80
    • Bryan O'Donoghue's avatar
      mtd: rawnand: qcom: Fix clock sequencing in qcom_nandc_probe() · 6ff4cceb
      Bryan O'Donoghue authored
      
      stable inclusion
      from linux-4.19.231
      commit 891484112f4ffd0b576e88407bbd3653abf3faba
      
      --------------------------------
      
      commit 5c23b3f965bc9ee696bf2ed4bdc54d339dd9a455 upstream.
      
      Interacting with a NAND chip on an IPQ6018 I found that the qcomsmem NAND
      partition parser was returning -EPROBE_DEFER waiting for the main smem
      driver to load.
      
      This caused the board to reset. Playing about with the probe() function
      shows that the problem lies in the core clock being switched off before the
      nandc_unalloc() routine has completed.
      
      If we look at how qcom_nandc_remove() tears down allocated resources we see
      the expected order is
      
      qcom_nandc_unalloc(nandc);
      
      clk_disable_unprepare(nandc->aon_clk);
      clk_disable_unprepare(nandc->core_clk);
      
      dma_unmap_resource(&pdev->dev, nandc->base_dma, resource_size(res),
      		   DMA_BIDIRECTIONAL, 0);
      
      Tweaking probe() to both bring up and tear-down in that order removes the
      reset if we end up deferring elsewhere.
      
      Fixes: c76b78d8 ("mtd: nand: Qualcomm NAND controller driver")
      Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      Reviewed-by: default avatarManivannan Sadhasivam <mani@kernel.org>
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Link: https://lore.kernel.org/linux-mtd/20220103030316.58301-2-bryan.odonoghue@linaro.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      6ff4cceb
    • Trond Myklebust's avatar
      NFS: Do not report writeback errors in nfs_getattr() · e488b678
      Trond Myklebust authored
      
      stable inclusion
      from linux-4.19.231
      commit d2ba21f271eb167ac2b0581598e55222b89f0f32
      
      --------------------------------
      
      commit d19e0183a88306acda07f4a01fedeeffe2a2a06b upstream.
      
      The result of the writeback, whether it is an ENOSPC or an EIO, or
      anything else, does not inhibit the NFS client from reporting the
      correct file timestamps.
      
      Fixes: 79566ef0 ("NFS: Getattr doesn't require data sync semantics")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      e488b678