1. 21 2月, 2017 4 次提交
  2. 17 2月, 2017 1 次提交
  3. 16 2月, 2017 1 次提交
  4. 15 2月, 2017 2 次提交
  5. 10 2月, 2017 2 次提交
  6. 09 2月, 2017 1 次提交
  7. 07 2月, 2017 2 次提交
  8. 05 2月, 2017 1 次提交
    • B
      x86/CPU/AMD: Bring back Compute Unit ID · 79a8b9aa
      Borislav Petkov 提交于
      Commit:
      
        a33d3317 ("x86/CPU/AMD: Fix Bulldozer topology")
      
      restored the initial approach we had with the Fam15h topology of
      enumerating CU (Compute Unit) threads as cores. And this is still
      correct - they're beefier than HT threads but still have some
      shared functionality.
      
      Our current approach has a problem with the Mad Max Steam game, for
      example. Yves Dionne reported a certain "choppiness" while playing on
      v4.9.5.
      
      That problem stems most likely from the fact that the CU threads share
      resources within one CU and when we schedule to a thread of a different
      compute unit, this incurs latency due to migrating the working set to a
      different CU through the caches.
      
      When the thread siblings mask mirrors that aspect of the CUs and
      threads, the scheduler pays attention to it and tries to schedule within
      one CU first. Which takes care of the latency, of course.
      Reported-by: NYves Dionne <yves.dionne@gmail.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: <stable@vger.kernel.org> # 4.9
      Cc: Brice Goglin <Brice.Goglin@inria.fr>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yazen Ghannam <yazen.ghannam@amd.com>
      Link: http://lkml.kernel.org/r/20170205105022.8705-1-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      79a8b9aa
  9. 04 2月, 2017 3 次提交
  10. 01 2月, 2017 3 次提交
  11. 31 1月, 2017 1 次提交
  12. 30 1月, 2017 1 次提交
    • B
      x86/microcode: Do not access the initrd after it has been freed · 24c25032
      Borislav Petkov 提交于
      When we look for microcode blobs, we first try builtin and if that
      doesn't succeed, we fallback to the initrd supplied to the kernel.
      
      However, at some point doing boot, that initrd gets jettisoned and we
      shouldn't access it anymore. But we do, as the below KASAN report shows.
      That's because find_microcode_in_initrd() doesn't check whether the
      initrd is still valid or not.
      
      So do that.
      
        ==================================================================
        BUG: KASAN: use-after-free in find_cpio_data
        Read of size 1 by task swapper/1/0
        page:ffffea0000db9d40 count:0 mapcount:0 mapping:          (null) index:0x1
        flags: 0x100000000000000()
        raw: 0100000000000000 0000000000000000 0000000000000001 00000000ffffffff
        raw: dead000000000100 dead000000000200 0000000000000000 0000000000000000
        page dumped because: kasan: bad access detected
        CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W       4.10.0-rc5-debug-00075-g2dbde22 #3
        Hardware name: Dell Inc. XPS 13 9360/0839Y6, BIOS 1.2.3 12/01/2016
        Call Trace:
         dump_stack
         ? _atomic_dec_and_lock
         ? __dump_page
         kasan_report_error
         ? pointer
         ? find_cpio_data
         __asan_report_load1_noabort
         ? find_cpio_data
         find_cpio_data
         ? vsprintf
         ? dump_stack
         ? get_ucode_user
         ? print_usage_bug
         find_microcode_in_initrd
         __load_ucode_intel
         ? collect_cpu_info_early
         ? debug_check_no_locks_freed
         load_ucode_intel_ap
         ? collect_cpu_info
         ? trace_hardirqs_on
         ? flat_send_IPI_mask_allbutself
         load_ucode_ap
         ? get_builtin_firmware
         ? flush_tlb_func
         ? do_raw_spin_trylock
         ? cpumask_weight
         cpu_init
         ? trace_hardirqs_off
         ? play_dead_common
         ? native_play_dead
         ? hlt_play_dead
         ? syscall_init
         ? arch_cpu_idle_dead
         ? do_idle
         start_secondary
         start_cpu
        Memory state around the buggy address:
         ffff880036e74f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
         ffff880036e74f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
        >ffff880036e75000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                           ^
         ffff880036e75080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
         ffff880036e75100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
        ==================================================================
      Reported-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Tested-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170126165833.evjemhbqzaepirxo@pd.tnicSigned-off-by: NIngo Molnar <mingo@kernel.org>
      24c25032
  13. 28 1月, 2017 1 次提交
  14. 27 1月, 2017 1 次提交
  15. 25 1月, 2017 2 次提交
  16. 24 1月, 2017 3 次提交
  17. 23 1月, 2017 3 次提交
  18. 20 1月, 2017 8 次提交