1. 03 4月, 2019 40 次提交
    • S
      KVM: x86: Emulate MSR_IA32_ARCH_CAPABILITIES on AMD hosts · 3a18eaba
      Sean Christopherson 提交于
      commit 0cf9135b773bf32fba9dd8e6699c1b331ee4b749 upstream.
      
      The CPUID flag ARCH_CAPABILITIES is unconditioinally exposed to host
      userspace for all x86 hosts, i.e. KVM advertises ARCH_CAPABILITIES
      regardless of hardware support under the pretense that KVM fully
      emulates MSR_IA32_ARCH_CAPABILITIES.  Unfortunately, only VMX hosts
      handle accesses to MSR_IA32_ARCH_CAPABILITIES (despite KVM_GET_MSRS
      also reporting MSR_IA32_ARCH_CAPABILITIES for all hosts).
      
      Move the MSR_IA32_ARCH_CAPABILITIES handling to common x86 code so
      that it's emulated on AMD hosts.
      
      Fixes: 1eaafe91 ("kvm: x86: IA32_ARCH_CAPABILITIES is always supported")
      Cc: stable@vger.kernel.org
      Reported-by: NXiaoyao Li <xiaoyao.li@linux.intel.com>
      Cc: Jim Mattson <jmattson@google.com>
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a18eaba
    • S
      KVM: x86: update %rip after emulating IO · b9733a74
      Sean Christopherson 提交于
      commit 45def77ebf79e2e8942b89ed79294d97ce914fa0 upstream.
      
      Most (all?) x86 platforms provide a port IO based reset mechanism, e.g.
      OUT 92h or CF9h.  Userspace may emulate said mechanism, i.e. reset a
      vCPU in response to KVM_EXIT_IO, without explicitly announcing to KVM
      that it is doing a reset, e.g. Qemu jams vCPU state and resumes running.
      
      To avoid corruping %rip after such a reset, commit 0967b7bf ("KVM:
      Skip pio instruction when it is emulated, not executed") changed the
      behavior of PIO handlers, i.e. today's "fast" PIO handling to skip the
      instruction prior to exiting to userspace.  Full emulation doesn't need
      such tricks becase re-emulating the instruction will naturally handle
      %rip being changed to point at the reset vector.
      
      Updating %rip prior to executing to userspace has several drawbacks:
      
        - Userspace sees the wrong %rip on the exit, e.g. if PIO emulation
          fails it will likely yell about the wrong address.
        - Single step exits to userspace for are effectively dropped as
          KVM_EXIT_DEBUG is overwritten with KVM_EXIT_IO.
        - Behavior of PIO emulation is different depending on whether it
          goes down the fast path or the slow path.
      
      Rather than skip the PIO instruction before exiting to userspace,
      snapshot the linear %rip and cancel PIO completion if the current
      value does not match the snapshot.  For a 64-bit vCPU, i.e. the most
      common scenario, the snapshot and comparison has negligible overhead
      as VMCS.GUEST_RIP will be cached regardless, i.e. there is no extra
      VMREAD in this case.
      
      All other alternatives to snapshotting the linear %rip that don't
      rely on an explicit reset announcenment suffer from one corner case
      or another.  For example, canceling PIO completion on any write to
      %rip fails if userspace does a save/restore of %rip, and attempting to
      avoid that issue by canceling PIO only if %rip changed then fails if PIO
      collides with the reset %rip.  Attempting to zero in on the exact reset
      vector won't work for APs, which means adding more hooks such as the
      vCPU's MP_STATE, and so on and so forth.
      
      Checking for a linear %rip match technically suffers from corner cases,
      e.g. userspace could theoretically rewrite the underlying code page and
      expect a different instruction to execute, or the guest hardcodes a PIO
      reset at 0xfffffff0, but those are far, far outside of what can be
      considered normal operation.
      
      Fixes: 432baf60 ("KVM: VMX: use kvm_fast_pio_in for handling IN I/O")
      Cc: <stable@vger.kernel.org>
      Reported-by: NJim Mattson <jmattson@google.com>
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9733a74
    • S
      KVM: Reject device ioctls from processes other than the VM's creator · 7ceedcef
      Sean Christopherson 提交于
      commit ddba91801aeb5c160b660caed1800eb3aef403f8 upstream.
      
      KVM's API requires thats ioctls must be issued from the same process
      that created the VM.  In other words, userspace can play games with a
      VM's file descriptors, e.g. fork(), SCM_RIGHTS, etc..., but only the
      creator can do anything useful.  Explicitly reject device ioctls that
      are issued by a process other than the VM's creator, and update KVM's
      API documentation to extend its requirements to device ioctls.
      
      Fixes: 852b6d57 ("kvm: add device control API")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ceedcef
    • T
      x86/smp: Enforce CONFIG_HOTPLUG_CPU when SMP=y · a0713e81
      Thomas Gleixner 提交于
      commit bebd024e4815b1a170fcd21ead9c2222b23ce9e6 upstream.
      
      The SMT disable 'nosmt' command line argument is not working properly when
      CONFIG_HOTPLUG_CPU is disabled. The teardown of the sibling CPUs which are
      required to be brought up due to the MCE issues, cannot work. The CPUs are
      then kept in a half dead state.
      
      As the 'nosmt' functionality has become popular due to the speculative
      hardware vulnerabilities, the half torn down state is not a proper solution
      to the problem.
      
      Enforce CONFIG_HOTPLUG_CPU=y when SMP is enabled so the full operation is
      possible.
      Reported-by: NTianyu Lan <Tianyu.Lan@microsoft.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Konrad Wilk <konrad.wilk@oracle.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Mukesh Ojha <mojha@codeaurora.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Micheal Kelley <michael.h.kelley@microsoft.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190326163811.598166056@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0713e81
    • T
      cpu/hotplug: Prevent crash when CPU bringup fails on CONFIG_HOTPLUG_CPU=n · a56aa02e
      Thomas Gleixner 提交于
      commit 206b92353c839c0b27a0b9bec24195f93fd6cf7a upstream.
      
      Tianyu reported a crash in a CPU hotplug teardown callback when booting a
      kernel which has CONFIG_HOTPLUG_CPU disabled with the 'nosmt' boot
      parameter.
      
      It turns out that the SMP=y CONFIG_HOTPLUG_CPU=n case has been broken
      forever in case that a bringup callback fails. Unfortunately this issue was
      not recognized when the CPU hotplug code was reworked, so the shortcoming
      just stayed in place.
      
      When a bringup callback fails, the CPU hotplug code rolls back the
      operation and takes the CPU offline.
      
      The 'nosmt' command line argument uses a bringup failure to abort the
      bringup of SMT sibling CPUs. This partial bringup is required due to the
      MCE misdesign on Intel CPUs.
      
      With CONFIG_HOTPLUG_CPU=y the rollback works perfectly fine, but
      CONFIG_HOTPLUG_CPU=n lacks essential mechanisms to exercise the low level
      teardown of a CPU including the synchronizations in various facilities like
      RCU, NOHZ and others.
      
      As a consequence the teardown callbacks which must be executed on the
      outgoing CPU within stop machine with interrupts disabled are executed on
      the control CPU in interrupt enabled and preemptible context causing the
      kernel to crash and burn. The pre state machine code has a different
      failure mode which is more subtle and resulting in a less obvious use after
      free crash because the control side frees resources which are still in use
      by the undead CPU.
      
      But this is not a x86 only problem. Any architecture which supports the
      SMP=y HOTPLUG_CPU=n combination suffers from the same issue. It's just less
      likely to be triggered because in 99.99999% of the cases all bringup
      callbacks succeed.
      
      The easy solution of making HOTPLUG_CPU mandatory for SMP is not working on
      all architectures as the following architectures have either no hotplug
      support at all or not all subarchitectures support it:
      
       alpha, arc, hexagon, openrisc, riscv, sparc (32bit), mips (partial).
      
      Crashing the kernel in such a situation is not an acceptable state
      either.
      
      Implement a minimal rollback variant by limiting the teardown to the point
      where all regular teardown callbacks have been invoked and leave the CPU in
      the 'dead' idle state. This has the following consequences:
      
       - the CPU is brought down to the point where the stop_machine takedown
         would happen.
      
       - the CPU stays there forever and is idle
      
       - The CPU is cleared in the CPU active mask, but not in the CPU online
         mask which is a legit state.
      
       - Interrupts are not forced away from the CPU
      
       - All facilities which only look at online mask would still see it, but
         that is the case during normal hotplug/unplug operations as well. It's
         just a (way) longer time frame.
      
      This will expose issues, which haven't been exposed before or only seldom,
      because now the normally transient state of being non active but online is
      a permanent state. In testing this exposed already an issue vs. work queues
      where the vmstat code schedules work on the almost dead CPU which ends up
      in an unbound workqueue and triggers 'preemtible context' warnings. This is
      not a problem of this change, it merily exposes an already existing issue.
      Still this is better than crashing fully without a chance to debug it.
      
      This is mainly thought as workaround for those architectures which do not
      support HOTPLUG_CPU. All others should enforce HOTPLUG_CPU for SMP.
      
      Fixes: 2e1a3483 ("cpu/hotplug: Split out the state walk into functions")
      Reported-by: NTianyu Lan <Tianyu.Lan@microsoft.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NTianyu Lan <Tianyu.Lan@microsoft.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Konrad Wilk <konrad.wilk@oracle.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Mukesh Ojha <mojha@codeaurora.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Micheal Kelley <michael.h.kelley@microsoft.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190326163811.503390616@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a56aa02e
    • T
      watchdog: Respect watchdog cpumask on CPU hotplug · 336f6b23
      Thomas Gleixner 提交于
      commit 7dd47617114921fdd8c095509e5e7b4373cc44a1 upstream.
      
      The rework of the watchdog core to use cpu_stop_work broke the watchdog
      cpumask on CPU hotplug.
      
      The watchdog_enable/disable() functions are now called unconditionally from
      the hotplug callback, i.e. even on CPUs which are not in the watchdog
      cpumask. As a consequence the watchdog can become unstoppable.
      
      Only invoke them when the plugged CPU is in the watchdog cpumask.
      
      Fixes: 9cf57731 ("watchdog/softlockup: Replace "watchdog/%u" threads with cpu_stop_work")
      Reported-by: NMaxime Coquelin <maxime.coquelin@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NMaxime Coquelin <maxime.coquelin@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1903262245490.1789@nanos.tec.linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      336f6b23
    • M
      powerpc/64: Fix memcmp reading past the end of src/dest · c91d07ad
      Michael Ellerman 提交于
      commit d9470757398a700d9450a43508000bcfd010c7a4 upstream.
      
      Chandan reported that fstests' generic/026 test hit a crash:
      
        BUG: Unable to handle kernel data access at 0xc00000062ac40000
        Faulting instruction address: 0xc000000000092240
        Oops: Kernel access of bad area, sig: 11 [#1]
        LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries
        CPU: 0 PID: 27828 Comm: chacl Not tainted 5.0.0-rc2-next-20190115-00001-g6de6dba64dda #1
        NIP:  c000000000092240 LR: c00000000066a55c CTR: 0000000000000000
        REGS: c00000062c0c3430 TRAP: 0300   Not tainted  (5.0.0-rc2-next-20190115-00001-g6de6dba64dda)
        MSR:  8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 44000842  XER: 20000000
        CFAR: 00007fff7f3108ac DAR: c00000062ac40000 DSISR: 40000000 IRQMASK: 0
        GPR00: 0000000000000000 c00000062c0c36c0 c0000000017f4c00 c00000000121a660
        GPR04: c00000062ac3fff9 0000000000000004 0000000000000020 00000000275b19c4
        GPR08: 000000000000000c 46494c4500000000 5347495f41434c5f c0000000026073a0
        GPR12: 0000000000000000 c0000000027a0000 0000000000000000 0000000000000000
        GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
        GPR20: c00000062ea70020 c00000062c0c38d0 0000000000000002 0000000000000002
        GPR24: c00000062ac3ffe8 00000000275b19c4 0000000000000001 c00000062ac30000
        GPR28: c00000062c0c38d0 c00000062ac30050 c00000062ac30058 0000000000000000
        NIP memcmp+0x120/0x690
        LR  xfs_attr3_leaf_lookup_int+0x53c/0x5b0
        Call Trace:
          xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable)
          xfs_da3_node_lookup_int+0x32c/0x5a0
          xfs_attr_node_addname+0x170/0x6b0
          xfs_attr_set+0x2ac/0x340
          __xfs_set_acl+0xf0/0x230
          xfs_set_acl+0xd0/0x160
          set_posix_acl+0xc0/0x130
          posix_acl_xattr_set+0x68/0x110
          __vfs_setxattr+0xa4/0x110
          __vfs_setxattr_noperm+0xac/0x240
          vfs_setxattr+0x128/0x130
          setxattr+0x248/0x600
          path_setxattr+0x108/0x120
          sys_setxattr+0x28/0x40
          system_call+0x5c/0x70
        Instruction dump:
        7d201c28 7d402428 7c295040 38630008 38840008 408201f0 4200ffe8 2c050000
        4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 7d4a3436 7c295040
      
      The instruction dump decodes as:
        subfic  r6,r5,8
        rlwinm  r6,r6,3,0,28
        ldbrx   r9,0,r3
        ldbrx   r10,0,r4      <-
      
      Which shows us doing an 8 byte load from c00000062ac3fff9, which
      crosses the page boundary at c00000062ac40000 and faults.
      
      It's not OK for memcmp to read past the end of the source or
      destination buffers if that would cross a page boundary, because we
      don't know that the next page is mapped.
      
      As pointed out by Segher, we can read past the end of the source or
      destination as long as we don't cross a 4K boundary, because that's
      our minimum page size on all platforms.
      
      The bug is in the code at the .Lcmp_rest_lt8bytes label. When we get
      there we know that s1 is 8-byte aligned and we have at least 1 byte to
      read, so a single 8-byte load won't read past the end of s1 and cross
      a page boundary.
      
      But we have to be more careful with s2. So check if it's within 8
      bytes of a 4K boundary and if so go to the byte-by-byte loop.
      
      Fixes: 2d9ee327 ("powerpc/64: Align bytes before fall back to .Lshort in powerpc64 memcmp()")
      Cc: stable@vger.kernel.org # v4.19+
      Reported-by: NChandan Rajendra <chandan@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: NSegher Boessenkool <segher@kernel.crashing.org>
      Tested-by: NChandan Rajendra <chandan@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c91d07ad
    • G
      powerpc/pseries/energy: Use OF accessor functions to read ibm,drc-indexes · d7c00bbb
      Gautham R. Shenoy 提交于
      commit ce9afe08e71e3f7d64f337a6e932e50849230fc2 upstream.
      
      In cpu_to_drc_index() in the case when FW_FEATURE_DRC_INFO is absent,
      we currently use of_read_property() to obtain the pointer to the array
      corresponding to the property "ibm,drc-indexes". The elements of this
      array are of type __be32, but are accessed without any conversion to
      the OS-endianness, which is buggy on a Little Endian OS.
      
      Fix this by using of_property_read_u32_index() accessor function to
      safely read the elements of the array.
      
      Fixes: e83636ac ("pseries/drc-info: Search DRC properties for CPU indexes")
      Cc: stable@vger.kernel.org # v4.16+
      Reported-by: NPavithra R. Prakash <pavrampu@in.ibm.com>
      Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Reviewed-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      [mpe: Make the WARN_ON a WARN_ON_ONCE so it's not retriggerable]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7c00bbb
    • R
      objtool: Query pkg-config for libelf location · 0603e3a9
      Rolf Eike Beer 提交于
      commit 056d28d135bca0b1d0908990338e00e9dadaf057 upstream.
      
      If it is not in the default location, compilation fails at several points.
      Signed-off-by: NRolf Eike Beer <eb@emlix.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/91a25e992566a7968fedc89ec80e7f4c83ad0548.1553622500.git.jpoimboe@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0603e3a9
    • A
      perf intel-pt: Fix TSC slip · a436cf64
      Adrian Hunter 提交于
      commit f3b4e06b3bda759afd042d3d5fa86bea8f1fe278 upstream.
      
      A TSC packet can slip past MTC packets so that the timestamp appears to
      go backwards. One estimate is that can be up to about 40 CPU cycles,
      which is certainly less than 0x1000 TSC ticks, but accept slippage an
      order of magnitude more to be on the safe side.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 79b58424 ("perf tools: Add Intel PT support for decoding MTC packets")
      Link: http://lkml.kernel.org/r/20190325135135.18348-1-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a436cf64
    • K
      perf pmu: Fix parser error for uncore event alias · 5f936633
      Kan Liang 提交于
      commit e94d6b7f615e6dfbaf9fba7db6011db561461d0c upstream.
      
      Perf fails to parse uncore event alias, for example:
      
        # perf stat -e unc_m_clockticks -a --no-merge sleep 1
        event syntax error: 'unc_m_clockticks'
                             \___ parser error
      
      Current code assumes that the event alias is from one specific PMU.
      
      To find the PMU, perf strcmps the PMU name of event alias with the real
      PMU name on the system.
      
      However, the uncore event alias may be from multiple PMUs with common
      prefix. The PMU name of uncore event alias is the common prefix.
      
      For example, UNC_M_CLOCKTICKS is clock event for iMC, which include 6
      PMUs with the same prefix "uncore_imc" on a skylake server.
      
      The real PMU names on the system for iMC are uncore_imc_0 ...
      uncore_imc_5.
      
      The strncmp is used to only check the common prefix for uncore event
      alias.
      
      With the patch:
      
        # perf stat -e unc_m_clockticks -a --no-merge sleep 1
        Performance counter stats for 'system wide':
      
             723,594,722      unc_m_clockticks [uncore_imc_5]
             724,001,954      unc_m_clockticks [uncore_imc_3]
             724,042,655      unc_m_clockticks [uncore_imc_1]
             724,161,001      unc_m_clockticks [uncore_imc_4]
             724,293,713      unc_m_clockticks [uncore_imc_2]
             724,340,901      unc_m_clockticks [uncore_imc_0]
      
             1.002090060 seconds time elapsed
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: stable@vger.kernel.org
      Fixes: ea1fa48c055f ("perf stat: Handle different PMU names with common prefix")
      Link: http://lkml.kernel.org/r/1552672814-156173-1-git-send-email-kan.liang@linux.intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f936633
    • L
      mm/migrate.c: add missing flush_dcache_page for non-mapped page migrate · f70ddae2
      Lars Persson 提交于
      commit d2b2c6dd227ba5b8a802858748ec9a780cb75b47 upstream.
      
      Our MIPS 1004Kc SoCs were seeing random userspace crashes with SIGILL
      and SIGSEGV that could not be traced back to a userspace code bug.  They
      had all the magic signs of an I/D cache coherency issue.
      
      Now recently we noticed that the /proc/sys/vm/compact_memory interface
      was quite efficient at provoking this class of userspace crashes.
      
      Studying the code in mm/migrate.c there is a distinction made between
      migrating a page that is mapped at the instant of migration and one that
      is not mapped.  Our problem turned out to be the non-mapped pages.
      
      For the non-mapped page the code performs a copy of the page content and
      all relevant meta-data of the page without doing the required D-cache
      maintenance.  This leaves dirty data in the D-cache of the CPU and on
      the 1004K cores this data is not visible to the I-cache.  A subsequent
      page-fault that triggers a mapping of the page will happily serve the
      process with potentially stale code.
      
      What about ARM then, this bug should have seen greater exposure? Well
      ARM became immune to this flaw back in 2010, see commit c0177800
      ("ARM: 6379/1: Assume new page cache pages have dirty D-cache").
      
      My proposed fix moves the D-cache maintenance inside move_to_new_page to
      make it common for both cases.
      
      Link: http://lkml.kernel.org/r/20190315083502.11849-1-larper@axis.com
      Fixes: 97ee0524 ("flush cache before installing new page at migraton")
      Signed-off-by: NLars Persson <larper@axis.com>
      Reviewed-by: NPaul Burton <paul.burton@mips.com>
      Acked-by: NMel Gorman <mgorman@techsingularity.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f70ddae2
    • Y
      mm: mempolicy: make mbind() return -EIO when MPOL_MF_STRICT is specified · 5966777d
      Yang Shi 提交于
      commit a7f40cfe3b7ada57af9b62fd28430eeb4a7cfcb7 upstream.
      
      When MPOL_MF_STRICT was specified and an existing page was already on a
      node that does not follow the policy, mbind() should return -EIO.  But
      commit 6f4576e3 ("mempolicy: apply page table walker on
      queue_pages_range()") broke the rule.
      
      And commit c8633798 ("mm: mempolicy: mbind and migrate_pages support
      thp migration") didn't return the correct value for THP mbind() too.
      
      If MPOL_MF_STRICT is set, ignore vma_migratable() to make sure it
      reaches queue_pages_to_pte_range() or queue_pages_pmd() to check if an
      existing page was already on a node that does not follow the policy.
      And, non-migratable vma may be used, return -EIO too if MPOL_MF_MOVE or
      MPOL_MF_MOVE_ALL was specified.
      
      Tested with https://github.com/metan-ucw/ltp/blob/master/testcases/kernel/syscalls/mbind/mbind02.c
      
      [akpm@linux-foundation.org: tweak code comment]
      Link: http://lkml.kernel.org/r/1553020556-38583-1-git-send-email-yang.shi@linux.alibaba.com
      Fixes: 6f4576e3 ("mempolicy: apply page table walker on queue_pages_range()")
      Signed-off-by: NYang Shi <yang.shi@linux.alibaba.com>
      Signed-off-by: NOscar Salvador <osalvador@suse.de>
      Reported-by: NCyril Hrubis <chrubis@suse.cz>
      Suggested-by: NKirill A. Shutemov <kirill@shutemov.name>
      Acked-by: NRafael Aquini <aquini@redhat.com>
      Reviewed-by: NOscar Salvador <osalvador@suse.de>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5966777d
    • N
      iommu/io-pgtable-arm-v7s: request DMA32 memory, and improve debugging · c9874d39
      Nicolas Boichat 提交于
      commit 0a352554da69b02f75ca3389c885c741f1f63235 upstream.
      
      IOMMUs using ARMv7 short-descriptor format require page tables (level 1
      and 2) to be allocated within the first 4GB of RAM, even on 64-bit
      systems.
      
      For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32 is
      defined (e.g.  on arm64 platforms).
      
      For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32.  Note that
      we do not explicitly pass GFP_DMA[32] to kmem_cache_zalloc, as this is
      not strictly necessary, and would cause a warning in mm/sl*b.c, as we
      did not update GFP_SLAB_BUG_MASK.
      
      Also, print an error when the physical address does not fit in
      32-bit, to make debugging easier in the future.
      
      Link: http://lkml.kernel.org/r/20181210011504.122604-3-drinkcat@chromium.org
      Fixes: ad67f5a6 ("arm64: replace ZONE_DMA with ZONE_DMA32")
      Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Hsin-Yi Wang <hsinyi@chromium.org>
      Cc: Huaisheng Ye <yehs1@lenovo.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Matthias Brugger <matthias.bgg@gmail.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Sasha Levin <Alexander.Levin@microsoft.com>
      Cc: Tomasz Figa <tfiga@google.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Yong Wu <yong.wu@mediatek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c9874d39
    • N
      mm: add support for kmem caches in DMA32 zone · 62d342d6
      Nicolas Boichat 提交于
      commit 6d6ea1e967a246f12cfe2f5fb743b70b2e608d4a upstream.
      
      Patch series "iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables",
      v6.
      
      This is a followup to the discussion in [1], [2].
      
      IOMMUs using ARMv7 short-descriptor format require page tables (level 1
      and 2) to be allocated within the first 4GB of RAM, even on 64-bit
      systems.
      
      For L1 tables that are bigger than a page, we can just use
      __get_free_pages with GFP_DMA32 (on arm64 systems only, arm would still
      use GFP_DMA).
      
      For L2 tables that only take 1KB, it would be a waste to allocate a full
      page, so we considered 3 approaches:
       1. This series, adding support for GFP_DMA32 slab caches.
       2. genalloc, which requires pre-allocating the maximum number of L2 page
          tables (4096, so 4MB of memory).
       3. page_frag, which is not very memory-efficient as it is unable to reuse
          freed fragments until the whole page is freed. [3]
      
      This series is the most memory-efficient approach.
      
      stable@ note:
        We confirmed that this is a regression, and IOMMU errors happen on 4.19
        and linux-next/master on MT8173 (elm, Acer Chromebook R13). The issue
        most likely starts from commit ad67f5a6 ("arm64: replace ZONE_DMA
        with ZONE_DMA32"), i.e. 4.15, and presumably breaks a number of Mediatek
        platforms (and maybe others?).
      
      [1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html
      [2] https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031696.html
      [3] https://patchwork.codeaurora.org/patch/671639/
      
      This patch (of 3):
      
      IOMMUs using ARMv7 short-descriptor format require page tables to be
      allocated within the first 4GB of RAM, even on 64-bit systems.  On arm64,
      this is done by passing GFP_DMA32 flag to memory allocation functions.
      
      For IOMMU L2 tables that only take 1KB, it would be a waste to allocate
      a full page using get_free_pages, so we considered 3 approaches:
       1. This patch, adding support for GFP_DMA32 slab caches.
       2. genalloc, which requires pre-allocating the maximum number of L2
          page tables (4096, so 4MB of memory).
       3. page_frag, which is not very memory-efficient as it is unable
          to reuse freed fragments until the whole page is freed.
      
      This change makes it possible to create a custom cache in DMA32 zone using
      kmem_cache_create, then allocate memory using kmem_cache_alloc.
      
      We do not create a DMA32 kmalloc cache array, as there are currently no
      users of kmalloc(..., GFP_DMA32).  These calls will continue to trigger a
      warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.
      
      This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
      kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
      unnecessary).
      
      Link: http://lkml.kernel.org/r/20181210011504.122604-2-drinkcat@chromium.orgSigned-off-by: NNicolas Boichat <drinkcat@chromium.org>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Sasha Levin <Alexander.Levin@microsoft.com>
      Cc: Huaisheng Ye <yehs1@lenovo.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Yong Wu <yong.wu@mediatek.com>
      Cc: Matthias Brugger <matthias.bgg@gmail.com>
      Cc: Tomasz Figa <tfiga@google.com>
      Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Hsin-Yi Wang <hsinyi@chromium.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      62d342d6
    • R
      usb: cdc-acm: fix race during wakeup blocking TX traffic · 2392ffab
      Romain Izard 提交于
      commit 93e1c8a638308980309e009cc40b5a57ef87caf1 upstream.
      
      When the kernel is compiled with preemption enabled, the URB completion
      handler can run in parallel with the work responsible for waking up the
      tty layer. If the URB handler sets the EVENT_TTY_WAKEUP bit during the
      call to tty_port_tty_wakeup() to signal that there is room for additional
      input, it will be cleared at the end of this call. As a result, TX traffic
      on the upper layer will be blocked.
      
      This can be seen with a kernel configured with CONFIG_PREEMPT, and a fast
      modem connected with PPP running over a USB CDC-ACM port.
      
      Use test_and_clear_bit() instead, which ensures that each wakeup requested
      by the URB completion code will trigger a call to tty_port_tty_wakeup().
      
      Fixes: 1aba579f cdc-acm: handle read pipe errors
      Signed-off-by: NRomain Izard <romain.izard.pro@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2392ffab
    • M
      xhci: Don't let USB3 ports stuck in polling state prevent suspend · 82a5090a
      Mathias Nyman 提交于
      commit d92f2c59cc2cbca6bfb2cc54882b58ba76b15fd4 upstream.
      
      Commit 2f31a67f01a8 ("usb: xhci: Prevent bus suspend if a port connect
      change or polling state is detected") was intended to prevent ports that
      were still link training from being forced to U3 suspend state mid
      enumeration.
      This solved enumeration issues for devices with slow link training.
      
      Turns out some devices are stuck in the link training/polling state,
      and thus that patch will prevent suspend completely for these devices.
      This is seen with USB3 card readers in some MacBooks.
      
      Instead of preventing suspend, give some time to complete the link
      training. On successful training the port will end up as connected
      and enabled.
      If port instead is stuck in link training the bus suspend will continue
      suspending after 360ms (10 * 36ms) timeout (tPollingLFPSTimeout).
      
      Original patch was sent to stable, this one should go there as well
      
      Fixes: 2f31a67f01a8 ("usb: xhci: Prevent bus suspend if a port connect change or polling state is detected")
      Cc: stable@vger.kernel.org
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      82a5090a
    • M
      usb: xhci: dbc: Don't free all memory with spinlock held · 20a09a2e
      Mathias Nyman 提交于
      commit 8867ea262196a6945c24a0fb739575af646ec0e9 upstream.
      
      The xhci debug capability (DbC) feature did its memory cleanup with
      spinlock held. dma_free_coherent() warns if called with interrupts
      disabled
      
      move the memory cleanup outside the spinlock
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20a09a2e
    • M
      xhci: Fix port resume done detection for SS ports with LPM enabled · c81b8722
      Mathias Nyman 提交于
      commit 6cbcf596934c8e16d6288c7cc62dfb7ad8eadf15 upstream.
      
      A suspended SS port in U3 link state will go to U0 when resumed, but
      can almost immediately after that enter U1 or U2 link power save
      states before host controller driver reads the port status.
      
      Host controller driver only checks for U0 state, and might miss
      the finished resume, leaving flags unclear and skip notifying usb
      code of the wake.
      
      Add U1 and U2 to the possible link states when checking for finished
      port resume.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c81b8722
    • Y
      usb: host: xhci-rcar: Add XHCI_TRUST_TX_LENGTH quirk · 093ccda1
      Yasushi Asano 提交于
      commit 40fc165304f0faaae78b761f8ee30b5d216b1850 upstream.
      
      When plugging BUFFALO LUA4-U3-AGT USB3.0 to Gigabit Ethernet LAN
      Adapter, warning messages filled up dmesg.
      
      [  101.098287] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
      [  101.117463] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
      [  101.136513] xhci-hcd ee000000.usb: WARN Successful completion on short TX for slot 1 ep 4: needs XHCI_TRUST_TX_LENGTH quirk?
      
      Adding the XHCI_TRUST_TX_LENGTH quirk resolves the issue.
      Signed-off-by: NYasushi Asano <yasano@jp.adit-jv.com>
      Signed-off-by: NSpyridon Papageorgiou <spapageorgiou@de.adit-jv.com>
      Acked-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      093ccda1
    • F
      usb: common: Consider only available nodes for dr_mode · 015e5c17
      Fabrizio Castro 提交于
      commit 238e0268c82789e4c107a37045d529a6dbce51a9 upstream.
      
      There are cases where multiple device tree nodes point to the
      same phy node by means of the "phys" property, but we should
      only consider those nodes that are marked as available rather
      than just any node.
      
      Fixes: 98bfb394 ("usb: of: add an api to get dr_mode by the phy node")
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      015e5c17
    • R
      USB: gadget: f_hid: fix deadlock in f_hidg_write() · ef4df134
      Radoslav Gerganov 提交于
      commit 072684e8c58d17e853f8e8b9f6d9ce2e58d2b036 upstream.
      
      In f_hidg_write() the write_spinlock is acquired before calling
      usb_ep_queue() which causes a deadlock when dummy_hcd is being used.
      This is because dummy_queue() callbacks into f_hidg_req_complete() which
      tries to acquire the same spinlock. This is (part of) the backtrace when
      the deadlock occurs:
      
        0xffffffffc06b1410 in f_hidg_req_complete
        0xffffffffc06a590a in usb_gadget_giveback_request
        0xffffffffc06cfff2 in dummy_queue
        0xffffffffc06a4b96 in usb_ep_queue
        0xffffffffc06b1eb6 in f_hidg_write
        0xffffffff8127730b in __vfs_write
        0xffffffff812774d1 in vfs_write
        0xffffffff81277725 in SYSC_write
      
      Fix this by releasing the write_spinlock before calling usb_ep_queue()
      Reviewed-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Tested-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: stable@vger.kernel.org # 4.11+
      Fixes: 749494b6 ("usb: gadget: f_hid: fix: Move IN request allocation to set_alt()")
      Signed-off-by: NRadoslav Gerganov <rgerganov@vmware.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef4df134
    • A
      usb: mtu3: fix EXTCON dependency · 614ac345
      Arnd Bergmann 提交于
      commit 3d54d10c6afed34fd45b852bf76f55e8da31d8ef upstream.
      
      When EXTCON is a loadable module, mtu3 fails to link as built-in:
      
      drivers/usb/mtu3/mtu3_plat.o: In function `mtu3_probe':
      mtu3_plat.c:(.text+0x690): undefined reference to `extcon_get_edev_by_phandle'
      
      Add a Kconfig dependency to force mtu3 also to be a loadable module
      if extconn is, but still allow it to be built without extcon.
      
      Fixes: d0ed062a ("usb: mtu3: dual-role mode support")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      614ac345
    • C
      phy: sun4i-usb: Support set_mode to USB_HOST for non-OTG PHYs · 66e44981
      Chen-Yu Tsai 提交于
      commit 1396929e8a903db80425343cacca766a18ad6409 upstream.
      
      While only the first PHY supports mode switching, the remaining PHYs
      work in USB host mode. They should support set_mode with mode=USB_HOST
      instead of failing. This is especially needed now that the USB core does
      set_mode for all USB ports, which was added in commit b97a31348379 ("usb:
      core: comply to PHY framework").
      
      Make set_mode with mode=USB_HOST a no-op instead of failing for the
      non-OTG USB PHYs.
      
      Fixes: 6ba43c29 ("phy-sun4i-usb: Add support for phy_set_mode")
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66e44981
    • A
      gpio: adnp: Fix testing wrong value in adnp_gpio_direction_input · 6ebe0373
      Axel Lin 提交于
      commit c5bc6e526d3f217ed2cc3681d256dc4a2af4cc2b upstream.
      
      Current code test wrong value so it does not verify if the written
      data is correctly read back. Fix it.
      Also make it return -EPERM if read value does not match written bit,
      just like it done for adnp_gpio_direction_output().
      
      Fixes: 5e969a40 ("gpio: Add Avionic Design N-bit GPIO expander support")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAxel Lin <axel.lin@ingics.com>
      Reviewed-by: NThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ebe0373
    • K
      gpio: exar: add a check for the return value of ida_simple_get fails · b26f7e86
      Kangjie Lu 提交于
      commit 7ecced0934e574b528a1ba6c237731e682216a74 upstream.
      
      ida_simple_get may fail and return a negative error number.
      The fix checks its return value; if it fails, go to err_destroy.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b26f7e86
    • Z
      drm/i915/gvt: Fix MI_FLUSH_DW parsing with correct index check · df74e70f
      Zhenyu Wang 提交于
      commit 13bcb80b7ee79431fce361e060611134cb19e209 upstream.
      
      When MI_FLUSH_DW post write hw status page in index mode, the index
      value is in dword step and turned into address offset in cmd dword1.
      As status page size is 4K, so can't exceed that.
      
      This fixed upper bound check in cmd parser code which incorrectly
      stopped VM for reason of invalid MI_FLUSH_DW write index.
      
      v2:
      - Fix upper bound as 4K page size because index value is address offset.
      
      Fixes: be1da707 ("drm/i915/gvt: vGPU command scanner")
      Cc: stable@vger.kernel.org # v4.10+
      Cc: "Zhao, Yan Y" <yan.y.zhao@intel.com>
      Reviewed-by: NYan Zhao <yan.y.zhao@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df74e70f
    • E
      drm/vkms: fix use-after-free when drm_gem_handle_create() fails · 75f9e994
      Eric Biggers 提交于
      commit 36b6c9ed45afe89045973e8dee1b004dd5372d40 upstream.
      
      If drm_gem_handle_create() fails in vkms_gem_create(), then the
      vkms_gem_object is freed twice: once when the reference is dropped by
      drm_gem_object_put_unlocked(), and again by the extra calls to
      drm_gem_object_release() and kfree().
      
      Fix it by skipping the second release and free.
      
      This bug was originally found in the vgem driver by syzkaller using
      fault injection, but I noticed it's also present in the vkms driver.
      
      Fixes: 559e50fd ("drm/vkms: Add dumb operations")
      Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Signed-off-by: NRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190226220858.214438-1-ebiggers@kernel.orgSigned-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75f9e994
    • E
      drm/vgem: fix use-after-free when drm_gem_handle_create() fails · eb1e5525
      Eric Biggers 提交于
      commit 21d2b122732318b48c10b7262e15595ce54511d3 upstream.
      
      If drm_gem_handle_create() fails in vgem_gem_create(), then the
      drm_vgem_gem_object is freed twice: once when the reference is dropped
      by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
      
      This was hit by syzkaller using fault injection.
      
      Fix it by skipping the second free.
      
      Reported-by: syzbot+e73f2fb5ed5a5df36d33@syzkaller.appspotmail.com
      Fixes: af33a919 ("drm/vgem: Enable dmabuf import interfaces")
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Acked-by: NLaura Abbott <labbott@redhat.com>
      Signed-off-by: NRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190226214451.195123-1-ebiggers@kernel.orgSigned-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb1e5525
    • Y
      fs/proc/proc_sysctl.c: fix NULL pointer dereference in put_links · 07d0d2bd
      YueHaibing 提交于
      commit 23da9588037ecdd4901db76a5b79a42b529c4ec3 upstream.
      
      Syzkaller reports:
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN PTI
      CPU: 1 PID: 5373 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:put_links+0x101/0x440 fs/proc/proc_sysctl.c:1599
      Code: 00 0f 85 3a 03 00 00 48 8b 43 38 48 89 44 24 20 48 83 c0 38 48 89 c2 48 89 44 24 28 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 fe 02 00 00 48 8b 74 24 20 48 c7 c7 60 2a 9d 91
      RSP: 0018:ffff8881d828f238 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff8881e01b1140 RCX: ffffffff8ee98267
      RDX: 0000000000000007 RSI: ffffc90001479000 RDI: ffff8881e01b1178
      RBP: dffffc0000000000 R08: ffffed103ee27259 R09: ffffed103ee27259
      R10: 0000000000000001 R11: ffffed103ee27258 R12: fffffffffffffff4
      R13: 0000000000000006 R14: ffff8881f59838c0 R15: dffffc0000000000
      FS:  00007f072254f700(0000) GS:ffff8881f7100000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fff8b286668 CR3: 00000001f0542002 CR4: 00000000007606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       drop_sysctl_table+0x152/0x9f0 fs/proc/proc_sysctl.c:1629
       get_subdir fs/proc/proc_sysctl.c:1022 [inline]
       __register_sysctl_table+0xd65/0x1090 fs/proc/proc_sysctl.c:1335
       br_netfilter_init+0xbc/0x1000 [br_netfilter]
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f072254ec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003
      RBP: 00007f072254ec70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f072254f6bc
      R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
      Modules linked in: br_netfilter(+) dvb_usb_dibusb_mc_common dib3000mc dibx000_common dvb_usb_dibusb_common dvb_usb_dw2102 dvb_usb classmate_laptop palmas_regulator cn videobuf2_v4l2 v4l2_common snd_soc_bd28623 mptbase snd_usb_usx2y snd_usbmidi_lib snd_rawmidi wmi libnvdimm lockd sunrpc grace rc_kworld_pc150u rc_core rtc_da9063 sha1_ssse3 i2c_cros_ec_tunnel adxl34x_spi adxl34x nfnetlink lib80211 i5500_temp dvb_as102 dvb_core videobuf2_common videodev media videobuf2_vmalloc videobuf2_memops udc_core lnbp22 leds_lp3952 hid_roccat_ryos s1d13xxxfb mtd vport_geneve openvswitch nf_conncount nf_nat_ipv6 nsh geneve udp_tunnel ip6_udp_tunnel snd_soc_mt6351 sis_agp phylink snd_soc_adau1761_spi snd_soc_adau1761 snd_soc_adau17x1 snd_soc_core snd_pcm_dmaengine ac97_bus snd_compress snd_soc_adau_utils snd_soc_sigmadsp_regmap snd_soc_sigmadsp raid_class hid_roccat_konepure hid_roccat_common hid_roccat c2port_duramar2150 core mdio_bcm_unimac iptable_security iptable_raw iptable_mangle
       iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim devlink vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel joydev mousedev ide_pci_generic piix aesni_intel aes_x86_64 ide_core crypto_simd atkbd cryptd glue_helper serio_raw ata_generic pata_acpi i2c_piix4 floppy sch_fq_codel ip_tables x_tables ipv6 [last unloaded: lm73]
      Dumping ftrace buffer:
         (ftrace buffer empty)
      ---[ end trace 770020de38961fd0 ]---
      
      A new dir entry can be created in get_subdir and its 'header->parent' is
      set to NULL.  Only after insert_header success, it will be set to 'dir',
      otherwise 'header->parent' is set to NULL and drop_sysctl_table is called.
      However in err handling path of get_subdir, drop_sysctl_table also be
      called on 'new->header' regardless its value of parent pointer.  Then
      put_links is called, which triggers NULL-ptr deref when access member of
      header->parent.
      
      In fact we have multiple error paths which call drop_sysctl_table() there,
      upon failure on insert_links() we also call drop_sysctl_table().And even
      in the successful case on __register_sysctl_table() we still always call
      drop_sysctl_table().This patch fix it.
      
      Link: http://lkml.kernel.org/r/20190314085527.13244-1-yuehaibing@huawei.com
      Fixes: 0e47c99d ("sysctl: Replace root_list with links between sysctl_table_sets")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Acked-by: NLuis Chamberlain <mcgrof@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: <stable@vger.kernel.org>    [3.4+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07d0d2bd
    • W
      Disable kgdboc failed by echo space to /sys/module/kgdboc/parameters/kgdboc · c956914f
      Wentao Wang 提交于
      commit 3ec8002951ea173e24b466df1ea98c56b7920e63 upstream.
      
      Echo "" to /sys/module/kgdboc/parameters/kgdboc will fail with "No such
      device” error.
      
      This is caused by function "configure_kgdboc" who init err to ENODEV
      when the config is empty (legal input) the code go out with ENODEV
      returned.
      
      Fixes: 2dd453168643 ("kgdboc: Fix restrict error")
      Signed-off-by: NWentao Wang <witallwang@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c956914f
    • B
      USB: serial: option: add Olicard 600 · 1c992ea0
      Bjørn Mork 提交于
      commit 84f3b43f7378b98b7e3096d5499de75183d4347c upstream.
      
      This is a Qualcomm based device with a QMI function on interface 4.
      It is mode switched from 2020:2030 using a standard eject message.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2020 ProdID=2031 Rev= 2.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
      E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
      E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
      E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      [ johan: use tabs to align comments in adjacent lines ]
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1c992ea0
    • K
      USB: serial: option: add support for Quectel EM12 · 19151c64
      Kristian Evensen 提交于
      commit d1252f0237238b912c3e7a51bf237acf34c97983 upstream.
      
      The Quectel EM12 is a Cat. 12 LTE modem. It behaves in the exactly the
      same way as the EP06 (including the dynamic configuration behavior), so
      the same checks on reserved interfaces, etc. are needed.
      Signed-off-by: NKristian Evensen <kristian.evensen@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19151c64
    • M
      USB: serial: option: set driver_info for SIM5218 and compatibles · 002795b0
      Mans Rullgard 提交于
      commit f8df5c2c3e2df5ffaf9fb5503da93d477a8c7db4 upstream.
      
      The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4
      of which are serial ports.  The fifth is a network interface supported
      by the qmi-wwan driver.  Furthermore, the serial ports do not support
      modem control signals.  Add driver_info flags to reflect this.
      Signed-off-by: NMans Rullgard <mans@mansr.com>
      Fixes: ec0cd94d ("usb: option: add SIMCom SIM5218")
      Cc: stable <stable@vger.kernel.org>	# 3.2
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      002795b0
    • L
      USB: serial: mos7720: fix mos_parport refcount imbalance on error path · d7dfccfd
      Lin Yi 提交于
      commit 2908b076f5198d231de62713cb2b633a3a4b95ac upstream.
      
      The write_parport_reg_nonblock() helper takes a reference to the struct
      mos_parport, but failed to release it in a couple of error paths after
      allocation failures, leading to a memory leak.
      
      Johan said that move the kref_get() and mos_parport assignment to the
      end of urbtrack initialisation is a better way, so move it. and
      mos_parport do not used until urbtrack initialisation.
      Signed-off-by: NLin Yi <teroincn@163.com>
      Fixes: b69578df ("USB: usbserial: mos7720: add support for parallel port on moschip 7715")
      Cc: stable <stable@vger.kernel.org>     # 2.6.35
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7dfccfd
    • G
      USB: serial: ftdi_sio: add additional NovaTech products · 1f46db3c
      George McCollister 提交于
      commit 422c2537ba9d42320f8ab6573940269f87095320 upstream.
      
      Add PIDs for the NovaTech OrionLX+ and Orion I/O so they can be
      automatically detected.
      Signed-off-by: NGeorge McCollister <george.mccollister@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f46db3c
    • G
      USB: serial: cp210x: add new device id · 2a630035
      Greg Kroah-Hartman 提交于
      commit a595ecdd5f60b2d93863cebb07eec7f935839b54 upstream.
      
      Lorenz Messtechnik has a device that is controlled by the cp210x driver,
      so add the device id to the driver.  The device id was provided by
      Silicon-Labs for the devices from this vendor.
      Reported-by: NUli <t9cpu@web.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a630035
    • H
      serial: sh-sci: Fix setting SCSCR_TIE while transferring data · 59203f07
      Hoan Nguyen An 提交于
      commit 93bcefd4c6bad4c69dbc4edcd3fbf774b24d930d upstream.
      
      We disable transmission interrupt (clear SCSCR_TIE) after all data has been transmitted
      (if uart_circ_empty(xmit)). While transmitting, if the data is still in the tty buffer,
      re-enable the SCSCR_TIE bit, which was done at sci_start_tx().
      This is unnecessary processing, wasting CPU operation if the data transmission length is large.
      And further, transmit end, FIFO empty bits disabling have also been performed in the step above.
      Signed-off-by: NHoan Nguyen An <na-hoan@jinso.co.jp>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59203f07
    • A
      serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference · b1e660c6
      Aditya Pakki 提交于
      commit 32f47179833b63de72427131169809065db6745e upstream.
      
      of_match_device on failure to find a matching device can return a NULL
      pointer. The patch checks for such a scenrio and passes the error upstream.
      Signed-off-by: NAditya Pakki <pakki001@umn.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1e660c6
    • A
      serial: max310x: Fix to avoid potential NULL pointer dereference · f34ec64b
      Aditya Pakki 提交于
      commit 3a10e3dd52e80b9a97a3346020024d17b2c272d6 upstream.
      
      of_match_device can return a NULL pointer when matching device is not
      found. This patch avoids a scenario causing NULL pointer derefernce.
      Signed-off-by: NAditya Pakki <pakki001@umn.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f34ec64b