Skip to content
  1. Feb 10, 2021
    • Dave Hansen's avatar
      x86/apic: Add extra serialization for non-serializing MSRs · 36e5fe7f
      Dave Hansen authored
      commit 25a068b8
      
       upstream.
      
      Jan Kiszka reported that the x2apic_wrmsr_fence() function uses a plain
      MFENCE while the Intel SDM (10.12.3 MSR Access in x2APIC Mode) calls for
      MFENCE; LFENCE.
      
      Short summary: we have special MSRs that have weaker ordering than all
      the rest. Add fencing consistent with current SDM recommendations.
      
      This is not known to cause any issues in practice, only in theory.
      
      Longer story below:
      
      The reason the kernel uses a different semantic is that the SDM changed
      (roughly in late 2017). The SDM changed because folks at Intel were
      auditing all of the recommended fences in the SDM and realized that the
      x2apic fences were insufficient.
      
      Why was the pain MFENCE judged insufficient?
      
      WRMSR itself is normally a serializing instruction. No fences are needed
      because the instruction itself serializes everything.
      
      But, there are explicit exceptions for this serializing behavior written
      into the WRMSR instruction documentation for two classes of MSRs:
      IA32_TSC_DEADLINE and the X2APIC MSRs.
      
      Back to x2apic: WRMSR is *not* serializing in this specific case.
      But why is MFENCE insufficient? MFENCE makes writes visible, but
      only affects load/store instructions. WRMSR is unfortunately not a
      load/store instruction and is unaffected by MFENCE. This means that a
      non-serializing WRMSR could be reordered by the CPU to execute before
      the writes made visible by the MFENCE have even occurred in the first
      place.
      
      This means that an x2apic IPI could theoretically be triggered before
      there is any (visible) data to process.
      
      Does this affect anything in practice? I honestly don't know. It seems
      quite possible that by the time an interrupt gets to consume the (not
      yet) MFENCE'd data, it has become visible, mostly by accident.
      
      To be safe, add the SDM-recommended fences for all x2apic WRMSRs.
      
      This also leaves open the question of the _other_ weakly-ordered WRMSR:
      MSR_IA32_TSC_DEADLINE. While it has the same ordering architecture as
      the x2APIC MSRs, it seems substantially less likely to be a problem in
      practice. While writes to the in-memory Local Vector Table (LVT) might
      theoretically be reordered with respect to a weakly-ordered WRMSR like
      TSC_DEADLINE, the SDM has this to say:
      
        In x2APIC mode, the WRMSR instruction is used to write to the LVT
        entry. The processor ensures the ordering of this write and any
        subsequent WRMSR to the deadline; no fencing is required.
      
      But, that might still leave xAPIC exposed. The safest thing to do for
      now is to add the extra, recommended LFENCE.
      
       [ bp: Massage commit message, fix typos, drop accidentally added
         newline to tools/arch/x86/include/asm/barrier.h. ]
      
      Reported-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20200305174708.F77040DD@viggo.jf.intel.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36e5fe7f
    • Josh Poimboeuf's avatar
      x86/build: Disable CET instrumentation in the kernel · dee55c07
      Josh Poimboeuf authored
      commit 20bf2b37 upstream.
      
      With retpolines disabled, some configurations of GCC, and specifically
      the GCC versions 9 and 10 in Ubuntu will add Intel CET instrumentation
      to the kernel by default. That breaks certain tracing scenarios by
      adding a superfluous ENDBR64 instruction before the fentry call, for
      functions which can be called indirectly.
      
      CET instrumentation isn't currently necessary in the kernel, as CET is
      only supported in user space. Disable it unconditionally and move it
      into the x86's Makefile as CET/CFI... enablement should be a per-arch
      decision anyway.
      
       [ bp: Massage and extend commit message. ]
      
      Fixes: 29be86d7
      
       ("kbuild: add -fcf-protection=none when using retpoline flags")
      Reported-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Tested-by: default avatarNikolay Borisov <nborisov@suse.com>
      Cc: <stable@vger.kernel.org>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Link: https://lkml.kernel.org/r/20210128215219.6kct3h2eiustncws@treble
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dee55c07
    • Muchun Song's avatar
      mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active · e8022991
      Muchun Song authored
      commit ecbf4724 upstream.
      
      The page_huge_active() can be called from scan_movable_pages() which do
      not hold a reference count to the HugeTLB page.  So when we call
      page_huge_active() from scan_movable_pages(), the HugeTLB page can be
      freed parallel.  Then we will trigger a BUG_ON which is in the
      page_huge_active() when CONFIG_DEBUG_VM is enabled.  Just remove the
      VM_BUG_ON_PAGE.
      
      Link: https://lkml.kernel.org/r/20210115124942.46403-6-songmuchun@bytedance.com
      Fixes: 7e1f049e
      
       ("mm: hugetlb: cleanup using paeg_huge_active()")
      Signed-off-by: default avatarMuchun Song <songmuchun@bytedance.com>
      Reviewed-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarOscar Salvador <osalvador@suse.de>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Yang Shi <shy828301@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e8022991
    • Muchun Song's avatar
      mm: hugetlb: fix a race between isolating and freeing page · c2e8bf37
      Muchun Song authored
      commit 0eb2df2b upstream.
      
      There is a race between isolate_huge_page() and __free_huge_page().
      
        CPU0:                                     CPU1:
      
        if (PageHuge(page))
                                                  put_page(page)
                                                    __free_huge_page(page)
                                                        spin_lock(&hugetlb_lock)
                                                        update_and_free_page(page)
                                                          set_compound_page_dtor(page,
                                                            NULL_COMPOUND_DTOR)
                                                        spin_unlock(&hugetlb_lock)
          isolate_huge_page(page)
            // trigger BUG_ON
            VM_BUG_ON_PAGE(!PageHead(page), page)
            spin_lock(&hugetlb_lock)
            page_huge_active(page)
              // trigger BUG_ON
              VM_BUG_ON_PAGE(!PageHuge(page), page)
            spin_unlock(&hugetlb_lock)
      
      When we isolate a HugeTLB page on CPU0.  Meanwhile, we free it to the
      buddy allocator on CPU1.  Then, we can trigger a BUG_ON on CPU0, because
      it is already freed to the buddy allocator.
      
      Link: https://lkml.kernel.org/r/20210115124942.46403-5-songmuchun@bytedance.com
      Fixes: c8721bbb
      
       ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
      Signed-off-by: default avatarMuchun Song <songmuchun@bytedance.com>
      Reviewed-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarOscar Salvador <osalvador@suse.de>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Yang Shi <shy828301@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2e8bf37
    • Muchun Song's avatar
      mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page · c00e7c90
      Muchun Song authored
      commit 585fc0d2 upstream.
      
      If a new hugetlb page is allocated during fallocate it will not be
      marked as active (set_page_huge_active) which will result in a later
      isolate_huge_page failure when the page migration code would like to
      move that page.  Such a failure would be unexpected and wrong.
      
      Only export set_page_huge_active, just leave clear_page_huge_active as
      static.  Because there are no external users.
      
      Link: https://lkml.kernel.org/r/20210115124942.46403-3-songmuchun@bytedance.com
      Fixes: 70c3547e
      
       (hugetlbfs: add hugetlbfs_fallocate())
      Signed-off-by: default avatarMuchun Song <songmuchun@bytedance.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reviewed-by: default avatarOscar Salvador <osalvador@suse.de>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Yang Shi <shy828301@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c00e7c90
    • Russell King's avatar
      ARM: footbridge: fix dc21285 PCI configuration accessors · 7daa4d7c
      Russell King authored
      commit 39d3454c
      
       upstream.
      
      Building with gcc 4.9.2 reveals a latent bug in the PCI accessors
      for Footbridge platforms, which causes a fatal alignment fault
      while accessing IO memory. Fix this by making the assembly volatile.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7daa4d7c
    • Fengnan Chang's avatar
      mmc: core: Limit retries when analyse of SDIO tuples fails · 2d8debea
      Fengnan Chang authored
      commit f92e04f7
      
       upstream.
      
      When analysing tuples fails we may loop indefinitely to retry. Let's avoid
      this by using a 10s timeout and bail if not completed earlier.
      
      Signed-off-by: default avatarFengnan Chang <fengnanchang@gmail.com>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20210123033230.36442-1-fengnanchang@gmail.com
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d8debea
    • Aurelien Aptel's avatar
      cifs: report error instead of invalid when revalidating a dentry fails · 7a3d11f9
      Aurelien Aptel authored
      commit 21b200d0
      
       upstream.
      
      Assuming
      - //HOST/a is mounted on /mnt
      - //HOST/b is mounted on /mnt/b
      
      On a slow connection, running 'df' and killing it while it's
      processing /mnt/b can make cifs_get_inode_info() returns -ERESTARTSYS.
      
      This triggers the following chain of events:
      => the dentry revalidation fail
      => dentry is put and released
      => superblock associated with the dentry is put
      => /mnt/b is unmounted
      
      This patch makes cifs_d_revalidate() return the error instead of 0
      (invalid) when cifs_revalidate_dentry() fails, except for ENOENT (file
      deleted) and ESTALE (file recreated).
      
      Signed-off-by: default avatarAurelien Aptel <aaptel@suse.com>
      Suggested-by: default avatarShyam Prasad N <nspmangalore@gmail.com>
      Reviewed-by: default avatarShyam Prasad N <nspmangalore@gmail.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a3d11f9
    • Wang ShaoBo's avatar
      kretprobe: Avoid re-registration of the same kretprobe earlier · 05b07625
      Wang ShaoBo authored
      commit 0188b878 upstream.
      
      Our system encountered a re-init error when re-registering same kretprobe,
      where the kretprobe_instance in rp->free_instances is illegally accessed
      after re-init.
      
      Implementation to avoid re-registration has been introduced for kprobe
      before, but lags for register_kretprobe(). We must check if kprobe has
      been re-registered before re-initializing kretprobe, otherwise it will
      destroy the data struct of kretprobe registered, which can lead to memory
      leak, system crash, also some unexpected behaviors.
      
      We use check_kprobe_rereg() to check if kprobe has been re-registered
      before running register_kretprobe()'s body, for giving a warning message
      and terminate registration process.
      
      Link: https://lkml.kernel.org/r/20210128124427.2031088-1-bobo.shaobowang@huawei.com
      
      Cc: stable@vger.kernel.org
      Fixes: 1f0ab409
      
       ("kprobes: Prevent re-registration of the same kprobe")
      [ The above commit should have been done for kretprobes too ]
      Acked-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: default avatarAnanth N Mavinakayanahalli <ananth@linux.ibm.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarWang ShaoBo <bobo.shaobowang@huawei.com>
      Signed-off-by: default avatarCheng Jian <cj.chengjian@huawei.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05b07625
    • Felix Fietkau's avatar
      mac80211: fix station rate table updates on assoc · 70d9dc44
      Felix Fietkau authored
      commit 18fe0fae
      
       upstream.
      
      If the driver uses .sta_add, station entries are only uploaded after the sta
      is in assoc state. Fix early station rate table updates by deferring them
      until the sta has been uploaded.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Link: https://lore.kernel.org/r/20210201083324.3134-1-nbd@nbd.name
      [use rcu_access_pointer() instead since we won't dereference here]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70d9dc44
    • Heiko Stuebner's avatar
      usb: dwc2: Fix endpoint direction check in ep_from_windex · 1ca6fa6c
      Heiko Stuebner authored
      commit f670e9f9 upstream.
      
      dwc2_hsotg_process_req_status uses ep_from_windex() to retrieve
      the endpoint for the index provided in the wIndex request param.
      
      In a test-case with a rndis gadget running and sending a malformed
      packet to it like:
          dev.ctrl_transfer(
              0x82,      # bmRequestType
              0x00,       # bRequest
              0x0000,     # wValue
              0x0001,     # wIndex
              0x00       # wLength
          )
      it is possible to cause a crash:
      
      [  217.533022] dwc2 ff300000.usb: dwc2_hsotg_process_req_status: USB_REQ_GET_STATUS
      [  217.559003] Unable to handle kernel read from unreadable memory at virtual address 0000000000000088
      ...
      [  218.313189] Call trace:
      [  218.330217]  ep_from_windex+0x3c/0x54
      [  218.348565]  usb_gadget_giveback_request+0x10/0x20
      [  218.368056]  dwc2_hsotg_complete_request+0x144/0x184
      
      This happens because ep_from_windex wants to compare the endpoint
      direction even if index_to_ep() didn't return an endpoint due to
      the direction not matching.
      
      The fix is easy insofar that the actual direction check is already
      happening when calling index_to_ep() which will return NULL if there
      is no endpoint for the targeted direction, so the offending check
      can go away completely.
      
      Fixes: c6f5c050
      
       ("usb: dwc2: gadget: add bi-directional endpoint support")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarGerhard Klostermeier <gerhard.klostermeier@syss.de>
      Signed-off-by: default avatarHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
      Link: https://lore.kernel.org/r/20210127103919.58215-1-heiko@sntech.de
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ca6fa6c
    • Jeremy Figgins's avatar
      USB: usblp: don't call usb_set_interface if there's a single alt · 07b40919
      Jeremy Figgins authored
      commit d8c6edfa
      
       upstream.
      
      Some devices, such as the Winbond Electronics Corp. Virtual Com Port
      (Vendor=0416, ProdId=5011), lockup when usb_set_interface() or
      usb_clear_halt() are called. This device has only a single
      altsetting, so it should not be necessary to call usb_set_interface().
      
      Acked-by: default avatarPete Zaitcev <zaitcev@redhat.com>
      Signed-off-by: default avatarJeremy Figgins <kernel@jeremyfiggins.com>
      Link: https://lore.kernel.org/r/YAy9kJhM/rG8EQXC@watson
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07b40919
    • Dan Carpenter's avatar
      USB: gadget: legacy: fix an error code in eth_bind() · 980193e2
      Dan Carpenter authored
      commit 3e1f4a2e upstream.
      
      This code should return -ENOMEM if the allocation fails but it currently
      returns success.
      
      Fixes: 9b95236e
      
       ("usb: gadget: ether: allocate and init otg descriptor by otg capabilities")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Link: https://lore.kernel.org/r/YBKE9rqVuJEOUWpW@mwanda
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      980193e2
    • Arnd Bergmann's avatar
      elfcore: fix building with clang · 3140b074
      Arnd Bergmann authored
      commit 6e7b64b9
      
       upstream.
      
      kernel/elfcore.c only contains weak symbols, which triggers a bug with
      clang in combination with recordmcount:
      
        Cannot find symbol for section 2: .text.
        kernel/elfcore.o: failed
      
      Move the empty stubs into linux/elfcore.h as inline functions.  As only
      two architectures use these, just use the architecture specific Kconfig
      symbols to key off the declaration.
      
      Link: https://lkml.kernel.org/r/20201204165742.3815221-2-arnd@kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Nathan Chancellor <natechancellor@gmail.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Barret Rhoden <brho@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3140b074
    • Ralf Baechle's avatar
      ELF/MIPS build fix · eab1253f
      Ralf Baechle authored
      commit f43edca7
      
       upstream.
      
      CONFIG_MIPS32_N32=y but CONFIG_BINFMT_ELF disabled results in the
      following linker errors:
      
        arch/mips/built-in.o: In function `elf_core_dump':
        binfmt_elfn32.c:(.text+0x23dbc): undefined reference to `elf_core_extra_phdrs'
        binfmt_elfn32.c:(.text+0x246e4): undefined reference to `elf_core_extra_data_size'
        binfmt_elfn32.c:(.text+0x248d0): undefined reference to `elf_core_write_extra_phdrs'
        binfmt_elfn32.c:(.text+0x24ac4): undefined reference to `elf_core_write_extra_data'
      
      CONFIG_MIPS32_O32=y but CONFIG_BINFMT_ELF disabled results in the following
      linker errors:
      
        arch/mips/built-in.o: In function `elf_core_dump':
        binfmt_elfo32.c:(.text+0x28a04): undefined reference to `elf_core_extra_phdrs'
        binfmt_elfo32.c:(.text+0x29330): undefined reference to `elf_core_extra_data_size'
        binfmt_elfo32.c:(.text+0x2951c): undefined reference to `elf_core_write_extra_phdrs'
        binfmt_elfo32.c:(.text+0x29710): undefined reference to `elf_core_write_extra_data'
      
      This is because binfmt_elfn32 and binfmt_elfo32 are using symbols from
      elfcore but for these configurations elfcore will not be built.
      
      Fixed by making elfcore selectable by a separate config symbol which
      unlike the current mechanism can also be used from other directories
      than kernel/, then having each flavor of ELF that relies on elfcore.o,
      select it in Kconfig, including CONFIG_MIPS32_N32 and CONFIG_MIPS32_O32
      which fixes this issue.
      
      Link: http://lkml.kernel.org/r/20160520141705.GA1913@linux-mips.org
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Reviewed-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: "Maciej W. Rozycki" <macro@linux-mips.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eab1253f
    • Xie He's avatar
      net: lapb: Copy the skb before sending a packet · 8b77cafc
      Xie He authored
      [ Upstream commit 88c7a9fd ]
      
      When sending a packet, we will prepend it with an LAPB header.
      This modifies the shared parts of a cloned skb, so we should copy the
      skb rather than just clone it, before we prepend the header.
      
      In "Documentation/networking/driver.rst" (the 2nd point), it states
      that drivers shouldn't modify the shared parts of a cloned skb when
      transmitting.
      
      The "dev_queue_xmit_nit" function in "net/core/dev.c", which is called
      when an skb is being sent, clones the skb and sents the clone to
      AF_PACKET sockets. Because the LAPB drivers first remove a 1-byte
      pseudo-header before handing over the skb to us, if we don't copy the
      skb before prepending the LAPB header, the first byte of the packets
      received on AF_PACKET sockets can be corrupted.
      
      Fixes: 1da177e4
      
       ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Acked-by: default avatarMartin Schiller <ms@dev.tdt.de>
      Link: https://lore.kernel.org/r/20210201055706.415842-1-xie.he.0141@gmail.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8b77cafc
    • Alexey Dobriyan's avatar
      Input: i8042 - unbreak Pegatron C15B · 0d60f5b6
      Alexey Dobriyan authored
      [ Upstream commit a3a9060e ]
      
      g++ reports
      
      	drivers/input/serio/i8042-x86ia64io.h:225:3: error: ‘.matches’ designator used multiple times in the same initializer list
      
      C99 semantics is that last duplicated initialiser wins,
      so DMI entry gets overwritten.
      
      Fixes: a48491c6
      
       ("Input: i8042 - add ByteSpeed touchpad to noloop table")
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Acked-by: default avatarPo-Hsu Lin <po-hsu.lin@canonical.com>
      Link: https://lore.kernel.org/r/20201228072335.GA27766@localhost.localdomain
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0d60f5b6
    • Christoph Schemmel's avatar
      USB: serial: option: Adding support for Cinterion MV31 · 48eed97f
      Christoph Schemmel authored
      commit e478d602
      
       upstream.
      
      Adding support for Cinterion device MV31 for enumeration with
      PID 0x00B3 and 0x00B7.
      
      usb-devices output for 0x00B3
      T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=5000 MxCh= 0
      D:  Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
      P:  Vendor=1e2d ProdID=00b3 Rev=04.14
      S:  Manufacturer=Cinterion
      S:  Product=Cinterion PID 0x00B3 USB Mobile Broadband
      S:  SerialNumber=b3246eed
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
      I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
      I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=cdc_wdm
      I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
      
      usb-devices output for 0x00B7
      T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=5000 MxCh= 0
      D:  Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
      P:  Vendor=1e2d ProdID=00b7 Rev=04.14
      S:  Manufacturer=Cinterion
      S:  Product=Cinterion PID 0x00B3 USB Mobile Broadband
      S:  SerialNumber=b3246eed
      C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=896mA
      I:  If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
      
      Signed-off-by: default avatarChristoph Schemmel <christoph.schemmel@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48eed97f
    • Chenxin Jin's avatar
      USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000 · 4f98b0a9
      Chenxin Jin authored
      commit 43377df7
      
       upstream.
      
      Teraoka AD2000 uses the CP210x driver, but the chip VID/PID is
      customized with 0988/0578. We need the driver to support the new
      VID/PID.
      
      Signed-off-by: default avatarChenxin Jin <bg4akv@hotmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f98b0a9
    • Pho Tran's avatar
      USB: serial: cp210x: add pid/vid for WSDA-200-USB · 545d8354
      Pho Tran authored
      commit 3c4f6ecd
      
       upstream.
      
      Information pid/vid of WSDA-200-USB, Lord corporation company:
      vid: 199b
      pid: ba30
      
      Signed-off-by: default avatarPho Tran <pho.tran@silabs.com>
      [ johan: amend comment with product name ]
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      545d8354
    • Sasha Levin's avatar
      stable: clamp SUBLEVEL in 4.4 and 4.9 · a15813a8
      Sasha Levin authored
      
      
      Right now SUBLEVEL is overflowing, and some userspace may start treating
      4.9.256 as 4.10. While out of tree modules have different ways of
        extracting the version number (and we're generally ok with breaking
      them), we do care about breaking userspace and it would appear that this
      overflow might do just that.
      
      Our rules around userspace ABI in the stable kernel are pretty simple:
      we don't break it. Thus, while userspace may be checking major/minor, it
      shouldn't be doing anything with sublevel.
      
      This patch applies a big band-aid to the 4.9 and 4.4 kernels in the form
      of clamping their sublevel to 255.
      
      The clamp is done for the purpose of LINUX_VERSION_CODE only, and
      extracting the version number from the Makefile or "make kernelversion"
      will continue to work as intended.
      
      We might need to do it later in newer trees, but maybe we'll have a
      better solution by then, so I'm ignoring that problem for now.
      
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a15813a8
    • Brian King's avatar
      scsi: ibmvfc: Set default timeout to avoid crash during migration · dbf37a41
      Brian King authored
      [ Upstream commit 76490729
      
       ]
      
      While testing live partition mobility, we have observed occasional crashes
      of the Linux partition. What we've seen is that during the live migration,
      for specific configurations with large amounts of memory, slow network
      links, and workloads that are changing memory a lot, the partition can end
      up being suspended for 30 seconds or longer. This resulted in the following
      scenario:
      
      CPU 0                          CPU 1
      -------------------------------  ----------------------------------
      scsi_queue_rq                    migration_store
       -> blk_mq_start_request          -> rtas_ibm_suspend_me
        -> blk_add_timer                 -> on_each_cpu(rtas_percpu_suspend_me
                    _______________________________________V
                   |
                   V
          -> IPI from CPU 1
           -> rtas_percpu_suspend_me
                                           -> __rtas_suspend_last_cpu
      
      -- Linux partition suspended for > 30 seconds --
                                            -> for_each_online_cpu(cpu)
                                                 plpar_hcall_norets(H_PROD
       -> scsi_dispatch_cmd
                                            -> scsi_times_out
                                             -> scsi_abort_command
                                              -> queue_delayed_work
        -> ibmvfc_queuecommand_lck
         -> ibmvfc_send_event
          -> ibmvfc_send_crq
           - returns H_CLOSED
         <- returns SCSI_MLQUEUE_HOST_BUSY
      -> __blk_mq_requeue_request
      
                                            -> scmd_eh_abort_handler
                                             -> scsi_try_to_abort_cmd
                                               - returns SUCCESS
                                             -> scsi_queue_insert
      
      Normally, the SCMD_STATE_COMPLETE bit would protect against the command
      completion and the timeout, but that doesn't work here, since we don't
      check that at all in the SCSI_MLQUEUE_HOST_BUSY path.
      
      In this case we end up calling scsi_queue_insert on a request that has
      already been queued, or possibly even freed, and we crash.
      
      The patch below simply increases the default I/O timeout to avoid this race
      condition. This is also the timeout value that nearly all IBM SAN storage
      recommends setting as the default value.
      
      Link: https://lore.kernel.org/r/1610463998-19791-1-git-send-email-brking@linux.vnet.ibm.com
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dbf37a41
    • Javed Hasan's avatar
      scsi: libfc: Avoid invoking response handler twice if ep is already completed · 82035511
      Javed Hasan authored
      [ Upstream commit b2b0f16f
      
       ]
      
      A race condition exists between the response handler getting called because
      of exchange_mgr_reset() (which clears out all the active XIDs) and the
      response we get via an interrupt.
      
      Sequence of events:
      
      	 rport ba0200: Port timeout, state PLOGI
      	 rport ba0200: Port entered PLOGI state from PLOGI state
      	 xid 1052: Exchange timer armed : 20000 msecs      xid timer armed here
      	 rport ba0200: Received LOGO request while in state PLOGI
      	 rport ba0200: Delete port
      	 rport ba0200: work event 3
      	 rport ba0200: lld callback ev 3
      	 bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
      	 bnx2fc: ba0200 - rport not created Yet!!
      	 /* Here we reset any outstanding exchanges before
      	 freeing rport using the exch_mgr_reset() */
      	 xid 1052: Exchange timer canceled
      	 /* Here we got two responses for one xid */
      	 xid 1052: invoking resp(), esb 20000000 state 3
      	 xid 1052: invoking resp(), esb 20000000 state 3
      	 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
      	 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
      
      Skip the response if the exchange is already completed.
      
      Link: https://lore.kernel.org/r/20201215194731.2326-1-jhasan@marvell.com
      Signed-off-by: default avatarJaved Hasan <jhasan@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      82035511
    • Thinh Nguyen's avatar
      usb: udc: core: Use lock when write to soft_connect · f42ee7b5
      Thinh Nguyen authored
      commit c28095bc upstream
      
      Use lock to guard against concurrent access for soft-connect/disconnect
      operations when writing to soft_connect sysfs.
      
      Fixes: 2ccea03a
      
       ("usb: gadget: introduce UDC Class")
      Cc: stable@vger.kernel.org
      Acked-by: default avatarFelipe Balbi <balbi@kernel.org>
      Signed-off-by: default avatarThinh Nguyen <Thinh.Nguyen@synopsys.com>
      Link: https://lore.kernel.org/r/338ea01fbd69b1985ef58f0f59af02c805ddf189.1610611437.git.Thinh.Nguyen@synopsys.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [sudip: manual backporting to old file]
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f42ee7b5
    • Lee Jones's avatar
      futex: Handle faults correctly for PI futexes · 46358277
      Lee Jones authored
      From: Thomas Gleixner <tglx@linutronix.de>
      
      fixup_pi_state_owner() tries to ensure that the state of the rtmutex,
      pi_state and the user space value related to the PI futex are consistent
      before returning to user space. In case that the user space value update
      faults and the fault cannot be resolved by faulting the page in via
      fault_in_user_writeable() the function returns with -EFAULT and leaves
      the rtmutex and pi_state owner state inconsistent.
      
      A subsequent futex_unlock_pi() operates on the inconsistent pi_state and
      releases the rtmutex despite not owning it which can corrupt the RB tree of
      the rtmutex and cause a subsequent kernel stack use after free.
      
      It was suggested to loop forever in fixup_pi_state_owner() if the fault
      cannot be resolved, but that results in runaway tasks which is especially
      undesired when the problem happens due to a programming error and not due
      to malice.
      
      As the user space value cannot be fixed up, the proper solution is to make
      the rtmutex and the pi_state consistent so both have the same owner. This
      leaves the user space value out of sync. Any subsequent operation on the
      futex will fail because the 10th rule of PI futexes (pi_state owner and
      user space value are consistent) has been violated.
      
      As a consequence this removes the inept attempts of 'fixing' the situation
      in case that the current task owns the rtmutex when returning with an
      unresolvable fault by unlocking the rtmutex which left pi_state::owner and
      rtmutex::owner out of sync in a different and only slightly less dangerous
      way.
      
      Fixes: 1b7558e4
      
       ("futexes: fix fault handling in futex_lock_pi")
      Reported-by: default avatar <gzobqq@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46358277
    • Lee Jones's avatar
      futex: Simplify fixup_pi_state_owner() · 47e452fc
      Lee Jones authored
      From: Thomas Gleixner <tglx@linutronix.de>
      
      [ Upstream commit f2dac39d
      
       ]
      
      Too many gotos already and an upcoming fix would make it even more
      unreadable.
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47e452fc
    • Lee Jones's avatar
      futex: Use pi_state_update_owner() in put_pi_state() · f08a4af5
      Lee Jones authored
      From: Thomas Gleixner <tglx@linutronix.de>
      
      [ Upstream commit 6ccc84f9
      
       ]
      
      No point in open coding it. This way it gains the extra sanity checks.
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f08a4af5
    • Lee Jones's avatar
      rtmutex: Remove unused argument from rt_mutex_proxy_unlock() · 42255927
      Lee Jones authored
      From: Thomas Gleixner <tglx@linutronix.de>
      
      [ Upstream commit 2156ac19
      
       ]
      Nothing uses the argument. Remove it as preparation to use
      pi_state_update_owner().
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42255927
    • Lee Jones's avatar
      futex: Provide and use pi_state_update_owner() · 34c8e1c2
      Lee Jones authored
      From: Thomas Gleixner <tglx@linutronix.de>
      
      [ Upstream commit c5cade20
      
       ]
      
      Updating pi_state::owner is done at several places with the same
      code. Provide a function for it and use that at the obvious places.
      
      This is also a preparation for a bug fix to avoid yet another copy of the
      same code or alternatively introducing a completely unpenetratable mess of
      gotos.
      
      Originally-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      34c8e1c2
    • Lee Jones's avatar
      futex: Replace pointless printk in fixup_owner() · 3edf5f2a
      Lee Jones authored
      From: Thomas Gleixner <tglx@linutronix.de>
      
      [ Upstream commit 04b79c55
      
       ]
      
      If that unexpected case of inconsistent arguments ever happens then the
      futex state is left completely inconsistent and the printk is not really
      helpful. Replace it with a warning and make the state consistent.
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3edf5f2a
    • Lee Jones's avatar
      futex: Avoid violating the 10th rule of futex · ad4740ce
      Lee Jones authored
      From: Peter Zijlstra <peterz@infradead.org>
      
      commit c1e2f0ea upstream.
      
      Julia reported futex state corruption in the following scenario:
      
         waiter                                  waker                                            stealer (prio > waiter)
      
         futex(WAIT_REQUEUE_PI, uaddr, uaddr2,
               timeout=[N ms])
            futex_wait_requeue_pi()
               futex_wait_queue_me()
                  freezable_schedule()
                  <scheduled out>
                                                 futex(LOCK_PI, uaddr2)
                                                 futex(CMP_REQUEUE_PI, uaddr,
                                                       uaddr2, 1, 0)
                                                    /* requeues waiter to uaddr2 */
                                                 futex(UNLOCK_PI, uaddr2)
                                                       wake_futex_pi()
                                                          cmp_futex_value_locked(uaddr2, waiter)
                                                          wake_up_q()
                 <woken by waker>
                 <hrtimer_wakeup() fires,
                  clears sleeper->task>
                                                                                                 futex(LOCK_PI, uaddr2)
                                                                                                    __rt_mutex_start_proxy_lock()
                                                                                                       try_to_take_rt_mutex() /* steals lock */
                                                                                                          rt_mutex_set_owner(lock, stealer)
                                                                                                    <preempted>
               <scheduled in>
               rt_mutex_wait_proxy_lock()
                  __rt_mutex_slowlock()
                     try_to_take_rt_mutex() /* fails, lock held by stealer */
                     if (timeout && !timeout->task)
                        return -ETIMEDOUT;
                  fixup_owner()
                     /* lock wasn't acquired, so,
                        fixup_pi_state_owner skipped */
      
         return -ETIMEDOUT;
      
         /* At this point, we've returned -ETIMEDOUT to userspace, but the
          * futex word shows waiter to be the owner, and the pi_mutex has
          * stealer as the owner */
      
         futex_lock(LOCK_PI, uaddr2)
           -> bails with EDEADLK, futex word says we're owner.
      
      And suggested that what commit:
      
        73d786bd ("futex: Rework inconsistent rt_mutex/futex_q state")
      
      removes from fixup_owner() looks to be just what is needed. And indeed
      it is -- I completely missed that requeue_pi could also result in this
      case. So we need to restore that, except that subsequent patches, like
      commit:
      
        16ffa12d ("futex: Pull rt_mutex_futex_unlock() out from under hb->lock")
      
      changed all the locking rules. Even without that, the sequence:
      
      -               if (rt_mutex_futex_trylock(&q->pi_state->pi_mutex)) {
      -                       locked = 1;
      -                       goto out;
      -               }
      
      -               raw_spin_lock_irq(&q->pi_state->pi_mutex.wait_lock);
      -               owner = rt_mutex_owner(&q->pi_state->pi_mutex);
      -               if (!owner)
      -                       owner = rt_mutex_next_owner(&q->pi_state->pi_mutex);
      -               raw_spin_unlock_irq(&q->pi_state->pi_mutex.wait_lock);
      -               ret = fixup_pi_state_owner(uaddr, q, owner);
      
      already suggests there were races; otherwise we'd never have to look
      at next_owner.
      
      So instead of doing 3 consecutive wait_lock sections with who knows
      what races, we do it all in a single section. Additionally, the usage
      of pi_state->owner in fixup_owner() was only safe because only the
      rt_mutex owner would modify it, which this additional case wrecks.
      
      Luckily the values can only change away and not to the value we're
      testing, this means we can do a speculative test and double check once
      we have the wait_lock.
      
      Fixes: 73d786bd
      
       ("futex: Rework inconsistent rt_mutex/futex_q state")
      Reported-by: default avatarJulia Cartwright <julia@ni.com>
      Reported-by: default avatarGratian Crisan <gratian.crisan@ni.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarJulia Cartwright <julia@ni.com>
      Tested-by: default avatarGratian Crisan <gratian.crisan@ni.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Link: https://lkml.kernel.org/r/20171208124939.7livp7no2ov65rrc@hirez.programming.kicks-ass.net
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [Lee: Back-ported to solve a dependency]
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad4740ce
    • Lee Jones's avatar
      futex: Rework inconsistent rt_mutex/futex_q state · 394fc498
      Lee Jones authored
      From: Peter Zijlstra <peterz@infradead.org>
      
      [Upstream commit 73d786bd
      
       ]
      
      There is a weird state in the futex_unlock_pi() path when it interleaves
      with a concurrent futex_lock_pi() at the point where it drops hb->lock.
      
      In this case, it can happen that the rt_mutex wait_list and the futex_q
      disagree on pending waiters, in particular rt_mutex will find no pending
      waiters where futex_q thinks there are. In this case the rt_mutex unlock
      code cannot assign an owner.
      
      The futex side fixup code has to cleanup the inconsistencies with quite a
      bunch of interesting corner cases.
      
      Simplify all this by changing wake_futex_pi() to return -EAGAIN when this
      situation occurs. This then gives the futex_lock_pi() code the opportunity
      to continue and the retried futex_unlock_pi() will now observe a coherent
      state.
      
      The only problem is that this breaks RT timeliness guarantees. That
      is, consider the following scenario:
      
        T1 and T2 are both pinned to CPU0. prio(T2) > prio(T1)
      
          CPU0
      
          T1
            lock_pi()
            queue_me()  <- Waiter is visible
      
          preemption
      
          T2
            unlock_pi()
      	loops with -EAGAIN forever
      
      Which is undesirable for PI primitives. Future patches will rectify
      this.
      
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: juri.lelli@arm.com
      Cc: bigeasy@linutronix.de
      Cc: xlpang@redhat.com
      Cc: rostedt@goodmis.org
      Cc: mathieu.desnoyers@efficios.com
      Cc: jdesfossez@efficios.com
      Cc: dvhart@infradead.org
      Cc: bristot@redhat.com
      Link: http://lkml.kernel.org/r/20170322104151.850383690@infradead.org
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      [Lee: Back-ported to solve a dependency]
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      394fc498
    • Lee Jones's avatar
      futex: Remove rt_mutex_deadlock_account_*() · fd7924d6
      Lee Jones authored
      
      
      From: Peter Zijlstra <peterz@infradead.org>
      
      These are unused and clutter up the code.
      
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: juri.lelli@arm.com
      Cc: bigeasy@linutronix.de
      Cc: xlpang@redhat.com
      Cc: rostedt@goodmis.org
      Cc: mathieu.desnoyers@efficios.com
      Cc: jdesfossez@efficios.com
      Cc: dvhart@infradead.org
      Cc: bristot@redhat.com
      Link: http://lkml.kernel.org/r/20170322104151.652692478@infradead.org
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      [Lee: Back-ported to solve a dependency]
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd7924d6
    • Lee Jones's avatar
      futex,rt_mutex: Provide futex specific rt_mutex API · 6510e4a2
      Lee Jones authored
      From: Peter Zijlstra <peterz@infradead.org>
      
      [ Upstream commit 5293c2ef
      
       ]
      
      Part of what makes futex_unlock_pi() intricate is that
      rt_mutex_futex_unlock() -> rt_mutex_slowunlock() can drop
      rt_mutex::wait_lock.
      
      This means it cannot rely on the atomicy of wait_lock, which would be
      preferred in order to not rely on hb->lock so much.
      
      The reason rt_mutex_slowunlock() needs to drop wait_lock is because it can
      race with the rt_mutex fastpath, however futexes have their own fast path.
      
      Since futexes already have a bunch of separate rt_mutex accessors, complete
      that set and implement a rt_mutex variant without fastpath for them.
      
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: juri.lelli@arm.com
      Cc: bigeasy@linutronix.de
      Cc: xlpang@redhat.com
      Cc: rostedt@goodmis.org
      Cc: mathieu.desnoyers@efficios.com
      Cc: jdesfossez@efficios.com
      Cc: dvhart@infradead.org
      Cc: bristot@redhat.com
      Link: http://lkml.kernel.org/r/20170322104151.702962446@infradead.org
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      [Lee: Back-ported to solve a dependency]
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6510e4a2
    • Eric Dumazet's avatar
      net_sched: reject silly cell_log in qdisc_get_rtab() · 3dee3a42
      Eric Dumazet authored
      commit e4bedf48 upstream
      
      iproute2 probably never goes beyond 8 for the cell exponent,
      but stick to the max shift exponent for signed 32bit.
      
      UBSAN reported:
      UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22
      shift exponent 130 is too large for 32-bit type 'int'
      CPU: 1 PID: 8450 Comm: syz-executor586 Not tainted 5.11.0-rc3-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:79 [inline]
       dump_stack+0x183/0x22e lib/dump_stack.c:120
       ubsan_epilogue lib/ubsan.c:148 [inline]
       __ubsan_handle_shift_out_of_bounds+0x432/0x4d0 lib/ubsan.c:395
       __detect_linklayer+0x2a9/0x330 net/sched/sch_api.c:389
       qdisc_get_rtab+0x2b5/0x410 net/sched/sch_api.c:435
       cbq_init+0x28f/0x12c0 net/sched/sch_cbq.c:1180
       qdisc_create+0x801/0x1470 net/sched/sch_api.c:1246
       tc_modify_qdisc+0x9e3/0x1fc0 net/sched/sch_api.c:1662
       rtnetlink_rcv_msg+0xb1d/0xe60 net/core/rtnetlink.c:5564
       netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2494
       netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
       netlink_unicast+0x7de/0x9b0 net/netlink/af_netlink.c:1330
       netlink_sendmsg+0xaa6/0xe90 net/netlink/af_netlink.c:1919
       sock_sendmsg_nosec net/socket.c:652 [inline]
       sock_sendmsg net/socket.c:672 [inline]
       ____sys_sendmsg+0x5a2/0x900 net/socket.c:2345
       ___sys_sendmsg net/socket.c:2399 [inline]
       __sys_sendmsg+0x319/0x400 net/socket.c:2432
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 1da177e4
      
       ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarCong Wang <cong.wang@bytedance.com>
      Link: https://lore.kernel.org/r/20210114160637.1660597-1-eric.dumazet@gmail.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      [sudip: adjust context]
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3dee3a42
  2. Feb 05, 2021
  3. Feb 04, 2021