1. 05 11月, 2017 3 次提交
  2. 04 11月, 2017 34 次提交
  3. 03 11月, 2017 3 次提交
    • R
      x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo · 941f5f0f
      Rafael J. Wysocki 提交于
      Commit 890da9cf (Revert "x86: do not use cpufreq_quick_get() for
      /proc/cpuinfo "cpu MHz"") is not sufficient to restore the previous
      behavior of "cpu MHz" in /proc/cpuinfo on x86 due to some changes
      made after the commit it has reverted.
      
      To address this, make the code in question use arch_freq_get_on_cpu()
      which also is used by cpufreq for reporting the current frequency of
      CPUs and since that function doesn't really depend on cpufreq in any
      way, drop the CONFIG_CPU_FREQ dependency for the object file
      containing it.
      
      Also refactor arch_freq_get_on_cpu() somewhat to avoid IPIs and
      return cached values right away if it is called very often over a
      short time (to prevent user space from triggering IPI storms through
      it).
      
      Fixes: 890da9cf (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
      Cc: stable@kernel.org   # 4.13 - together with 890da9cfSigned-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      941f5f0f
    • H
      mm, swap: fix race between swap count continuation operations · 2628bd6f
      Huang Ying 提交于
      One page may store a set of entries of the sis->swap_map
      (swap_info_struct->swap_map) in multiple swap clusters.
      
      If some of the entries has sis->swap_map[offset] > SWAP_MAP_MAX,
      multiple pages will be used to store the set of entries of the
      sis->swap_map.  And the pages are linked with page->lru.  This is called
      swap count continuation.  To access the pages which store the set of
      entries of the sis->swap_map simultaneously, previously, sis->lock is
      used.  But to improve the scalability of __swap_duplicate(), swap
      cluster lock may be used in swap_count_continued() now.  This may race
      with add_swap_count_continuation() which operates on a nearby swap
      cluster, in which the sis->swap_map entries are stored in the same page.
      
      The race can cause wrong swap count in practice, thus cause unfreeable
      swap entries or software lockup, etc.
      
      To fix the race, a new spin lock called cont_lock is added to struct
      swap_info_struct to protect the swap count continuation page list.  This
      is a lock at the swap device level, so the scalability isn't very well.
      But it is still much better than the original sis->lock, because it is
      only acquired/released when swap count continuation is used.  Which is
      considered rare in practice.  If it turns out that the scalability
      becomes an issue for some workloads, we can split the lock into some
      more fine grained locks.
      
      Link: http://lkml.kernel.org/r/20171017081320.28133-1-ying.huang@intel.com
      Fixes: 235b6217 ("mm/swap: add cluster lock")
      Signed-off-by: N"Huang, Ying" <ying.huang@intel.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Shaohua Li <shli@kernel.org>
      Cc: Tim Chen <tim.c.chen@intel.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Aaron Lu <aaron.lu@intel.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: <stable@vger.kernel.org>	[4.11+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2628bd6f
    • Z
      mm/huge_memory.c: deposit page table when copying a PMD migration entry · dd8a67f9
      Zi Yan 提交于
      We need to deposit pre-allocated PTE page table when a PMD migration
      entry is copied in copy_huge_pmd().  Otherwise, we will leak the
      pre-allocated page and cause a NULL pointer dereference later in
      zap_huge_pmd().
      
      The missing counters during PMD migration entry copy process are added
      as well.
      
      The bug report is here: https://lkml.org/lkml/2017/10/29/214
      
      Link: http://lkml.kernel.org/r/20171030144636.4836-1-zi.yan@sent.com
      Fixes: 84c3fc4e ("mm: thp: check pmd migration entry in common path")
      Signed-off-by: NZi Yan <zi.yan@cs.rutgers.edu>
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dd8a67f9