1. 13 12月, 2015 21 次提交
    • L
      Merge branch 'akpm' (patches from Andrew) · 800f1ac4
      Linus Torvalds 提交于
      Merge misc fixes from Andrew Morton:
       "17 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        MIPS: fix DMA contiguous allocation
        sh64: fix __NR_fgetxattr
        ocfs2: fix SGID not inherited issue
        mm/oom_kill.c: avoid attempting to kill init sharing same memory
        drivers/base/memory.c: prohibit offlining of memory blocks with missing sections
        tmpfs: fix shmem_evict_inode() warnings on i_blocks
        mm/hugetlb.c: fix resv map memory leak for placeholder entries
        mm: hugetlb: call huge_pte_alloc() only if ptep is null
        kernel: remove stop_machine() Kconfig dependency
        mm: kmemleak: mark kmemleak_init prototype as __init
        mm: fix kerneldoc on mem_cgroup_replace_page
        osd fs: __r4w_get_page rely on PageUptodate for uptodate
        MAINTAINERS: make Vladimir co-maintainer of the memory controller
        mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress
        mm: fix swapped Movable and Reclaimable in /proc/pagetypeinfo
        memcg: fix memory.high target
        mm: hugetlb: fix hugepage memory leak caused by wrong reserve count
      800f1ac4
    • L
      Merge branch 'parisc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · a971526e
      Linus Torvalds 提交于
      Pull parisc fixes from Helge Deller:
       "Fix the boot crash on Mako machines with Huge Pages, prevent a panic
        with SATA controllers (and others) by correctly calculating the IOMMU
        space, hook up the mlock2 syscall and drop unneeded code in the parisc
        pci code"
      
      * 'parisc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Disable huge pages on Mako machines
        parisc: Wire up mlock2 syscall
        parisc: Remove unused pcibios_init_bus()
        parisc iommu: fix panic due to trying to allocate too large region
      a971526e
    • L
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 78075631
      Linus Torvalds 提交于
      Pull block layer fixes from Jens Axboe:
       "A set of fixes for the current series.  This contains:
      
         - A bunch of fixes for lightnvm, should be the last round for this
           series.  From Matias and Wenwei.
      
         - A writeback detach inode fix from Ilya, also marked for stable.
      
         - A block (though it says SCSI) fix for an OOPS in SCSI runtime power
           management.
      
         - Module init error path fixes for null_blk from Minfei"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        null_blk: Fix error path in module initialization
        lightnvm: do not compile in debugging by default
        lightnvm: prevent gennvm module unload on use
        lightnvm: fix media mgr registration
        lightnvm: replace req queue with nvmdev for lld
        lightnvm: comments on constants
        lightnvm: check mm before use
        lightnvm: refactor spin_unlock in gennvm_get_blk
        lightnvm: put blks when luns configure failed
        lightnvm: use flags in rrpc_get_blk
        block: detach bdev inode from its wb in __blkdev_put()
        SCSI: Fix NULL pointer dereference in runtime PM
      78075631
    • L
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · 6539756e
      Linus Torvalds 提交于
      Pull arm64 fixes from Catalin Marinas:
      
       - Update the linker script to use L1_CACHE_BYTES instead of hard-coded
         64.  We recently changed L1_CACHE_BYTES to 128
      
       - Improve race condition reporting on set_pte_at() and change the BUG
         to WARN_ONCE.  With hardware update of the accessed/dirty state, we
         need to ensure that set_pte_at() does not inadvertently override
         hardware updated state.  The patch also makes the checks ignore
         !pte_valid() new entries
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        arm64: Improve error reporting on set_pte_at() checks
        arm64: update linker script to increased L1_CACHE_BYTES value
      6539756e
    • Q
      MIPS: fix DMA contiguous allocation · 9530d0fe
      Qais Yousef 提交于
      Recent changes to how GFP_ATOMIC is defined seems to have broken the
      condition to use mips_alloc_from_contiguous() in
      mips_dma_alloc_coherent().
      
      I couldn't bottom out the exact change but I think it's this commit
      d0164adc ("mm, page_alloc: distinguish between being unable to
      sleep, unwilling to sleep and avoiding waking kswapd").
      
      GFP_ATOMIC has multiple bits set and the check for !(gfp & GFP_ATOMIC)
      isn't enough.
      
      The reason behind this condition is to check whether we can potentially
      do a sleeping memory allocation.  Use gfpflags_allow_blocking() instead
      which should be more robust.
      Signed-off-by: NQais Yousef <qais.yousef@imgtec.com>
      Acked-by: NMel Gorman <mgorman@techsingularity.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9530d0fe
    • D
      sh64: fix __NR_fgetxattr · 2d33fa10
      Dmitry V. Levin 提交于
      According to arch/sh/kernel/syscalls_64.S and common sense, __NR_fgetxattr
      has to be defined to 259, but it doesn't.  Instead, it's defined to 269,
      which is of course used by another syscall, __NR_sched_setaffinity in this
      case.
      
      This bug was found by strace test suite.
      Signed-off-by: NDmitry V. Levin <ldv@altlinux.org>
      Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2d33fa10
    • J
      ocfs2: fix SGID not inherited issue · 854ee2e9
      Junxiao Bi 提交于
      Commit 8f1eb487 ("ocfs2: fix umask ignored issue") introduced an
      issue, SGID of sub dir was not inherited from its parents dir.  It is
      because SGID is set into "inode->i_mode" in ocfs2_get_init_inode(), but
      is overwritten by "mode" which don't have SGID set later.
      
      Fixes: 8f1eb487 ("ocfs2: fix umask ignored issue")
      Signed-off-by: NJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Acked-by: NSrinivas Eeda <srinivas.eeda@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      854ee2e9
    • C
      mm/oom_kill.c: avoid attempting to kill init sharing same memory · a2b829d9
      Chen Jie 提交于
      It's possible that an oom killed victim shares an ->mm with the init
      process and thus oom_kill_process() would end up trying to kill init as
      well.
      
      This has been shown in practice:
      
      	Out of memory: Kill process 9134 (init) score 3 or sacrifice child
      	Killed process 9134 (init) total-vm:1868kB, anon-rss:84kB, file-rss:572kB
      	Kill process 1 (init) sharing same memory
      	...
      	Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
      
      And this will result in a kernel panic.
      
      If a process is forked by init and selected for oom kill while still
      sharing init_mm, then it's likely this system is in a recoverable state.
      However, it's better not to try to kill init and allow the machine to
      panic due to unkillable processes.
      
      [rientjes@google.com: rewrote changelog]
      [akpm@linux-foundation.org: fix inverted test, per Ben]
      Signed-off-by: NChen Jie <chenjie6@huawei.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NHillf Danton <hillf.zj@alibaba-inc.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Li Zefan <lizefan@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a2b829d9
    • S
      drivers/base/memory.c: prohibit offlining of memory blocks with missing sections · 26bbe7ef
      Seth Jennings 提交于
      Commit bdee237c ("x86: mm: Use 2GB memory block size on large-memory
      x86-64 systems") and 982792c7 ("x86, mm: probe memory block size for
      generic x86 64bit") introduced large block sizes for x86.  This made it
      possible to have multiple sections per memory block where previously,
      there was a only every one section per block.
      
      Since blocks consist of contiguous ranges of section, there can be holes
      in the blocks where sections are not present.  If one attempts to
      offline such a block, a crash occurs since the code is not designed to
      deal with this.
      
      This patch is a quick fix to gaurd against the crash by not allowing
      blocks with non-present sections to be offlined.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=107781Signed-off-by: NSeth Jennings <sjennings@variantweb.net>
      Reported-by: NAndrew Banman <abanman@sgi.com>
      Cc: Daniel J Blueman <daniel@numascale.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Russ Anderson <rja@sgi.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26bbe7ef
    • H
      tmpfs: fix shmem_evict_inode() warnings on i_blocks · 267a4c76
      Hugh Dickins 提交于
      Dmitry Vyukov provides a little program, autogenerated by syzkaller,
      which races a fault on a mapping of a sparse memfd object, against
      truncation of that object below the fault address: run repeatedly for a
      few minutes, it reliably generates shmem_evict_inode()'s
      WARN_ON(inode->i_blocks).
      
      (But there's nothing specific to memfd here, nor to the fstat which it
      happened to use to generate the fault: though that looked suspicious,
      since a shmem_recalc_inode() had been added there recently.  The same
      problem can be reproduced with open+unlink in place of memfd_create, and
      with fstatfs in place of fstat.)
      
      v3.7 commit 0f3c42f5 ("tmpfs: change final i_blocks BUG to WARNING")
      explains one cause of such a warning (a race with shmem_writepage to
      swap), and possible solutions; but we never took it further, and this
      syzkaller incident turns out to have a different cause.
      
      shmem_getpage_gfp()'s error recovery, when a freshly allocated page is
      then found to be beyond eof, looks plausible - decrementing the alloced
      count that was just before incremented - but in fact can go wrong, if a
      racing thread (the truncator, for example) gets its shmem_recalc_inode()
      in just after our delete_from_page_cache().  delete_from_page_cache()
      decrements nrpages, that shmem_recalc_inode() will balance the books by
      decrementing alloced itself, then our decrement of alloced take it one
      too low: leading to the WARNING when the object is finally evicted.
      
      Once the new page has been exposed in the page cache,
      shmem_getpage_gfp() must leave it to shmem_recalc_inode() itself to get
      the accounting right in all cases (and not fall through from "trunc:" to
      "decused:").  Adjust that error recovery block; and the reinitialization
      of info and sbinfo can be removed too.
      
      While we're here, fix shmem_writepage() to avoid the original issue: it
      will be safe against a racing shmem_recalc_inode(), if it merely
      increments swapped before the shmem_delete_from_page_cache() which
      decrements nrpages (but it must then do its own shmem_recalc_inode()
      before that, while still in balance, instead of after).  (Aside: why do
      we shmem_recalc_inode() here in the swap path? Because its raison d'etre
      is to cope with clean sparse shmem pages being reclaimed behind our
      back: so here when swapping is a good place to look for that case.) But
      I've not now managed to reproduce this bug, even without the patch.
      
      I don't see why I didn't do that earlier: perhaps inhibited by the
      preference to eliminate shmem_recalc_inode() altogether.  Driven by this
      incident, I do now have a patch to do so at last; but still want to sit
      on it for a bit, there's a couple of questions yet to be resolved.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      267a4c76
    • M
      mm/hugetlb.c: fix resv map memory leak for placeholder entries · dbe409e4
      Mike Kravetz 提交于
      Dmitry Vyukov reported the following memory leak
      
      unreferenced object 0xffff88002eaafd88 (size 32):
        comm "a.out", pid 5063, jiffies 4295774645 (age 15.810s)
        hex dump (first 32 bytes):
          28 e9 4e 63 00 88 ff ff 28 e9 4e 63 00 88 ff ff  (.Nc....(.Nc....
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
           kmalloc include/linux/slab.h:458
           region_chg+0x2d4/0x6b0 mm/hugetlb.c:398
           __vma_reservation_common+0x2c3/0x390 mm/hugetlb.c:1791
           vma_needs_reservation mm/hugetlb.c:1813
           alloc_huge_page+0x19e/0xc70 mm/hugetlb.c:1845
           hugetlb_no_page mm/hugetlb.c:3543
           hugetlb_fault+0x7a1/0x1250 mm/hugetlb.c:3717
           follow_hugetlb_page+0x339/0xc70 mm/hugetlb.c:3880
           __get_user_pages+0x542/0xf30 mm/gup.c:497
           populate_vma_page_range+0xde/0x110 mm/gup.c:919
           __mm_populate+0x1c7/0x310 mm/gup.c:969
           do_mlock+0x291/0x360 mm/mlock.c:637
           SYSC_mlock2 mm/mlock.c:658
           SyS_mlock2+0x4b/0x70 mm/mlock.c:648
      
      Dmitry identified a potential memory leak in the routine region_chg,
      where a region descriptor is not free'ed on an error path.
      
      However, the root cause for the above memory leak resides in region_del.
      In this specific case, a "placeholder" entry is created in region_chg.
      The associated page allocation fails, and the placeholder entry is left
      in the reserve map.  This is "by design" as the entry should be deleted
      when the map is released.  The bug is in the region_del routine which is
      used to delete entries within a specific range (and when the map is
      released).  region_del did not handle the case where a placeholder entry
      exactly matched the start of the range range to be deleted.  In this
      case, the entry would not be deleted and leaked.  The fix is to take
      these special placeholder entries into account in region_del.
      
      The region_chg error path leak is also fixed.
      
      Fixes: feba16e2 ("mm/hugetlb: add region_del() to delete a specific range of entries")
      Signed-off-by: NMike Kravetz <mike.kravetz@oracle.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Acked-by: NHillf Danton <hillf.zj@alibaba-inc.com>
      Cc: <stable@vger.kernel.org>	[4.3+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dbe409e4
    • N
      mm: hugetlb: call huge_pte_alloc() only if ptep is null · 0d777df5
      Naoya Horiguchi 提交于
      Currently at the beginning of hugetlb_fault(), we call huge_pte_offset()
      and check whether the obtained *ptep is a migration/hwpoison entry or
      not.  And if not, then we get to call huge_pte_alloc().  This is racy
      because the *ptep could turn into migration/hwpoison entry after the
      huge_pte_offset() check.  This race results in BUG_ON in
      huge_pte_alloc().
      
      We don't have to call huge_pte_alloc() when the huge_pte_offset()
      returns non-NULL, so let's fix this bug with moving the code into else
      block.
      
      Note that the *ptep could turn into a migration/hwpoison entry after
      this block, but that's not a problem because we have another
      !pte_present check later (we never go into hugetlb_no_page() in that
      case.)
      
      Fixes: 290408d4 ("hugetlb: hugepage migration core")
      Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: NHillf Danton <hillf.zj@alibaba-inc.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: <stable@vger.kernel.org>	[2.6.36+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0d777df5
    • C
      kernel: remove stop_machine() Kconfig dependency · 86fffe4a
      Chris Wilson 提交于
      Currently the full stop_machine() routine is only enabled on SMP if
      module unloading is enabled, or if the CPUs are hotpluggable.  This
      leads to configurations where stop_machine() is broken as it will then
      only run the callback on the local CPU with irqs disabled, and not stop
      the other CPUs or run the callback on them.
      
      For example, this breaks MTRR setup on x86 in certain configs since
      ea8596bb ("kprobes/x86: Remove unused text_poke_smp() and
      text_poke_smp_batch() functions") as the MTRR is only established on the
      boot CPU.
      
      This patch removes the Kconfig option for STOP_MACHINE and uses the SMP
      and HOTPLUG_CPU config options to compile the correct stop_machine() for
      the architecture, removing the false dependency on MODULE_UNLOAD in the
      process.
      
      Link: https://lkml.org/lkml/2014/10/8/124
      References: https://bugs.freedesktop.org/show_bug.cgi?id=84794Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Pranith Kumar <bobby.prani@gmail.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vladimir Davydov <vdavydov@parallels.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Iulia Manda <iulia.manda21@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Chuck Ebbert <cebbert.lkml@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      86fffe4a
    • N
      mm: kmemleak: mark kmemleak_init prototype as __init · 98e89cf0
      Nicolas Iooss 提交于
      The kmemleak_init() definition in mm/kmemleak.c is marked __init but its
      prototype in include/linux/kmemleak.h is marked __ref since commit
      a6186d89 ("kmemleak: Mark the early log buffer as __initdata").
      
      This causes a section mismatch which is reported as a warning when
      building with clang -Wsection, because kmemleak_init() is declared in
      section .ref.text but defined in .init.text.
      
      Fix this by marking kmemleak_init() prototype __init.
      Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      98e89cf0
    • H
      mm: fix kerneldoc on mem_cgroup_replace_page · 25be6a65
      Hugh Dickins 提交于
      Whoops, I missed removing the kerneldoc comment of the lrucare arg
      removed from mem_cgroup_replace_page; but it's a good comment, keep it.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      25be6a65
    • H
      osd fs: __r4w_get_page rely on PageUptodate for uptodate · 3066a967
      Hugh Dickins 提交于
      Commit 42cb14b1 ("mm: migrate dirty page without
      clear_page_dirty_for_io etc") simplified the migration of a PageDirty
      pagecache page: one stat needs moving from zone to zone and that's about
      all.
      
      It's convenient and safest for it to shift the PageDirty bit from old
      page to new, just before updating the zone stats: before copying data
      and marking the new PageUptodate.  This is all done while both pages are
      isolated and locked, just as before; and just as before, there's a
      moment when the new page is visible in the radix_tree, but not yet
      PageUptodate.  What's new is that it may now be briefly visible as
      PageDirty before it is PageUptodate.
      
      When I scoured the tree to see if this could cause a problem anywhere,
      the only places I found were in two similar functions __r4w_get_page():
      which look up a page with find_get_page() (not using page lock), then
      claim it's uptodate if it's PageDirty or PageWriteback or PageUptodate.
      
      I'm not sure whether that was right before, but now it might be wrong
      (on rare occasions): only claim the page is uptodate if PageUptodate.
      Or perhaps the page in question could never be migratable anyway?
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Tested-by: NBoaz Harrosh <ooo@electrozaur.com>
      Cc: Benny Halevy <bhalevy@panasas.com>
      Cc: Trond Myklebust <trond.myklebust@primarydata.com>
      Cc: Christoph Lameter <cl@linux.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3066a967
    • J
      MAINTAINERS: make Vladimir co-maintainer of the memory controller · ed0f1e21
      Johannes Weiner 提交于
      Vladimir architected and authored much of the current state of the
      memcg's slab memory accounting and tracking.  Make sure he gets CC'd on
      bug reports ;-)
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NVladimir Davydov <vdavydov@virtuozzo.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ed0f1e21
    • M
      mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress · 373ccbe5
      Michal Hocko 提交于
      Tetsuo Handa has reported that the system might basically livelock in
      OOM condition without triggering the OOM killer.
      
      The issue is caused by internal dependency of the direct reclaim on
      vmstat counter updates (via zone_reclaimable) which are performed from
      the workqueue context.  If all the current workers get assigned to an
      allocation request, though, they will be looping inside the allocator
      trying to reclaim memory but zone_reclaimable can see stalled numbers so
      it will consider a zone reclaimable even though it has been scanned way
      too much.  WQ concurrency logic will not consider this situation as a
      congested workqueue because it relies that worker would have to sleep in
      such a situation.  This also means that it doesn't try to spawn new
      workers or invoke the rescuer thread if the one is assigned to the
      queue.
      
      In order to fix this issue we need to do two things.  First we have to
      let wq concurrency code know that we are in trouble so we have to do a
      short sleep.  In order to prevent from issues handled by 0e093d99
      ("writeback: do not sleep on the congestion queue if there are no
      congested BDIs or if significant congestion is not being encountered in
      the current zone") we limit the sleep only to worker threads which are
      the ones of the interest anyway.
      
      The second thing to do is to create a dedicated workqueue for vmstat and
      mark it WQ_MEM_RECLAIM to note it participates in the reclaim and to
      have a spare worker thread for it.
      Signed-off-by: NMichal Hocko <mhocko@suse.com>
      Reported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Cristopher Lameter <clameter@sgi.com>
      Cc: Joonsoo Kim <js1304@gmail.com>
      Cc: Arkadiusz Miskiewicz <arekm@maven.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      373ccbe5
    • V
      mm: fix swapped Movable and Reclaimable in /proc/pagetypeinfo · 475a2f90
      Vlastimil Babka 提交于
      Commit 016c13da ("mm, page_alloc: use masks and shifts when
      converting GFP flags to migrate types") has swapped MIGRATE_MOVABLE and
      MIGRATE_RECLAIMABLE in the enum definition.  However, migratetype_names
      wasn't updated to reflect that.
      
      As a result, the file /proc/pagetypeinfo shows the counts for Movable as
      Reclaimable and vice versa.
      
      Additionally, commit 0aaa29a5 ("mm, page_alloc: reserve pageblocks
      for high-order atomic allocations on demand") introduced
      MIGRATE_HIGHATOMIC, but did not add a letter to distinguish it into
      show_migration_types(), so it doesn't appear in the listing of free
      areas during page alloc failures or oom kills.
      
      This patch fixes both problems.  The atomic reserves will show with a
      letter 'H' in the free areas listings.
      
      Fixes: 016c13da ("mm, page_alloc: use masks and shifts when converting GFP flags to migrate types")
      Fixes: 0aaa29a5 ("mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand")
      Signed-off-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      475a2f90
    • V
      memcg: fix memory.high target · 9516a18a
      Vladimir Davydov 提交于
      When the memory.high threshold is exceeded, try_charge() schedules a
      task_work to reclaim the excess.  The reclaim target is set to the
      number of pages requested by try_charge().
      
      This is wrong, because try_charge() usually charges more pages than
      requested (batch > nr_pages) in order to refill per cpu stocks.  As a
      result, a process in a cgroup can easily exceed memory.high
      significantly when doing a lot of charges w/o returning to userspace
      (e.g.  reading a file in big chunks).
      
      Fix this issue by assuring that when exceeding memory.high a process
      reclaims as many pages as were actually charged (i.e.  batch).
      Signed-off-by: NVladimir Davydov <vdavydov@virtuozzo.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9516a18a
    • N
      mm: hugetlb: fix hugepage memory leak caused by wrong reserve count · a88c7695
      Naoya Horiguchi 提交于
      When dequeue_huge_page_vma() in alloc_huge_page() fails, we fall back on
      alloc_buddy_huge_page() to directly create a hugepage from the buddy
      allocator.
      
      In that case, however, if alloc_buddy_huge_page() succeeds we don't
      decrement h->resv_huge_pages, which means that successful
      hugetlb_fault() returns without releasing the reserve count.  As a
      result, subsequent hugetlb_fault() might fail despite that there are
      still free hugepages.
      
      This patch simply adds decrementing code on that code path.
      
      I reproduced this problem when testing v4.3 kernel in the following situation:
       - the test machine/VM is a NUMA system,
       - hugepage overcommiting is enabled,
       - most of hugepages are allocated and there's only one free hugepage
         which is on node 0 (for example),
       - another program, which calls set_mempolicy(MPOL_BIND) to bind itself to
         node 1, tries to allocate a hugepage,
       - the allocation should fail but the reserve count is still hold.
      Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: <stable@vger.kernel.org> [3.16+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a88c7695
  2. 12 12月, 2015 7 次提交
    • H
      parisc: Disable huge pages on Mako machines · 78c0cbff
      Helge Deller 提交于
      Mako-based machines (PA8800 and PA8900 CPUs) don't allow aliasing on
      non-equaivalent addresses.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      78c0cbff
    • H
      parisc: Wire up mlock2 syscall · 5c477b45
      Helge Deller 提交于
      Signed-off-by: NHelge Deller <deller@gmx.de>
      5c477b45
    • B
      parisc: Remove unused pcibios_init_bus() · 5f0e9b4c
      Bjorn Helgaas 提交于
      There are no callers of pcibios_init_bus(), so remove it.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      5f0e9b4c
    • M
      parisc iommu: fix panic due to trying to allocate too large region · e46e31a3
      Mikulas Patocka 提交于
      When using the Promise TX2+ SATA controller on PA-RISC, the system often
      crashes with kernel panic, for example just writing data with the dd
      utility will make it crash.
      
      Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources
      
      CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
      Backtrace:
       [<000000004021497c>] show_stack+0x14/0x20
       [<0000000040410bf0>] dump_stack+0x88/0x100
       [<000000004023978c>] panic+0x124/0x360
       [<0000000040452c18>] sba_alloc_range+0x698/0x6a0
       [<0000000040453150>] sba_map_sg+0x260/0x5b8
       [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata]
       [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata]
       [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata]
       [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130
       [<000000004049da34>] scsi_request_fn+0x6e4/0x970
       [<00000000403e95a8>] __blk_run_queue+0x40/0x60
       [<00000000403e9d8c>] blk_run_queue+0x3c/0x68
       [<000000004049a534>] scsi_run_queue+0x2a4/0x360
       [<000000004049be68>] scsi_end_request+0x1a8/0x238
       [<000000004049de84>] scsi_io_completion+0xfc/0x688
       [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0
      
      The cause of the crash is not exhaustion of the IOMMU space, there is
      plenty of free pages. The function sba_alloc_range is called with size
      0x11000, thus the pages_needed variable is 0x11. The function
      sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
      0x10 (because dma_get_seg_boundary(dev) returns 0xffff).
      
      The function sba_search_bitmap attempts to allocate 17 pages that must not
      cross 16-page boundary - it can't satisfy this requirement
      (iommu_is_span_boundary always returns true) and fails even if there are
      many free entries in the IOMMU space.
      
      How did it happen that we try to allocate 17 pages that don't cross
      16-page boundary? The cause is in the function iommu_coalesce_chunks. This
      function tries to coalesce adjacent entries in the scatterlist. The
      function does several checks if it may coalesce one entry with the next,
      one of those checks is this:
      
      	if (startsg->length + dma_len > max_seg_size)
      		break;
      
      When it finishes coalescing adjacent entries, it allocates the mapping:
      
      sg_dma_len(contig_sg) = dma_len;
      dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
      sg_dma_address(contig_sg) =
      	PIDE_FLAG
      	| (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT)
      	| dma_offset;
      
      It is possible that (startsg->length + dma_len > max_seg_size) is false
      (we are just near the 0x10000 max_seg_size boundary), so the funcion
      decides to coalesce this entry with the next entry. When the coalescing
      succeeds, the function performs
      	dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
      And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
      iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
      to allocate 17 pages for a device that must not cross 16-page boundary.
      
      To fix the bug, we must make sure that dma_len after addition of
      dma_offset and alignment doesn't cross the segment boundary. I.e. change
      	if (startsg->length + dma_len > max_seg_size)
      		break;
      to
      	if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size)
      		break;
      
      This patch makes this change (it precalculates max_seg_boundary at the
      beginning of the function iommu_coalesce_chunks). I also added a check
      that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
      not needed for Promise TX2+ SATA, but it may be needed for other devices
      that have dma_get_seg_boundary lower than dma_get_max_seg_size).
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NHelge Deller <deller@gmx.de>
      e46e31a3
    • L
      Merge tag 'dm-4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · b9d85451
      Linus Torvalds 提交于
      Pull device mapper fixes from Mike Snitzer:
       "Five stable fixes:
      
         - Two DM btree bufio buffer leak fixes that resolve reported BUG_ONs
           during DM thinp metadata close's dm_bufio_client_destroy().
      
         - A DM thinp range discard fix to handle discarding a partially
           mapped range.
      
         - A DM thinp metadata snapshot fix to make sure the btree roots saved
           in the metadata snapshot are the most current.
      
         - A DM space map metadata refcounting fix that improves both DM thinp
           and DM cache metadata"
      
      * tag 'dm-4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm btree: fix bufio buffer leaks in dm_btree_del() error path
        dm space map metadata: fix ref counting bug when bootstrapping a new space map
        dm thin metadata: fix bug when taking a metadata snapshot
        dm thin metadata: fix bug in dm_thin_remove_range()
        dm btree: fix leak of bufio-backed block in btree_split_sibling error path
      b9d85451
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse · 732c4a9e
      Linus Torvalds 提交于
      Pull fuse fixes from Miklos Szeredi:
       "Two bugfixes, both bound for -stable"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
        fuse: break infinite loop in fuse_fill_write_pages()
        cuse: fix memory leak
      732c4a9e
    • L
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 4be460d9
      Linus Torvalds 提交于
      Pull drm fixes from Dave Airlie:
       "Not too much this time.
      
         - One nouveau workaround extended to a few more GPUs
         - Some amdgpu big endian fixes, and a regression fixer
         - Some vmwgfx fixes
         - One ttm locking fix
         - One vgaarb fix"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        vgaarb: fix signal handling in vga_get()
        radeon: Fix VCE IB test on Big-Endian systems
        radeon: Fix VCE ring test for Big-Endian systems
        radeon/cik: Fix GFX IB test on Big-Endian
        drm/amdgpu: fix the lost duplicates checking
        drm/nouveau/pmu: remove whitelist for PGOB-exit WAR, enable by default
        drm/vmwgfx: Implement the cursor_set2 callback v2
        drm/vmwgfx: fix a warning message
        drm/ttm: Fixed a read/write lock imbalance
      4be460d9
  3. 11 12月, 2015 5 次提交
    • C
      arm64: Improve error reporting on set_pte_at() checks · 82d34008
      Catalin Marinas 提交于
      Currently the BUG_ON() checks do not give enough information about the
      PTEs being set. This patch changes BUG_ON to WARN_ONCE and dumps the
      values of the old and new PTEs. In addition, the checks are only made if
      the new PTE entry is valid.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: NMing Lei <tom.leiming@gmail.com>
      Cc: Will Deacon <will.deacon@arm.com>
      82d34008
    • K
      vgaarb: fix signal handling in vga_get() · 9f5bd308
      Kirill A. Shutemov 提交于
      There are few defects in vga_get() related to signal hadning:
      
        - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
          case;
      
        - if we found pending signal we must remove ourself from wait queue
          and change task state back to running;
      
        - -ERESTARTSYS is more appropriate, I guess.
      Signed-off-by: NKirill A. Shutemov <kirill@shutemov.name>
      Cc: stable@vger.kernel.org
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9f5bd308
    • D
      Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · 49307da3
      Dave Airlie 提交于
      some big endian fixes and one regression fix.
      
      * 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux:
        radeon: Fix VCE IB test on Big-Endian systems
        radeon: Fix VCE ring test for Big-Endian systems
        radeon/cik: Fix GFX IB test on Big-Endian
        drm/amdgpu: fix the lost duplicates checking
      49307da3
    • L
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma · 0bd0f1e6
      Linus Torvalds 提交于
      Pull rdma fixes from Doug Ledford:
       "Most are minor to important fixes.
      
        There is one performance enhancement that I took on the grounds that
        failing to check if other processes can run before running what's
        intended to be a background, idle-time task is a bug, even though the
        primary effect of the fix is to improve performance (and it was a very
        simple patch)"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
        IB/mlx5: Postpone remove_keys under knowledge of coming preemption
        IB/mlx4: Use vmalloc for WR buffers when needed
        IB/mlx4: Use correct order of variables in log message
        iser-target: Remove explicit mlx4 work-around
        mlx4: Expose correct max_sge_rd limit
        IB/mad: Require CM send method for everything except ClassPortInfo
        IB/cma: Add a missing rcu_read_unlock()
        IB core: Fix ib_sg_to_pages()
        IB/srp: Fix srp_map_sg_fr()
        IB/srp: Fix indirect data buffer rkey endianness
        IB/srp: Initialize dma_length in srp_map_idb
        IB/srp: Fix possible send queue overflow
        IB/srp: Fix a memory leak
        IB/sa: Put netlink request into the request list before sending
        IB/iser: use sector_div instead of do_div
        IB/core: use RCU for uverbs id lookup
        IB/qib: Minor fixes to qib per SFF 8636
        IB/core: Fix user mode post wr corruption
        IB/qib: Fix qib_mr structure
      0bd0f1e6
    • L
      Merge tag 'sound-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · a80c47da
      Linus Torvalds 提交于
      Pull sound fixes from Takashi Iwai:
       "Again less intensive changes in this rc: you can find only a few
        HD-audio fixes (noise fixes for Intel Broxton chip and a few Thinkpad
        models, quirks for Alienware 17 and Packard Bell DOTS) in addition to
        a long-standing rme96 bug fix"
      
      * tag 'sound-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: hda/ca0132 - quirk for Alienware 17 2015
        ALSA: hda - Fix noise problems on Thinkpad T440s
        ALSA: hda - Fixing speaker noise on the two latest thinkpad models
        ALSA: hda - Add inverted dmic for Packard Bell DOTS
        ALSA: hda - Fix playback noise with 24/32 bit sample size on BXT
        ALSA: rme96: Fix unexpected volume reset after rate changes
      a80c47da
  4. 10 12月, 2015 7 次提交
    • J
      dm btree: fix bufio buffer leaks in dm_btree_del() error path · ed8b45a3
      Joe Thornber 提交于
      If dm_btree_del()'s call to push_frame() fails, e.g. due to
      btree_node_validator finding invalid metadata, the dm_btree_del() error
      path must unlock all frames (which have active dm-bufio buffers) that
      were pushed onto the del_stack.
      
      Otherwise, dm_bufio_client_destroy() will BUG_ON() because dm-bufio
      buffers have leaked, e.g.:
        device-mapper: bufio: leaked buffer 3, hold count 1, list 0
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      ed8b45a3
    • L
      Merge tag 'vfio-v4.4-rc5' of git://github.com/awilliam/linux-vfio · 6764e5eb
      Linus Torvalds 提交于
      Pull VFIO fixes from Alex Williamson:
      
       - Various fixes for removing redundancy, const'ifying structs, avoiding
         stack usage, fixing WARN usage (Krzysztof Kozlowski, Julia Lawall,
         Kees Cook, Dan Carpenter)
      
       - Revert No-IOMMU mode as the intended user has not emerged (Alex
         Williamson)
      
      * tag 'vfio-v4.4-rc5' of git://github.com/awilliam/linux-vfio:
        Revert: "vfio: Include No-IOMMU mode"
        vfio: fix a warning message
        vfio: platform: remove needless stack usage
        vfio-pci: constify pci_error_handlers structures
        vfio: Drop owner assignment from platform_driver
      6764e5eb
    • L
      Merge tag 'devicetree-fixes-for-4.4-rc4' of... · eef121f4
      Linus Torvalds 提交于
      Merge tag 'devicetree-fixes-for-4.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
      
      Pull DT fixes from Rob Herring:
       "I think this should be all for 4.4:
      
         - Fix incorrect warning about overlapping memory regions
      
         - Export of_irq_find_parent again which was made static in 4.4, but
           has users pending for 4.5.
      
         - Fix of_msi_map_rid declaration location
      
         - Fix re-entrancy for of_fdt_unflatten_tree
      
         - Clean-up of phys_addr_t printks"
      
      * tag 'devicetree-fixes-for-4.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
        of/irq: move of_msi_map_rid declaration to the correct ifdef section
        of/irq: Export of_irq_find_parent again
        of/fdt: Add mutex protection for calls to __unflatten_device_tree()
        of/address: fix typo in comment block of of_translate_one()
        of: do not use 0x in front of %pa
        of: Fix comparison of reserved memory regions
      eef121f4
    • L
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · abb7e2b3
      Linus Torvalds 提交于
      Pull clk fixes from Stephen Boyd:
       "One small build fix, a couple do_div() fixes, and a fix for the gpio
        basic clock type are the major changes here.  There's also a couple
        fixes for the TI, sunxi, and scpi clock drivers"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: sunxi: pll2: Fix clock running too fast
        clk: scpi: add missing of_node_put
        clk: qoriq: fix memory leak
        imx/clk-pllv2: fix wrong do_div() usage
        imx/clk-pllv1: fix wrong do_div() usage
        clk: mmp: add linux/clk.h includes
        clk: ti: drop locking code from mux/divider drivers
        clk: ti816x: Add missing dmtimer clkdev entries
        clk: ti: fapll: fix wrong do_div() usage
        clk: ti: clkt_dpll: fix wrong do_div() usage
        clk: gpio: Get parent clk names in of_gpio_clk_setup()
      abb7e2b3
    • L
      Merge tag 'for-linus-4.4-1' of git://git.code.sf.net/p/openipmi/linux-ipmi · 9a0f76fd
      Linus Torvalds 提交于
      Pull IPMI fix from Corey Minyard:
       "Fix an Oops if an interrupt occurs at startup.  This can happen on
        some hardware"
      
      * tag 'for-linus-4.4-1' of git://git.code.sf.net/p/openipmi/linux-ipmi:
        ipmi: move timer init to before irq is setup
      9a0f76fd
    • J
      ipmi: move timer init to before irq is setup · 27f972d3
      Jan Stancek 提交于
      We encountered a panic on boot in ipmi_si on a dell per320 due to an
      uninitialized timer as follows.
      
      static int smi_start_processing(void       *send_info,
                                      ipmi_smi_t intf)
      {
              /* Try to claim any interrupts. */
              if (new_smi->irq_setup)
                      new_smi->irq_setup(new_smi);
      
       --> IRQ arrives here and irq handler tries to modify uninitialized timer
      
          which triggers BUG_ON(!timer->function) in __mod_timer().
      
       Call Trace:
         <IRQ>
         [<ffffffffa0532617>] start_new_msg+0x47/0x80 [ipmi_si]
         [<ffffffffa053269e>] start_check_enables+0x4e/0x60 [ipmi_si]
         [<ffffffffa0532bd8>] smi_event_handler+0x1e8/0x640 [ipmi_si]
         [<ffffffff810f5584>] ? __rcu_process_callbacks+0x54/0x350
         [<ffffffffa053327c>] si_irq_handler+0x3c/0x60 [ipmi_si]
         [<ffffffff810efaf0>] handle_IRQ_event+0x60/0x170
         [<ffffffff810f245e>] handle_edge_irq+0xde/0x180
         [<ffffffff8100fc59>] handle_irq+0x49/0xa0
         [<ffffffff8154643c>] do_IRQ+0x6c/0xf0
         [<ffffffff8100ba53>] ret_from_intr+0x0/0x11
      
              /* Set up the timer that drives the interface. */
              setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);
      
      The following patch fixes the problem.
      
      To: Openipmi-developer@lists.sourceforge.net
      To: Corey Minyard <minyard@acm.org>
      CC: linux-kernel@vger.kernel.org
      Signed-off-by: NJan Stancek <jstancek@redhat.com>
      Signed-off-by: NTony Camuso <tcamuso@redhat.com>
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Cc: stable@vger.kernel.org # Applies cleanly to 3.10-, needs small rework before
      27f972d3
    • S
      bitops.h: correctly handle rol32 with 0 byte shift · d7e35dfa
      Sasha Levin 提交于
      ROL on a 32 bit integer with a shift of 32 or more is undefined and the
      result is arch-dependent. Avoid this by handling the trivial case of
      roling by 0 correctly.
      
      The trivial solution of checking if shift is 0 breaks gcc's detection
      of this code as a ROL instruction, which is unacceptable.
      
      This bug was reported and fixed in GCC
      (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157):
      
      	The standard rotate idiom,
      
      	  (x << n) | (x >> (32 - n))
      
      	is recognized by gcc (for concreteness, I discuss only the case that x
      	is an uint32_t here).
      
      	However, this is portable C only for n in the range 0 < n < 32. For n
      	== 0, we get x >> 32 which gives undefined behaviour according to the
      	C standard (6.5.7, Bitwise shift operators). To portably support n ==
      	0, one has to write the rotate as something like
      
      	  (x << n) | (x >> ((-n) & 31))
      
      	And this is apparently not recognized by gcc.
      
      Note that this is broken on older GCCs and will result in slower ROL.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d7e35dfa