1. 07 9月, 2019 2 次提交
  2. 06 9月, 2019 12 次提交
  3. 05 9月, 2019 3 次提交
    • D
      drm/vmwgfx: Fix double free in vmw_recv_msg() · 08b0c891
      Dan Carpenter 提交于
      We recently added a kfree() after the end of the loop:
      
      	if (retries == RETRIES) {
      		kfree(reply);
      		return -EINVAL;
      	}
      
      There are two problems.  First the test is wrong and because retries
      equals RETRIES if we succeed on the last iteration through the loop.
      Second if we fail on the last iteration through the loop then the kfree
      is a double free.
      
      When you're reading this code, please note the break statement at the
      end of the while loop.  This patch changes the loop so that if it's not
      successful then "reply" is NULL and we can test for that afterward.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 6b7c3b86 ("drm/vmwgfx: fix memory leak when too many retries have occurred")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      08b0c891
    • L
      Merge tag 'nfs-for-5.3-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs · 3b47fd5c
      Linus Torvalds 提交于
      Pull NFS client bugfix from Trond Myklebust:
       "Regression fix inode fileid checks in attribute revalidation code"
      
      * tag 'nfs-for-5.3-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
        NFS: Fix inode fileid checks in attribute revalidation code
      3b47fd5c
    • I
      sched/core: Fix uclamp ABI bug, clean up and robustify sched_read_attr() ABI logic and code · 1251201c
      Ingo Molnar 提交于
      Thadeu Lima de Souza Cascardo reported that 'chrt' broke on recent kernels:
      
        $ chrt -p $$
        chrt: failed to get pid 26306's policy: Argument list too long
      
      and he has root-caused the bug to the following commit increasing sched_attr
      size and breaking sched_read_attr() into returning -EFBIG:
      
        a509a7cd ("sched/uclamp: Extend sched_setattr() to support utilization clamping")
      
      The other, bigger bug is that the whole sched_getattr() and sched_read_attr()
      logic of checking non-zero bits in new ABI components is arguably broken,
      and pretty much any extension of the ABI will spuriously break the ABI.
      That's way too fragile.
      
      Instead implement the perf syscall's extensible ABI instead, which we
      already implement on the sched_setattr() side:
      
       - if user-attributes have the same size as kernel attributes then the
         logic is unchanged.
      
       - if user-attributes are larger than the kernel knows about then simply
         skip the extra bits, but set attr->size to the (smaller) kernel size
         so that tooling can (in principle) handle older kernel as well.
      
       - if user-attributes are smaller than the kernel knows about then just
         copy whatever user-space can accept.
      
      Also clean up the whole logic:
      
       - Simplify the code flow - there's no need for 'ret' for example.
      
       - Standardize on 'kattr/uattr' and 'ksize/usize' naming to make sure we
         always know which side we are dealing with.
      
       - Why is it called 'read' when what it does is to copy to user? This
         code is so far away from VFS read() semantics that the naming is
         actively confusing. Name it sched_attr_copy_to_user() instead, which
         mirrors other copy_to_user() functionality.
      
       - Move the attr->size assignment from the head of sched_getattr() to the
         sched_attr_copy_to_user() function. Nothing else within the kernel
         should care about the size of the structure.
      
      With these fixes the sched_getattr() syscall now nicely supports an
      extensible ABI in both a forward and backward compatible fashion, and
      will also fix the chrt bug.
      
      As an added bonus the bogus -EFBIG return is removed as well, which as
      Thadeu noted should have been -E2BIG to begin with.
      Reported-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Tested-by: NDietmar Eggemann <dietmar.eggemann@arm.com>
      Tested-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Acked-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Patrick Bellasi <patrick.bellasi@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: a509a7cd ("sched/uclamp: Extend sched_setattr() to support utilization clamping")
      Link: https://lkml.kernel.org/r/20190904075532.GA26751@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1251201c
  4. 04 9月, 2019 9 次提交
    • G
      powerpc/tm: Fix restoring FP/VMX facility incorrectly on interrupts · a8318c13
      Gustavo Romero 提交于
      When in userspace and MSR FP=0 the hardware FP state is unrelated to
      the current process. This is extended for transactions where if tbegin
      is run with FP=0, the hardware checkpoint FP state will also be
      unrelated to the current process. Due to this, we need to ensure this
      hardware checkpoint is updated with the correct state before we enable
      FP for this process.
      
      Unfortunately we get this wrong when returning to a process from a
      hardware interrupt. A process that starts a transaction with FP=0 can
      take an interrupt. When the kernel returns back to that process, we
      change to FP=1 but with hardware checkpoint FP state not updated. If
      this transaction is then rolled back, the FP registers now contain the
      wrong state.
      
      The process looks like this:
         Userspace:                      Kernel
      
                     Start userspace
                      with MSR FP=0 TM=1
                        < -----
         ...
         tbegin
         bne
                     Hardware interrupt
                         ---- >
                                          <do_IRQ...>
                                          ....
                                          ret_from_except
                                            restore_math()
      				        /* sees FP=0 */
                                              restore_fp()
                                                tm_active_with_fp()
      					    /* sees FP=1 (Incorrect) */
                                                load_fp_state()
                                              FP = 0 -> 1
                        < -----
                     Return to userspace
                       with MSR TM=1 FP=1
                       with junk in the FP TM checkpoint
         TM rollback
         reads FP junk
      
      When returning from the hardware exception, tm_active_with_fp() is
      incorrectly making restore_fp() call load_fp_state() which is setting
      FP=1.
      
      The fix is to remove tm_active_with_fp().
      
      tm_active_with_fp() is attempting to handle the case where FP state
      has been changed inside a transaction. In this case the checkpointed
      and transactional FP state is different and hence we must restore the
      FP state (ie. we can't do lazy FP restore inside a transaction that's
      used FP). It's safe to remove tm_active_with_fp() as this case is
      handled by restore_tm_state(). restore_tm_state() detects if FP has
      been using inside a transaction and will set load_fp and call
      restore_math() to ensure the FP state (checkpoint and transaction) is
      restored.
      
      This is a data integrity problem for the current process as the FP
      registers are corrupted. It's also a security problem as the FP
      registers from one process may be leaked to another.
      
      Similarly for VMX.
      
      A simple testcase to replicate this will be posted to
      tools/testing/selftests/powerpc/tm/tm-poison.c
      
      This fixes CVE-2019-15031.
      
      Fixes: a7771176 ("powerpc: Don't enable FP/Altivec if not checkpointed")
      Cc: stable@vger.kernel.org # 4.15+
      Signed-off-by: NGustavo Romero <gromero@linux.ibm.com>
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190904045529.23002-2-gromero@linux.vnet.ibm.com
      a8318c13
    • G
      powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction · 8205d5d9
      Gustavo Romero 提交于
      When we take an FP unavailable exception in a transaction we have to
      account for the hardware FP TM checkpointed registers being
      incorrect. In this case for this process we know the current and
      checkpointed FP registers must be the same (since FP wasn't used
      inside the transaction) hence in the thread_struct we copy the current
      FP registers to the checkpointed ones.
      
      This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr
      to determine if FP was on when in userspace. thread->ckpt_regs.msr
      represents the state of the MSR when exiting userspace. This is setup
      by check_if_tm_restore_required().
      
      Unfortunatley there is an optimisation in giveup_all() which returns
      early if tsk->thread.regs->msr (via local variable `usermsr`) has
      FP=VEC=VSX=SPE=0. This optimisation means that
      check_if_tm_restore_required() is not called and hence
      thread->ckpt_regs.msr is not updated and will contain an old value.
      
      This can happen if due to load_fp=255 we start a userspace process
      with MSR FP=1 and then we are context switched out. In this case
      thread->ckpt_regs.msr will contain FP=1. If that same process is then
      context switched in and load_fp overflows, MSR will have FP=0. If that
      process now enters a transaction and does an FP instruction, the FP
      unavailable will not update thread->ckpt_regs.msr (the bug) and MSR
      FP=1 will be retained in thread->ckpt_regs.msr.  tm_reclaim_thread()
      will then not perform the required memcpy and the checkpointed FP regs
      in the thread struct will contain the wrong values.
      
      The code path for this happening is:
      
             Userspace:                      Kernel
                         Start userspace
                          with MSR FP/VEC/VSX/SPE=0 TM=1
                            < -----
             ...
             tbegin
             bne
             fp instruction
                         FP unavailable
                             ---- >
                                              fp_unavailable_tm()
      					  tm_reclaim_current()
      					    tm_reclaim_thread()
      					      giveup_all()
      					        return early since FP/VMX/VSX=0
      						/* ckpt MSR not updated (Incorrect) */
      					      tm_reclaim()
      					        /* thread_struct ckpt FP regs contain junk (OK) */
                                                    /* Sees ckpt MSR FP=1 (Incorrect) */
      					      no memcpy() performed
      					        /* thread_struct ckpt FP regs not fixed (Incorrect) */
      					  tm_recheckpoint()
      					     /* Put junk in hardware checkpoint FP regs */
                                               ....
                            < -----
                         Return to userspace
                           with MSR TM=1 FP=1
                           with junk in the FP TM checkpoint
             TM rollback
             reads FP junk
      
      This is a data integrity problem for the current process as the FP
      registers are corrupted. It's also a security problem as the FP
      registers from one process may be leaked to another.
      
      This patch moves up check_if_tm_restore_required() in giveup_all() to
      ensure thread->ckpt_regs.msr is updated correctly.
      
      A simple testcase to replicate this will be posted to
      tools/testing/selftests/powerpc/tm/tm-poison.c
      
      Similarly for VMX.
      
      This fixes CVE-2019-15030.
      
      Fixes: f48e91e8 ("powerpc/tm: Fix FP and VMX register corruption")
      Cc: stable@vger.kernel.org # 4.12+
      Signed-off-by: NGustavo Romero <gromero@linux.vnet.ibm.com>
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com
      8205d5d9
    • N
      mm/balloon_compaction: suppress allocation warnings · 02fa5d7b
      Nadav Amit 提交于
      There is no reason to print warnings when balloon page allocation fails,
      as they are expected and can be handled gracefully.  Since VMware
      balloon now uses balloon-compaction infrastructure, and suppressed these
      warnings before, it is also beneficial to suppress these warnings to
      keep the same behavior that the balloon had before.
      
      Cc: Jason Wang <jasowang@redhat.com>
      Signed-off-by: NNadav Amit <namit@vmware.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      02fa5d7b
    • M
      Revert "vhost: access vq metadata through kernel virtual address" · 3d2c7d37
      Michael S. Tsirkin 提交于
      This reverts commit 7f466032 ("vhost: access vq metadata through
      kernel virtual address").  The commit caused a bunch of issues, and
      while commit 73f628ec ("vhost: disable metadata prefetch
      optimization") disabled the optimization it's not nice to keep lots of
      dead code around.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      3d2c7d37
    • Y
      vhost: Remove unnecessary variable · 896fc242
      Yunsheng Lin 提交于
      It is unnecessary to use ret variable to return the error
      code, just return the error code directly.
      Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      896fc242
    • ?
      virtio-net: lower min ring num_free for efficiency · 718be6ba
      ? jiang 提交于
      This change lowers ring buffer reclaim threshold from 1/2*queue to budget
      for better performance. According to our test with qemu + dpdk, packet
      dropping happens when the guest is not able to provide free buffer in
      avail ring timely with default 1/2*queue. The value in the patch has been
      tested and does show better performance.
      
      Test setup: iperf3 to generate packets to guest (total 30mins, pps 400k, UDP)
      avg packets drop before: 2842
      avg packets drop after: 360(-87.3%)
      
      Further, current code suffers from a starvation problem: the amount of
      work done by try_fill_recv is not bounded by the budget parameter, thus
      (with large queues) once in a while userspace gets blocked for a long
      time while queue is being refilled. Trigger refills earlier to make sure
      the amount of work to do is limited.
      Signed-off-by: Njiangkidd <jiangkidd@hotmail.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      718be6ba
    • T
      vhost/test: fix build for vhost test · 264b563b
      Tiwei Bie 提交于
      Since vhost_exceeds_weight() was introduced, callers need to specify
      the packet weight and byte weight in vhost_dev_init(). Note that, the
      packet weight isn't counted in this patch to keep the original behavior
      unchanged.
      
      Fixes: e82b9b07 ("vhost: introduce vhost_exceeds_weight()")
      Cc: stable@vger.kernel.org
      Signed-off-by: NTiwei Bie <tiwei.bie@intel.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      264b563b
    • T
      vhost/test: fix build for vhost test · 93d2c4de
      Tiwei Bie 提交于
      Since below commit, callers need to specify the iov_limit in
      vhost_dev_init() explicitly.
      
      Fixes: b46a0bf7 ("vhost: fix OOB in get_rx_bufs()")
      Cc: stable@vger.kernel.org
      Signed-off-by: NTiwei Bie <tiwei.bie@intel.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      93d2c4de
    • H
      ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre · 2a36c16e
      Hui Wang 提交于
      This ThinkCentre machine has a new realtek codec alc222, it is not
      in the support list, we add it in the realtek.c then this machine
      can apply FIXUPs for the realtek codec.
      
      And this machine has two front mics which can't be handled
      by PA so far, it uses the pin 0x18 and 0x19 as the front mics, as
      a result the existing FIXUP ALC294_FIXUP_LENOVO_MIC_LOCATION doesn't
      work on this machine. Fortunately another FIXUP
      ALC283_FIXUP_HEADSET_MIC also can change the location for one of the
      two mics on this machine.
      
      Link: https://lore.kernel.org/r/20190904055327.9883-1-hui.wang@canonical.comSigned-off-by: NHui Wang <hui.wang@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2a36c16e
  5. 03 9月, 2019 10 次提交
  6. 02 9月, 2019 4 次提交