1. 06 Jun, 2016 30 commits
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Move recursive check to per_cpu descriptor · d6bdff22
      Steven Rostedt (Red Hat) authored
      [ Upstream commit 58a09ec6 ]
      
      Instead of using a global per_cpu variable to perform the recursive
      checks into the ring buffer, use the already existing per_cpu descriptor
      that is part of the ring buffer itself.
      
      Not only does this simplify the code, it also allows for one ring buffer
      to be used within the guts of the use of another ring buffer. For example
      trace_printk() can now be used within the ring buffer to record changes
      done by an instance into the main ring buffer. The recursion checks
      will prevent the trace_printk() itself from causing recursive issues
      with the main ring buffer (it is just ignored), but the recursive
      checks wont prevent the trace_printk() from recording other ring buffers.
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d6bdff22
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Add unlikelys to make fast path the default · ac4e03df
      Steven Rostedt (Red Hat) authored
      [ Upstream commit 3205f806 ]
      
      I was running the trace_event benchmark and noticed that the times
      to record a trace_event was all over the place. I looked at the assembly
      of the ring_buffer_lock_reserver() and saw this:
      
       <ring_buffer_lock_reserve>:
             31 c0                   xor    %eax,%eax
             48 83 3d 76 47 bd 00    cmpq   $0x1,0xbd4776(%rip)        # ffffffff81d10d60 <ring_buffer_flags>
             01
             55                      push   %rbp
             48 89 e5                mov    %rsp,%rbp
             75 1d                   jne    ffffffff8113c60d <ring_buffer_lock_reserve+0x2d>
             65 ff 05 69 e3 ec 7e    incl   %gs:0x7eece369(%rip)        # a960 <__preempt_count>
             8b 47 08                mov    0x8(%rdi),%eax
             85 c0                   test   %eax,%eax
       +---- 74 12                   je     ffffffff8113c610 <ring_buffer_lock_reserve+0x30>
       |     65 ff 0d 5b e3 ec 7e    decl   %gs:0x7eece35b(%rip)        # a960 <__preempt_count>
       |     0f 84 85 00 00 00       je     ffffffff8113c690 <ring_buffer_lock_reserve+0xb0>
       |     31 c0                   xor    %eax,%eax
       |     5d                      pop    %rbp
       |     c3                      retq
       |     90                      nop
       +---> 65 44 8b 05 48 e3 ec    mov    %gs:0x7eece348(%rip),%r8d        # a960 <__preempt_count>
             7e
             41 81 e0 ff ff ff 7f    and    $0x7fffffff,%r8d
             b0 08                   mov    $0x8,%al
             65 8b 0d 58 36 ed 7e    mov    %gs:0x7eed3658(%rip),%ecx        # fc80 <current_context>
             41 f7 c0 00 ff 1f 00    test   $0x1fff00,%r8d
             74 1e                   je     ffffffff8113c64f <ring_buffer_lock_reserve+0x6f>
             41 f7 c0 00 00 10 00    test   $0x100000,%r8d
             b0 01                   mov    $0x1,%al
             75 13                   jne    ffffffff8113c64f <ring_buffer_lock_reserve+0x6f>
             41 81 e0 00 00 0f 00    and    $0xf0000,%r8d
             49 83 f8 01             cmp    $0x1,%r8
             19 c0                   sbb    %eax,%eax
             83 e0 02                and    $0x2,%eax
             83 c0 02                add    $0x2,%eax
             85 c8                   test   %ecx,%eax
             75 ab                   jne    ffffffff8113c5fe <ring_buffer_lock_reserve+0x1e>
             09 c8                   or     %ecx,%eax
             65 89 05 24 36 ed 7e    mov    %eax,%gs:0x7eed3624(%rip)        # fc80 <current_context>
      
      The arrow is the fast path.
      
      After adding the unlikely's, the fast path looks a bit better:
      
       <ring_buffer_lock_reserve>:
             31 c0                   xor    %eax,%eax
             48 83 3d 76 47 bd 00    cmpq   $0x1,0xbd4776(%rip)        # ffffffff81d10d60 <ring_buffer_flags>
             01
             55                      push   %rbp
             48 89 e5                mov    %rsp,%rbp
             75 7b                   jne    ffffffff8113c66b <ring_buffer_lock_reserve+0x8b>
             65 ff 05 69 e3 ec 7e    incl   %gs:0x7eece369(%rip)        # a960 <__preempt_count>
             8b 47 08                mov    0x8(%rdi),%eax
             85 c0                   test   %eax,%eax
             0f 85 9f 00 00 00       jne    ffffffff8113c6a1 <ring_buffer_lock_reserve+0xc1>
             65 8b 0d 57 e3 ec 7e    mov    %gs:0x7eece357(%rip),%ecx        # a960 <__preempt_count>
             81 e1 ff ff ff 7f       and    $0x7fffffff,%ecx
             b0 08                   mov    $0x8,%al
             65 8b 15 68 36 ed 7e    mov    %gs:0x7eed3668(%rip),%edx        # fc80 <current_context>
             f7 c1 00 ff 1f 00       test   $0x1fff00,%ecx
             75 50                   jne    ffffffff8113c670 <ring_buffer_lock_reserve+0x90>
             85 d0                   test   %edx,%eax
             75 7d                   jne    ffffffff8113c6a1 <ring_buffer_lock_reserve+0xc1>
             09 d0                   or     %edx,%eax
             65 89 05 53 36 ed 7e    mov    %eax,%gs:0x7eed3653(%rip)        # fc80 <current_context>
             65 8b 05 fc da ec 7e    mov    %gs:0x7eecdafc(%rip),%eax        # a130 <cpu_number>
             89 c2                   mov    %eax,%edx
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ac4e03df
    • Paul Burton's avatar
      MIPS: Disable preemption during prctl(PR_SET_FP_MODE, ...) · daf7322b
      Paul Burton authored
      [ Upstream commit bd239f1e ]
      
      Whilst a PR_SET_FP_MODE prctl is performed there are decisions made
      based upon whether the task is executing on the current CPU. This may
      change if we're preempted, so disable preemption to avoid such changes
      for the lifetime of the mode switch.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Fixes: 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
      Reviewed-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Tested-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: stable <stable@vger.kernel.org> # v4.0+
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13144/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      daf7322b
    • Maciej W. Rozycki's avatar
      MIPS: ptrace: Prevent writes to read-only FCSR bits · 49dc90fd
      Maciej W. Rozycki authored
      [ Upstream commit abf378be ]
      
      Correct the cases missed with commit 9b26616c ("MIPS: Respect the
      ISA level in FCSR handling") and prevent writes to read-only FCSR bits
      there.
      
      This in particular applies to FP context initialisation where any IEEE
      754-2008 bits preset by `mips_set_personality_nan' are cleared before
      the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request
      addressing FPC_CSR where no masking of read-only FCSR bits is done.
      
      Remove the FCSR clearing from FP context initialisation then and unify
      PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out
      code from `ptrace_setfpregs' and calling it from both places.
      
      This mostly matters to soft float configurations where the emulator can
      be switched this way to a mode which should not be accessible and cannot
      be set with the CTC1 instruction.  With hard float configurations any
      effect is transient anyway as read-only bits will retain their values at
      the time the FP context is restored.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Cc: stable@vger.kernel.org # v4.0+
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13239/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      49dc90fd
    • Maciej W. Rozycki's avatar
      MIPS: ptrace: Fix FP context restoration FCSR regression · ba1ccd8e
      Maciej W. Rozycki authored
      [ Upstream commit 42495484 ]
      
      Fix a floating-point context restoration regression introduced with
      commit 9b26616c ("MIPS: Respect the ISA level in FCSR handling")
      that causes a Floating Point exception and consequently a kernel oops
      with hard float configurations when one or more FCSR Enable and their
      corresponding Cause bits are set both at a time via a ptrace(2) call.
      
      To do so reinstate Cause bit masking originally introduced with commit
      b1442d39 ("MIPS: Prevent user from setting FCSR cause bits") to
      address this exact problem and then inadvertently removed from the
      PTRACE_SETFPREGS request with the commit referred above.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Cc: stable@vger.kernel.org # v4.0+
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13238/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ba1ccd8e
    • Paul Burton's avatar
      MIPS: math-emu: Fix jalr emulation when rd == $0 · fc39f274
      Paul Burton authored
      [ Upstream commit ab4a92e6 ]
      
      When emulating a jalr instruction with rd == $0, the code in
      isBranchInstr was incorrectly writing to GPR $0 which should actually
      always remain zeroed. This would lead to any further instructions
      emulated which use $0 operating on a bogus value until the task is next
      context switched, at which point the value of $0 in the task context
      would be restored to the correct zero by a store in SAVE_SOME. Fix this
      by not writing to rd if it is $0.
      
      Fixes: 102cedc3 ("MIPS: microMIPS: Floating point support.")
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Maciej W. Rozycki <macro@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable <stable@vger.kernel.org> # v3.10
      Patchwork: https://patchwork.linux-mips.org/patch/13160/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fc39f274
    • James Hogan's avatar
      MIPS: Fix uapi include in exported asm/siginfo.h · 4a16f41b
      James Hogan authored
      [ Upstream commit 987e5b83 ]
      
      Since commit 8cb48fe1 ("MIPS: Provide correct siginfo_t.si_stime"),
      MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h
      directly before defining MIPS' struct siginfo, in order to get the
      necessary definitions needed for the siginfo struct without the generic
      copy_siginfo() hitting compiler errors due to struct siginfo not yet
      being defined.
      
      Now that the generic copy_siginfo() is moved out to linux/signal.h we
      can safely include asm-generic/siginfo.h before defining the MIPS
      specific struct siginfo, which avoids the uapi/ include as well as
      breakage due to generic copy_siginfo() being defined before struct
      siginfo.
      Reported-by: default avatarChristopher Ferris <cferris@google.com>
      Fixes: 8cb48fe1 ("MIPS: Provide correct siginfo_t.si_stime")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Petr Malat <oss@malat.biz>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 4.0-
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4a16f41b
    • James Hogan's avatar
      SIGNAL: Move generic copy_siginfo() to signal.h · 175c6485
      James Hogan authored
      [ Upstream commit ca9eb49a ]
      
      The generic copy_siginfo() is currently defined in
      asm-generic/siginfo.h, after including uapi/asm-generic/siginfo.h which
      defines the generic struct siginfo. However this makes it awkward for an
      architecture to use it if it has to define its own struct siginfo (e.g.
      MIPS and potentially IA64), since it means that asm-generic/siginfo.h
      can only be included after defining the arch-specific siginfo, which may
      be problematic if the arch-specific definition needs definitions from
      uapi/asm-generic/siginfo.h.
      
      It is possible to work around this by first including
      uapi/asm-generic/siginfo.h to get the constants before defining the
      arch-specific siginfo, and include asm-generic/siginfo.h after. However
      uapi headers can't be included by other uapi headers, so that first
      include has to be in an ifdef __kernel__, with the non __kernel__ case
      including the non-UAPI header instead.
      
      Instead of that mess, move the generic copy_siginfo() definition into
      linux/signal.h, which allows an arch-specific uapi/asm/siginfo.h to
      include asm-generic/siginfo.h and define the arch-specific siginfo, and
      for the generic copy_siginfo() to see that arch-specific definition.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Petr Malat <oss@malat.biz>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Christopher Ferris <cferris@google.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 4.0-
      Patchwork: https://patchwork.linux-mips.org/patch/12478/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      175c6485
    • Paul Burton's avatar
      MIPS: Sync icache & dcache in set_pte_at · de444b25
      Paul Burton authored
      [ Upstream commit 37d22a0d ]
      
      It's possible for pages to become visible prior to update_mmu_cache
      running if a thread within the same address space preempts the current
      thread or runs simultaneously on another CPU. That is, the following
      scenario is possible:
      
          CPU0                            CPU1
      
          write to page
          flush_dcache_page
          flush_icache_page
          set_pte_at
                                          map page
          update_mmu_cache
      
      If CPU1 maps the page in between CPU0's set_pte_at, which marks it valid
      & visible, and update_mmu_cache where the dcache flush occurs then CPU1s
      icache will fill from stale data (unless it fills from the dcache, in
      which case all is good, but most MIPS CPUs don't have this property).
      Commit 4d46a67a ("MIPS: Fix race condition in lazy cache flushing.")
      attempted to fix that by performing the dcache flush in
      flush_icache_page such that it occurs before the set_pte_at call makes
      the page visible. However it has the problem that not all code that
      writes to pages exposed to userland call flush_icache_page. There are
      many callers of set_pte_at under mm/ and only 2 of them do call
      flush_icache_page. Thus the race window between a page becoming visible
      & being coherent between the icache & dcache remains open in some cases.
      
      To illustrate some of the cases, a WARN was added to __update_cache with
      this patch applied that triggered in cases where a page about to be
      flushed from the dcache was not the last page provided to
      flush_icache_page. That is, backtraces were obtained for cases in which
      the race window is left open without this patch. The 2 standout examples
      follow.
      
      When forking a process:
      
      [   15.271842] [<80417630>] __update_cache+0xcc/0x188
      [   15.277274] [<80530394>] copy_page_range+0x56c/0x6ac
      [   15.282861] [<8042936c>] copy_process.part.54+0xd40/0x17ac
      [   15.289028] [<80429f80>] do_fork+0xe4/0x420
      [   15.293747] [<80413808>] handle_sys+0x128/0x14c
      
      When exec'ing an ELF binary:
      
      [   14.445964] [<80417630>] __update_cache+0xcc/0x188
      [   14.451369] [<80538d88>] move_page_tables+0x414/0x498
      [   14.457075] [<8055d848>] setup_arg_pages+0x220/0x318
      [   14.462685] [<805b0f38>] load_elf_binary+0x530/0x12a0
      [   14.468374] [<8055ec3c>] search_binary_handler+0xbc/0x214
      [   14.474444] [<8055f6c0>] do_execveat_common+0x43c/0x67c
      [   14.480324] [<8055f938>] do_execve+0x38/0x44
      [   14.485137] [<80413808>] handle_sys+0x128/0x14c
      
      These code paths write into a page, call flush_dcache_page then call
      set_pte_at without flush_icache_page inbetween. The end result is that
      the icache can become corrupted & userland processes may execute
      unexpected or invalid code, typically resulting in a reserved
      instruction exception, a trap or a segfault.
      
      Fix this race condition fully by performing any cache maintenance
      required to keep the icache & dcache in sync in set_pte_at, before the
      page is made valid. This has the added bonus of ensuring the cache
      maintenance always happens in one location, rather than being duplicated
      in flush_icache_page & update_mmu_cache. It also matches the way other
      architectures solve the same problem (see arm, ia64 & powerpc).
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Reported-by: default avatarIonela Voinescu <ionela.voinescu@imgtec.com>
      Cc: Lars Persson <lars.persson@axis.com>
      Fixes: 4d46a67a ("MIPS: Fix race condition in lazy cache flushing.")
      Cc: Steven J. Hill <sjhill@realitydiluted.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable <stable@vger.kernel.org> # v4.1+
      Patchwork: https://patchwork.linux-mips.org/patch/12722/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      de444b25
    • Paul Burton's avatar
      MIPS: Handle highmem pages in __update_cache · 8c99d761
      Paul Burton authored
      [ Upstream commit f4281bba ]
      
      The following patch will expose __update_cache to highmem pages. Handle
      them by mapping them in for the duration of the cache maintenance, just
      like in __flush_dcache_page. The code for that isn't shared because we
      need the page address in __update_cache so sharing became messy. Given
      that the entirity is an extra 5 lines, just duplicate it.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Lars Persson <lars.persson@axis.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable <stable@vger.kernel.org> # v4.1+
      Patchwork: https://patchwork.linux-mips.org/patch/12721/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      8c99d761
    • Paul Burton's avatar
      MIPS: Flush highmem pages in __flush_dcache_page · e7c735b0
      Paul Burton authored
      [ Upstream commit 234859e4 ]
      
      When flush_dcache_page is called on an executable page, that page is
      about to be provided to userland & we can presume that the icache
      contains no valid entries for its address range. However if the icache
      does not fill from the dcache then we cannot presume that the pages
      content has been written back as far as the memories that the dcache
      will fill from (ie. L2 or further out).
      
      This was being done for lowmem pages, but not for highmem which can lead
      to icache corruption. Fix this by mapping highmem pages & flushing their
      content from the dcache in __flush_dcache_page before providing the page
      to userland, just as is done for lowmem pages.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Lars Persson <lars.persson@axis.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/12720/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e7c735b0
    • Guilherme G. Piccoli's avatar
      Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell" · deee8f00
      Guilherme G. Piccoli authored
      [ Upstream commit c2078d9e ]
      
      This reverts commit 89a51df5.
      
      The function eeh_add_device_early() is used to perform EEH
      initialization in devices added later on the system, like in
      hotplug/DLPAR scenarios. Since the commit 89a51df5 ("powerpc/eeh:
      Fix crash in eeh_add_device_early() on Cell") a new check was introduced
      in this function - Cell has no EEH capabilities which led to kernel oops
      if hotplug was performed, so checking for eeh_enabled() was introduced
      to avoid the issue.
      
      However, in architectures that EEH is present like pSeries or PowerNV,
      we might reach a case in which no PCI devices are present on boot time
      and so EEH is not initialized. Then, if a device is added via DLPAR for
      example, eeh_add_device_early() fails because eeh_enabled() is false,
      and EEH end up not being enabled at all.
      
      This reverts the aforementioned patch since a new verification was
      introduced by the commit d91dafc0 ("powerpc/eeh: Delay probing EEH
      device during hotplug") and so the original Cell issue does not happen
      anymore.
      
      Cc: stable@vger.kernel.org # v4.1+
      Reviewed-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      deee8f00
    • Gavin Shan's avatar
      powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover() · 75d03a9e
      Gavin Shan authored
      [ Upstream commit 5a0cdbfd ]
      
      The function eeh_pe_reset_and_recover() is used to recover EEH
      error when the passthrou device are transferred to guest and
      backwards. The content in the device's config space will be lost
      on PE reset issued in the middle of the recovery. The function
      saves/restores it before/after the reset. However, config access
      to some adapters like Broadcom BCM5719 at this point will causes
      fenced PHB. The config space is always blocked and we save 0xFF's
      that are restored at late point. The memory BARs are totally
      corrupted, causing another EEH error upon access to one of the
      memory BARs.
      
      This restores the config space on those adapters like BCM5719
      from the content saved to the EEH device when it's populated,
      to resolve above issue.
      
      Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
      Cc: stable@vger.kernel.org #v3.18+
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      75d03a9e
    • Gavin Shan's avatar
      powerpc/eeh: Don't report error in eeh_pe_reset_and_recover() · b7ccd2a2
      Gavin Shan authored
      [ Upstream commit affeb0f2 ]
      
      The function eeh_pe_reset_and_recover() is used to recover EEH
      error when the passthrough device are transferred to guest and
      backwards, meaning the device's driver is vfio-pci or none.
      When the driver is vfio-pci that provides error_detected() error
      handler only, the handler simply stops the guest and it's not
      expected behaviour. On the other hand, no error handlers will
      be called if we don't have a bound driver.
      
      This ignores the error handler in eeh_pe_reset_and_recover()
      that reports the error to device driver to avoid the exceptional
      behaviour.
      
      Fixes: 5cfb20b9 ("powerpc/eeh: Emulate EEH recovery for VFIO devices")
      Cc: stable@vger.kernel.org #v3.18+
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b7ccd2a2
    • Sasha Levin's avatar
      sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems · 18fc6569
      Sasha Levin authored
      [ Upstream commit 20878232 ]
      
      Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
      have no load at all.
      
      Uptime and /proc/loadavg on all systems with kernels released during the
      last five years up until kernel version 4.6-rc5, show a 5- and 15-minute
      minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
      idle systems, but the way the kernel calculates this value prevents it
      from getting lower than the mentioned values.
      
      Likewise but not as obviously noticeable, a fully loaded system with no
      processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95
      (multiplied by number of cores).
      
      Once the (old) load becomes 93 or higher, it mathematically can never
      get lower than 93, even when the active (load) remains 0 forever.
      This results in the strange 0.00, 0.01, 0.05 uptime values on idle
      systems.  Note: 93/2048 = 0.0454..., which rounds up to 0.05.
      
      It is not correct to add a 0.5 rounding (=1024/2048) here, since the
      result from this function is fed back into the next iteration again,
      so the result of that +0.5 rounding value then gets multiplied by
      (2048-2037), and then rounded again, so there is a virtual "ghost"
      load created, next to the old and active load terms.
      
      By changing the way the internally kept value is rounded, that internal
      value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon
      increasing load, the internally kept load value is rounded up, when the
      load is decreasing, the load value is rounded down.
      
      The modified code was tested on nohz=off and nohz kernels. It was tested
      on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was
      tested on single, dual, and octal cores system. It was tested on virtual
      hosts and bare hardware. No unwanted effects have been observed, and the
      problems that the patch intended to fix were indeed gone.
      Tested-by: default avatarDamien Wyart <damien.wyart@free.fr>
      Signed-off-by: default avatarVik Heyndrickx <vik.heyndrickx@veribox.net>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <stable@vger.kernel.org>
      Cc: Doug Smythies <dsmythies@telus.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 0f004f5a ("sched: Cure more NO_HZ load average woes")
      Link: http://lkml.kernel.org/r/e8d32bff-d544-7748-72b5-3c86cc71f09f@veribox.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      18fc6569
    • Sasha Levin's avatar
      rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring · fa5c124f
      Sasha Levin authored
      [ Upstream commit cf968937 ]
      
      We can't use kfree_skb in irq disable context, because spin_lock_irqsave
      make sure we are always in irq disable context, use dev_kfree_skb_irq
      instead of kfree_skb is better than dev_kfree_skb_any.
      
      This patch fix below kernel warning:
      [ 7612.095528] ------------[ cut here ]------------
      [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80()
      [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common
      [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G        W       4.4.0+ #4
      [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015
      [ 7612.095574]  00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454
      [ 7612.095584]  00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400
      [ 7612.095594]  f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8
      [ 7612.095604] Call Trace:
      [ 7612.095614]  [<c12ce7c5>] dump_stack+0x41/0x5c
      [ 7612.095620]  [<c104cc59>] warn_slowpath_common+0x89/0xc0
      [ 7612.095628]  [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
      [ 7612.095634]  [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80
      [ 7612.095640]  [<c104ccad>] warn_slowpath_null+0x1d/0x20
      [ 7612.095646]  [<c10508a8>] __local_bh_enable_ip+0x58/0x80
      [ 7612.095653]  [<c16b7d34>] destroy_conntrack+0x64/0xa0
      [ 7612.095660]  [<c16b300f>] nf_conntrack_destroy+0xf/0x20
      [ 7612.095665]  [<c1677565>] skb_release_head_state+0x55/0xa0
      [ 7612.095670]  [<c16775bb>] skb_release_all+0xb/0x20
      [ 7612.095674]  [<c167760b>] __kfree_skb+0xb/0x60
      [ 7612.095679]  [<c16776f0>] kfree_skb+0x30/0x70
      [ 7612.095686]  [<f81b869d>] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
      [ 7612.095692]  [<f81b869d>] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci]
      [ 7612.095698]  [<f81b87f9>] rtl_pci_start+0x19/0x190 [rtl_pci]
      [ 7612.095705]  [<f81970e6>] rtl_op_start+0x56/0x90 [rtlwifi]
      [ 7612.095712]  [<c17e3f16>] drv_start+0x36/0xc0
      [ 7612.095717]  [<c17f5ab3>] ieee80211_do_open+0x2d3/0x890
      [ 7612.095725]  [<c16820fe>] ? call_netdevice_notifiers_info+0x2e/0x60
      [ 7612.095730]  [<c17f60bd>] ieee80211_open+0x4d/0x50
      [ 7612.095736]  [<c16891b3>] __dev_open+0xa3/0x130
      [ 7612.095742]  [<c183fa53>] ? _raw_spin_unlock_bh+0x13/0x20
      [ 7612.095748]  [<c1689499>] __dev_change_flags+0x89/0x140
      [ 7612.095753]  [<c127c70d>] ? selinux_capable+0xd/0x10
      [ 7612.095759]  [<c1689589>] dev_change_flags+0x29/0x60
      [ 7612.095765]  [<c1700b93>] devinet_ioctl+0x553/0x670
      [ 7612.095772]  [<c12db758>] ? _copy_to_user+0x28/0x40
      [ 7612.095777]  [<c17018b5>] inet_ioctl+0x85/0xb0
      [ 7612.095783]  [<c166e647>] sock_ioctl+0x67/0x260
      [ 7612.095788]  [<c166e5e0>] ? sock_fasync+0x80/0x80
      [ 7612.095795]  [<c115c99b>] do_vfs_ioctl+0x6b/0x550
      [ 7612.095800]  [<c127c812>] ? selinux_file_ioctl+0x102/0x1e0
      [ 7612.095807]  [<c10a8914>] ? timekeeping_suspend+0x294/0x320
      [ 7612.095813]  [<c10a256a>] ? __hrtimer_run_queues+0x14a/0x210
      [ 7612.095820]  [<c1276e24>] ? security_file_ioctl+0x34/0x50
      [ 7612.095827]  [<c115cef0>] SyS_ioctl+0x70/0x80
      [ 7612.095832]  [<c1001804>] do_fast_syscall_32+0x84/0x120
      [ 7612.095839]  [<c183ff91>] sysenter_past_esp+0x36/0x55
      [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
      Signed-off-by: default avatarWang YanQing <udknight@gmail.com>
      Cc: Stable <stable@vger.kernel.org>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fa5c124f
    • Sasha Levin's avatar
      rtlwifi: Fix logic error in enter/exit power-save mode · 5de658d6
      Sasha Levin authored
      [ Upstream commit 873ffe15 ]
      
      In commit a269913c ("rtlwifi: Rework rtl_lps_leave() and
      rtl_lps_enter() to use work queue"), the tests for enter/exit
      power-save mode were inverted. With this change applied, the
      wifi connection becomes much more stable.
      
      Fixes: a269913c ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
      Signed-off-by: default avatarWang YanQing <udknight@gmail.com>
      CC: Stable <stable@vger.kernel.org> [3.10+]
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5de658d6
    • Arnd Bergmann's avatar
      kbuild: move -Wunused-const-variable to W=1 warning level · 4cfbd219
      Arnd Bergmann authored
      [ Upstream commit c9c6837d ]
      
      gcc-6 started warning by default about variables that are not
      used anywhere and that are marked 'const', generating many
      false positives in an allmodconfig build, e.g.:
      
      arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=]
      arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=]
      drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=]
      drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=]
      drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=]
      drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=]
      
      This is similar to the existing -Wunused-but-set-variable warning
      that was added in an earlier release and that we disable by default
      now and only enable when W=1 is set, so it makes sense to do
      the same here. Once we have eliminated the majority of the
      warnings for both, we can put them back into the default list.
      
      We probably want this in backport kernels as well, to allow building
      them with gcc-6 without introducing extra warnings.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4cfbd219
    • Marc Zyngier's avatar
      irqchip/gic-v3: Configure all interrupts as non-secure Group-1 · 10443b37
      Marc Zyngier authored
      [ Upstream commit 7c9b9730 ]
      
      The GICv3 driver wrongly assumes that it runs on the non-secure
      side of a secure-enabled system, while it could be on a system
      with a single security state, or a GICv3 with GICD_CTLR.DS set.
      
      Either way, it is important to configure this properly, or
      interrupts will simply not be delivered on this HW.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Tested-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      10443b37
    • Will Deacon's avatar
      irqchip/gic: Ensure ordering between read of INTACK and shared data · bfc9ab72
      Will Deacon authored
      [ Upstream commit f86c4fbd ]
      
      When an IPI is generated by a CPU, the pattern looks roughly like:
      
        <write shared data>
        smp_wmb();
        <write to GIC to signal SGI>
      
      On the receiving CPU we rely on the fact that, once we've taken the
      interrupt, then the freshly written shared data must be visible to us.
      Put another way, the CPU isn't going to speculate taking an interrupt.
      
      Unfortunately, this assumption turns out to be broken.
      
      Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
      to read some shared_data. Before CPUx has done anything, a random
      peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
      CPUy then takes the IRQ and starts executing the entry code, heading
      towards gic_handle_irq. Furthermore, let's assume that a bunch of the
      previous interrupts handled by CPUy were SGIs, so the branch predictor
      kicks in and speculates that irqnr will be <16 and we're likely to
      head into handle_IPI. The prefetcher then grabs a speculative copy of
      shared_data which contains a stale value.
      
      Meanwhile, CPUx gets round to updating shared_data and asking the GIC
      to send an SGI to CPUy. Internally, the GIC decides that the SGI is
      more important than the peripheral interrupt (which hasn't yet been
      ACKed) but doesn't need to do anything to CPUy, because the IRQ line
      is already raised.
      
      CPUy then reads the ACK register on the GIC, sees the SGI value which
      confirms the branch prediction and we end up with a stale shared_data
      value.
      
      This patch fixes the problem by adding an smp_rmb() to the IPI entry
      code in gic_handle_irq. As it turns out, the combination of a control
      dependency and an ISB instruction from the EOI in the GICv3 driver is
      enough to provide the ordering we need, so we add a comment there
      justifying the absence of an explicit smp_rmb().
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      bfc9ab72
    • Arnd Bergmann's avatar
      gcov: disable tree-loop-im to reduce stack usage · ff0ee291
      Arnd Bergmann authored
      [ Upstream commit c87bf431 ]
      
      Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like
      
      lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx':
      lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      
      After some investigation, I found that this behavior started with gcc-4.9,
      and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702.
      A suggested workaround for it is to use the -fno-tree-loop-im
      flag that turns off one of the optimization stages in gcc, so the
      code runs a little slower but does not use excessive amounts
      of stack.
      
      We could make this conditional on the gcc version, but I could not
      find an easy way to do this in Kbuild and the benefit would be
      fairly small, given that most of the gcc version in production are
      affected now.
      
      I'm marking this for 'stable' backports because it addresses a bug
      with code generation in gcc that exists in all kernel versions
      with the affected gcc releases.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ff0ee291
    • James Hogan's avatar
      MIPS: KVM: Fix timer IRQ race when writing CP0_Compare · 456b98fe
      James Hogan authored
      [ Upstream commit b45bacd2 ]
      
      Writing CP0_Compare clears the timer interrupt pending bit
      (CP0_Cause.TI), but this wasn't being done atomically. If a timer
      interrupt raced with the write of the guest CP0_Compare, the timer
      interrupt could end up being pending even though the new CP0_Compare is
      nowhere near CP0_Count.
      
      We were already updating the hrtimer expiry with
      kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and
      kvm_mips_resume_hrtimer(). Close the race window by expanding out
      kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting
      CP0_Compare between the freeze and resume. Since the pending timer
      interrupt should not be cleared when CP0_Compare is written via the KVM
      user API, an ack argument is added to distinguish the source of the
      write.
      
      Fixes: e30492bb ("MIPS: KVM: Rewrite count/compare timer emulation")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim KrčmáÅ" <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 3.16.x-
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      456b98fe
    • James Hogan's avatar
      MIPS: KVM: Fix timer IRQ race when freezing timer · 8106278c
      James Hogan authored
      [ Upstream commit 4355c44f ]
      
      There's a particularly narrow and subtle race condition when the
      software emulated guest timer is frozen which can allow a guest timer
      interrupt to be missed.
      
      This happens due to the hrtimer expiry being inexact, so very
      occasionally the freeze time will be after the moment when the emulated
      CP0_Count transitions to the same value as CP0_Compare (so an IRQ should
      be generated), but before the moment when the hrtimer is due to expire
      (so no IRQ is generated). The IRQ won't be generated when the timer is
      resumed either, since the resume CP0_Count will already match CP0_Compare.
      
      With VZ guests in particular this is far more likely to happen, since
      the soft timer may be frozen frequently in order to restore the timer
      state to the hardware guest timer. This happens after 5-10 hours of
      guest soak testing, resulting in an overflow in guest kernel timekeeping
      calculations, hanging the guest. A more focussed test case to
      intentionally hit the race (with the help of a new hypcall to cause the
      timer state to migrated between hardware & software) hits the condition
      fairly reliably within around 30 seconds.
      
      Instead of relying purely on the inexact hrtimer expiry to determine
      whether an IRQ should be generated, read the guest CP0_Compare and
      directly check whether the freeze time is before or after it. Only if
      CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to
      determine whether the last IRQ has already been generated (which will
      have pushed back the expiry by one timer period).
      
      Fixes: e30492bb ("MIPS: KVM: Rewrite count/compare timer emulation")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim KrčmáÅ" <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Cc: <stable@vger.kernel.org> # 3.16.x-
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      8106278c
    • Catalin Vasile's avatar
      crypto: caam - fix caam_jr_alloc() ret code · ceee7b2f
      Catalin Vasile authored
      [ Upstream commit e930c765 ]
      
      caam_jr_alloc() used to return NULL if a JR device could not be
      allocated for a session. In turn, every user of this function used
      IS_ERR() function to verify if anything went wrong, which does NOT look
      for NULL values. This made the kernel crash if the sanity check failed,
      because the driver continued to think it had allocated a valid JR dev
      instance to the session and at some point it tries to do a caam_jr_free()
      on a NULL JR dev pointer.
      This patch is a fix for this issue.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarCatalin Vasile <cata.vasile@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ceee7b2f
    • Johan Hovold's avatar
      USB: serial: quatech2: fix use-after-free in probe error path · 7124f5df
      Johan Hovold authored
      [ Upstream commit 028c49f5 ]
      
      The interface read URB is submitted in attach, but was only unlinked by
      the driver at disconnect.
      
      In case of a late probe error (e.g. due to failed minor allocation),
      disconnect is never called and we would end up with active URBs for an
      unbound interface. This in turn could lead to deallocated memory being
      dereferenced in the completion callback.
      
      Fixes: f7a33e60 ("USB: serial: add quatech2 usb to serial driver")
      Cc: stable <stable@vger.kernel.org>	# v3.5: 40d04738Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7124f5df
    • Johan Hovold's avatar
      USB: serial: mxuport: fix use-after-free in probe error path · 17e958ca
      Johan Hovold authored
      [ Upstream commit 9e452849 ]
      
      The interface read and event URBs are submitted in attach, but were
      never explicitly unlinked by the driver. Instead the URBs would have
      been killed by usb-serial core on disconnect.
      
      In case of a late probe error (e.g. due to failed minor allocation),
      disconnect is never called and we could end up with active URBs for an
      unbound interface. This in turn could lead to deallocated memory being
      dereferenced in the completion callbacks.
      
      Fixes: ee467a1f ("USB: serial: add Moxa UPORT 12XX/14XX/16XX
      driver")
      Cc: stable <stable@vger.kernel.org>	# v3.14
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      17e958ca
    • Johan Hovold's avatar
      USB: serial: keyspan: fix use-after-free in probe error path · d2e9eeb2
      Johan Hovold authored
      [ Upstream commit 35be1a71 ]
      
      The interface instat and indat URBs were submitted in attach, but never
      unlinked in release before deallocating the corresponding transfer
      buffers.
      
      In the case of a late probe error (e.g. due to failed minor allocation),
      disconnect would not have been called before release, causing the
      buffers to be freed while the URBs are still in use. We'd also end up
      with active URBs for an unbound interface.
      
      Fixes: f9c99bb8 ("USB: usb-serial: replace shutdown with disconnect,
      release")
      Cc: stable <stable@vger.kernel.org>	# v2.6.31
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d2e9eeb2
    • Johan Hovold's avatar
      USB: serial: io_edgeport: fix memory leaks in probe error path · 90eb29f5
      Johan Hovold authored
      [ Upstream commit c8d62957 ]
      
      URBs and buffers allocated in attach for Epic devices would never be
      deallocated in case of a later probe error (e.g. failure to allocate
      minor numbers) as disconnect is then never called.
      
      Fix by moving deallocation to release and making sure that the
      URBs are first unlinked.
      
      Fixes: f9c99bb8 ("USB: usb-serial: replace shutdown with disconnect,
      release")
      Cc: stable <stable@vger.kernel.org>	# v2.6.31
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      90eb29f5
    • Johan Hovold's avatar
      USB: serial: io_edgeport: fix memory leaks in attach error path · 7bbc1379
      Johan Hovold authored
      [ Upstream commit c5c0c555 ]
      
      Private data, URBs and buffers allocated for Epic devices during
      attach were never released on errors (e.g. missing endpoints).
      
      Fixes: 6e8cf775 ("USB: add EPIC support to the io_edgeport driver")
      Cc: stable <stable@vger.kernel.org>	# v2.6.21
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7bbc1379
    • Roger Quadros's avatar
      mfd: omap-usb-tll: Fix scheduling while atomic BUG · ec391566
      Roger Quadros authored
      [ Upstream commit b49b927f ]
      
      We shouldn't be calling clk_prepare_enable()/clk_prepare_disable()
      in an atomic context.
      
      Fixes the following issue:
      
      [    5.830970] ehci-omap: OMAP-EHCI Host Controller driver
      [    5.830974] driver_register 'ehci-omap'
      [    5.895849] driver_register 'wl1271_sdio'
      [    5.896870] BUG: scheduling while atomic: udevd/994/0x00000002
      [    5.896876] 4 locks held by udevd/994:
      [    5.896904]  #0:  (&dev->mutex){......}, at: [<c049597c>] __driver_attach+0x60/0xac
      [    5.896923]  #1:  (&dev->mutex){......}, at: [<c049598c>] __driver_attach+0x70/0xac
      [    5.896946]  #2:  (tll_lock){+.+...}, at: [<c04c2630>] omap_tll_enable+0x2c/0xd0
      [    5.896966]  #3:  (prepare_lock){+.+...}, at: [<c05ce9c8>] clk_prepare_lock+0x48/0xe0
      [    5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine
      [    5.897048] Preemption disabled at:[<  (null)>]   (null)
      [    5.897051]
      [    5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ #233
      [    5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree)
      [    5.897076] [<c010e714>] (unwind_backtrace) from [<c010af34>] (show_stack+0x10/0x14)
      [    5.897087] [<c010af34>] (show_stack) from [<c040aa7c>] (dump_stack+0x88/0xc0)
      [    5.897099] [<c040aa7c>] (dump_stack) from [<c020c558>] (__schedule_bug+0xac/0xd0)
      [    5.897111] [<c020c558>] (__schedule_bug) from [<c06f3d44>] (__schedule+0x88/0x7e4)
      [    5.897120] [<c06f3d44>] (__schedule) from [<c06f46d8>] (schedule+0x9c/0xc0)
      [    5.897129] [<c06f46d8>] (schedule) from [<c06f4904>] (schedule_preempt_disabled+0x14/0x20)
      [    5.897140] [<c06f4904>] (schedule_preempt_disabled) from [<c06f64e4>] (mutex_lock_nested+0x258/0x43c)
      [    5.897150] [<c06f64e4>] (mutex_lock_nested) from [<c05ce9c8>] (clk_prepare_lock+0x48/0xe0)
      [    5.897160] [<c05ce9c8>] (clk_prepare_lock) from [<c05d0e7c>] (clk_prepare+0x10/0x28)
      [    5.897169] [<c05d0e7c>] (clk_prepare) from [<c04c2668>] (omap_tll_enable+0x64/0xd0)
      [    5.897180] [<c04c2668>] (omap_tll_enable) from [<c04c1728>] (usbhs_runtime_resume+0x18/0x17c)
      [    5.897192] [<c04c1728>] (usbhs_runtime_resume) from [<c049d404>] (pm_generic_runtime_resume+0x2c/0x40)
      [    5.897202] [<c049d404>] (pm_generic_runtime_resume) from [<c049f180>] (__rpm_callback+0x38/0x68)
      [    5.897210] [<c049f180>] (__rpm_callback) from [<c049f220>] (rpm_callback+0x70/0x88)
      [    5.897218] [<c049f220>] (rpm_callback) from [<c04a0a00>] (rpm_resume+0x4ec/0x7ec)
      [    5.897227] [<c04a0a00>] (rpm_resume) from [<c04a0f48>] (__pm_runtime_resume+0x4c/0x64)
      [    5.897236] [<c04a0f48>] (__pm_runtime_resume) from [<c04958dc>] (driver_probe_device+0x30/0x70)
      [    5.897246] [<c04958dc>] (driver_probe_device) from [<c04959a4>] (__driver_attach+0x88/0xac)
      [    5.897256] [<c04959a4>] (__driver_attach) from [<c04940f8>] (bus_for_each_dev+0x50/0x84)
      [    5.897267] [<c04940f8>] (bus_for_each_dev) from [<c0494e40>] (bus_add_driver+0xcc/0x1e4)
      [    5.897276] [<c0494e40>] (bus_add_driver) from [<c0496914>] (driver_register+0xac/0xf4)
      [    5.897286] [<c0496914>] (driver_register) from [<c01018e0>] (do_one_initcall+0x100/0x1b8)
      [    5.897296] [<c01018e0>] (do_one_initcall) from [<c01c7a54>] (do_init_module+0x58/0x1c0)
      [    5.897304] [<c01c7a54>] (do_init_module) from [<c01c8a3c>] (SyS_finit_module+0x88/0x90)
      [    5.897313] [<c01c8a3c>] (SyS_finit_module) from [<c0107120>] (ret_fast_syscall+0x0/0x1c)
      [    5.912697] ------------[ cut here ]------------
      [    5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 _raw_spin_unlock+0x28/0x58
      [    5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count())
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Tested-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ec391566
  2. 04 Jun, 2016 1 commit
  3. 03 Jun, 2016 9 commits
    • James Hogan's avatar
      MIPS: Avoid using unwind_stack() with usermode · c2915ee9
      James Hogan authored
      [ Upstream commit 81a76d71 ]
      
      When showing backtraces in response to traps, for example crashes and
      address errors (usually unaligned accesses) when they are set in debugfs
      to be reported, unwind_stack will be used if the PC was in the kernel
      text address range. However since EVA it is possible for user and kernel
      address ranges to overlap, and even without EVA userland can still
      trigger an address error by jumping to a KSeg0 address.
      
      Adjust the check to also ensure that it was running in kernel mode. I
      don't believe any harm can come of this problem, since unwind_stack() is
      sufficiently defensive, however it is only meant for unwinding kernel
      code, so to be correct it should use the raw backtracing instead.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Reviewed-by: default avatarLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 3.15+
      Patchwork: https://patchwork.linux-mips.org/patch/11701/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      (cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9)
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c2915ee9
    • James Hogan's avatar
      MIPS: Don't unwind to user mode with EVA · dd95033f
      James Hogan authored
      [ Upstream commit a816b306 ]
      
      When unwinding through IRQs and exceptions, the unwinding only continues
      if the PC is a kernel text address, however since EVA it is possible for
      user and kernel address ranges to overlap, potentially allowing
      unwinding to continue to user mode if the user PC happens to be in the
      kernel text address range.
      
      Adjust the check to also ensure that the register state from before the
      exception is actually running in kernel mode, i.e. !user_mode(regs).
      
      I don't believe any harm can come of this problem, since the PC is only
      output, the stack pointer is checked to ensure it resides within the
      task's stack page before it is dereferenced in search of the return
      address, and the return address register is similarly only output (if
      the PC is in a leaf function or the beginning of a non-leaf function).
      
      However unwind_stack() is only meant for unwinding kernel code, so to be
      correct the unwind should stop there.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Reviewed-by: default avatarLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 3.15+
      Patchwork: https://patchwork.linux-mips.org/patch/11700/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      dd95033f
    • James Hogan's avatar
      MIPS: Fix siginfo.h to use strict posix types · 22a4a259
      James Hogan authored
      [ Upstream commit 5daebc47 ]
      
      Commit 85efde6f ("make exported headers use strict posix types")
      changed the asm-generic siginfo.h to use the __kernel_* types, and
      commit 3a471cbc ("remove __KERNEL_STRICT_NAMES") make the internal
      types accessible only to the kernel, but the MIPS implementation hasn't
      been updated to match.
      
      Switch to proper types now so that the exported asm/siginfo.h won't
      produce quite so many compiler errors when included alone by a user
      program.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Christopher Ferris <cferris@google.com>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 2.6.30-
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/12477/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      22a4a259
    • Oliver Hartkopp's avatar
      can: fix handling of unmodifiable configuration options · 5b59ae1e
      Oliver Hartkopp authored
      [ Upstream commit bb208f14 ]
      
      As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
      (6cfda7fb) it is possible to define fixed configuration options by
      setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'.
      This leads to the incovenience that the fixed configuration bits can not be
      passed by netlink even when they have the correct values (e.g. non-ISO, FD).
      
      This patch fixes that issue and not only allows fixed set bit values to be set
      again but now requires(!) to provide these fixed values at configuration time.
      A valid CAN FD configuration consists of a nominal/arbitration bittiming, a
      data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now
      enforced by a new can_validate() function. This fix additionally removed the
      inconsistency that was prohibiting the support of 'CANFD-only' controller
      drivers, like the RCar CAN FD.
      
      For this reason a new helper can_set_static_ctrlmode() has been introduced to
      provide a proper interface to handle static enabled CAN controller options.
      Reported-by: default avatarRamesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Reviewed-by: default avatarRamesh Shanmugasundaram  <ramesh.shanmugasundaram@bp.renesas.com>
      Cc: <stable@vger.kernel.org> # >= 3.18
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5b59ae1e
    • Catalin Marinas's avatar
      arm64: Ensure pmd_present() returns false after pmd_mknotpresent() · 0839058a
      Catalin Marinas authored
      [ Upstream commit 5bb1cc0f ]
      
      Currently, pmd_present() only checks for a non-zero value, returning
      true even after pmd_mknotpresent() (which only clears the type bits).
      This patch converts pmd_present() to using pte_present(), similar to the
      other pmd_*() checks. As a side effect, it will return true for
      PROT_NONE mappings, though they are not yet used by the kernel with
      transparent huge pages.
      
      For consistency, also change pmd_mknotpresent() to only clear the
      PMD_SECT_VALID bit, even though the PMD_TABLE_BIT is already 0 for block
      mappings (no functional change). The unused PMD_SECT_PROT_NONE
      definition is removed as transparent huge pages use the pte page prot
      values.
      
      Fixes: 9c7e535f ("arm64: mm: Route pmd thp functions through pte equivalents")
      Cc: <stable@vger.kernel.org> # 3.15+
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0839058a
    • Nicolai Stange's avatar
      ext4: silence UBSAN in ext4_mb_init() · 7346b874
      Nicolai Stange authored
      [ Upstream commit 935244cd ]
      
      Currently, in ext4_mb_init(), there's a loop like the following:
      
        do {
          ...
          offset += 1 << (sb->s_blocksize_bits - i);
          i++;
        } while (i <= sb->s_blocksize_bits + 1);
      
      Note that the updated offset is used in the loop's next iteration only.
      
      However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
      the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
      and UBSAN reports
      
        UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
        shift exponent 4294967295 is too large for 32-bit type 'int'
        [...]
        Call Trace:
         [<ffffffff818c4d25>] dump_stack+0xbc/0x117
         [<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169
         [<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e
         [<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
         [<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
         [<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390
         [<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0
         [<ffffffff814293c7>] ? create_cache+0x57/0x1f0
         [<ffffffff8142948a>] ? create_cache+0x11a/0x1f0
         [<ffffffff821c2168>] ? mutex_lock+0x38/0x60
         [<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50
         [<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0
         [<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0
         [<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0
         [...]
      
      Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.
      
      Unless compilers start to do some fancy transformations (which at least
      GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
      such calculated value of offset is never used again.
      
      Silence UBSAN by introducing another variable, offset_incr, holding the
      next increment to apply to offset and adjust that one by right shifting it
      by one position per loop iteration.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7346b874
    • Nicolai Stange's avatar
      ext4: address UBSAN warning in mb_find_order_for_block() · 76caa717
      Nicolai Stange authored
      [ Upstream commit b5cb316c ]
      
      Currently, in mb_find_order_for_block(), there's a loop like the following:
      
        while (order <= e4b->bd_blkbits + 1) {
          ...
          bb += 1 << (e4b->bd_blkbits - order);
        }
      
      Note that the updated bb is used in the loop's next iteration only.
      
      However, at the last iteration, that is at order == e4b->bd_blkbits + 1,
      the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports
      
        UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11
        shift exponent -1 is negative
        [...]
        Call Trace:
         [<ffffffff818c4d35>] dump_stack+0xbc/0x117
         [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169
         [<ffffffff819411bb>] ubsan_epilogue+0xd/0x4e
         [<ffffffff81941cbc>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
         [<ffffffff81941ac1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
         [<ffffffff816e93a0>] ? ext4_mb_generate_from_pa+0x590/0x590
         [<ffffffff816502c8>] ? ext4_read_block_bitmap_nowait+0x598/0xe80
         [<ffffffff816e7b7e>] mb_find_order_for_block+0x1ce/0x240
         [...]
      
      Unless compilers start to do some fancy transformations (which at least
      GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
      such calculated value of bb is never used again.
      
      Silence UBSAN by introducing another variable, bb_incr, holding the next
      increment to apply to bb and adjust that one by right shifting it by one
      position per loop iteration.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      76caa717
    • Jan Kara's avatar
      ext4: fix oops on corrupted filesystem · f245ed01
      Jan Kara authored
      [ Upstream commit 74177f55 ]
      
      When filesystem is corrupted in the right way, it can happen
      ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we
      subsequently remove inode from the in-memory orphan list. However this
      deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we
      leave i_orphan list_head with a stale content. Later we can look at this
      content causing list corruption, oops, or other issues. The reported
      trace looked like:
      
      WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100()
      list_del corruption, 0000000061c1d6e0->next is LIST_POISON1
      0000000000100100)
      CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250
      Stack:
       60462947 62219960 602ede24 62219960
       602ede24 603ca293 622198f0 602f02eb
       62219950 6002c12c 62219900 601b4d6b
      Call Trace:
       [<6005769c>] ? vprintk_emit+0x2dc/0x5c0
       [<602ede24>] ? printk+0x0/0x94
       [<600190bc>] show_stack+0xdc/0x1a0
       [<602ede24>] ? printk+0x0/0x94
       [<602ede24>] ? printk+0x0/0x94
       [<602f02eb>] dump_stack+0x2a/0x2c
       [<6002c12c>] warn_slowpath_common+0x9c/0xf0
       [<601b4d6b>] ? __list_del_entry+0x6b/0x100
       [<6002c254>] warn_slowpath_fmt+0x94/0xa0
       [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0
       [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0
       [<60023ebf>] ? set_signals+0x3f/0x50
       [<600a205a>] ? kmem_cache_free+0x10a/0x180
       [<602f4e88>] ? mutex_lock+0x18/0x30
       [<601b4d6b>] __list_del_entry+0x6b/0x100
       [<601177ec>] ext4_orphan_del+0x22c/0x2f0
       [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0
       [<6010b973>] ? ext4_truncate+0x383/0x390
       [<6010bc8b>] ext4_write_begin+0x30b/0x4b0
       [<6001bb50>] ? copy_from_user+0x0/0xb0
       [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0
       [<60072c4f>] generic_perform_write+0xaf/0x1e0
       [<600c4166>] ? file_update_time+0x46/0x110
       [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0
       [<6010030f>] ext4_file_write_iter+0x15f/0x470
       [<60094e10>] ? unlink_file_vma+0x0/0x70
       [<6009b180>] ? unlink_anon_vmas+0x0/0x260
       [<6008f169>] ? free_pgtables+0xb9/0x100
       [<600a6030>] __vfs_write+0xb0/0x130
       [<600a61d5>] vfs_write+0xa5/0x170
       [<600a63d6>] SyS_write+0x56/0xe0
       [<6029fcb0>] ? __libc_waitpid+0x0/0xa0
       [<6001b698>] handle_syscall+0x68/0x90
       [<6002633d>] userspace+0x4fd/0x600
       [<6002274f>] ? save_registers+0x1f/0x40
       [<60028bd7>] ? arch_prctl+0x177/0x1b0
       [<60017bd5>] fork_handler+0x85/0x90
      
      Fix the problem by using list_del_init() as we always should with
      i_orphan list.
      
      CC: stable@vger.kernel.org
      Reported-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f245ed01
    • Konstantin Shkolnyy's avatar
      USB: serial: cp210x: fix hardware flow-control disable · e4e59834
      Konstantin Shkolnyy authored
      [ Upstream commit a377f9e9 ]
      
      A bug in the CRTSCTS handling caused RTS to alternate between
      
      CRTSCTS=0 => "RTS is transmit active signal" and
      CRTSCTS=1 => "RTS is used for receive flow control"
      
      instead of
      
      CRTSCTS=0 => "RTS is statically active" and
      CRTSCTS=1 => "RTS is used for receive flow control"
      
      This only happened after first having enabled CRTSCTS.
      Signed-off-by: default avatarKonstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
      Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control")
      Cc: stable <stable@vger.kernel.org>
      [johan: reword commit message ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e4e59834