1. 11 Mar, 2016 6 commits
  2. 10 Mar, 2016 16 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · f2c12421
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "A few simple fixes for ARM, x86, PPC and generic code.
      
        The x86 MMU fix is a bit larger because the surrounding code needed a
        cleanup, but nothing worrisome"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: MMU: fix reserved bit check for ept=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0
        KVM: MMU: fix ept=0/pte.u=1/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo
        kvm: cap halt polling at exactly halt_poll_ns
        KVM: s390: correct fprs on SIGP (STOP AND) STORE STATUS
        KVM: VMX: disable PEBS before a guest entry
        KVM: PPC: Book3S HV: Sanitize special-purpose register values on guest exit
      f2c12421
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · c32c2cb2
      Linus Torvalds authored
      Pull arm64 fixes from Will Deacon:
       "I thought we were done for 4.5, but then the 64k-page chaps came
        crawling out of the woodwork.  *sigh*
      
        The vmemmap fix I sent for -rc7 caused a regression with 64k pages and
        sparsemem and at some point during the release cycle the new hugetlb
        code using contiguous ptes started failing the libhugetlbfs tests with
        64k pages enabled.
      
        So here are a couple of patches that fix the vmemmap alignment and
        disable the new hugetlb page sizes whilst a proper fix is being
        developed:
      
         - Temporarily disable huge pages built using contiguous ptes
      
         - Ensure vmemmap region is sufficiently aligned for sparsemem
           sections"
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        arm64: hugetlb: partial revert of 66b3923a
        arm64: account for sparsemem section alignment when choosing vmemmap offset
      c32c2cb2
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 2da33f9f
      Linus Torvalds authored
      Pull s390 fixes from Martin Schwidefsky:
       "Three bug fixes:
         - The fix for the page table corruption (CVE-2016-2143)
         - The diagnose statistics introduced a regression for the dasd diag
           driver
         - Boot crash on systems without the set-program-parameters facility"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390/mm: four page table levels vs. fork
        s390/cpumf: Fix lpp detection
        s390/dasd: fix diag 0x250 inline assembly
      2da33f9f
    • Mauro Carvalho Chehab's avatar
      [media] media-device: map new functions into old types for legacy API · b2cd2744
      Mauro Carvalho Chehab authored
      The legacy media controller userspace API exposes entity types that
      carry both type and function information. The new API replaces the type
      with a function. It preserves backward compatibility by defining legacy
      functions for the existing types and using them in drivers.
      
      This works fine, as long as newer entity functions won't be added.
      
      Unfortunately, some tools, like media-ctl with --print-dot argument
      rely on the now legacy MEDIA_ENT_T_V4L2_SUBDEV and MEDIA_ENT_T_DEVNODE
      numeric ranges to identify what entities will be shown.
      
      Also, if the entity doesn't match those ranges, it will ignore the
      major/minor information on devnodes, and won't be getting the devnode
      name via udev or sysfs.
      
      As we're now adding devices outside the old range, the legacy ioctl
      needs to map the new entity functions into a type at the old range,
      or otherwise we'll have a regression.
      
      Detected on all released media-ctl versions (e. g. versions <= 1.10).
      
      Fix this by deriving the type from the function to emulate the legacy
      API if the function isn't in the legacy functions range.
      Reported-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      b2cd2744
    • Ludovic Desroches's avatar
      dmaengine: at_xdmac: fix residue computation · 25c5e962
      Ludovic Desroches authored
      When computing the residue we need two pieces of information: the current
      descriptor and the remaining data of the current descriptor. To get
      that information, we need to read consecutively two registers but we
      can't do it in an atomic way. For that reason, we have to check manually
      that current descriptor has not changed.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Suggested-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Reported-by: default avatarDavid Engraf <david.engraf@sysgo.com>
      Tested-by: default avatarDavid Engraf <david.engraf@sysgo.com>
      Fixes: e1f7c9ee ("dmaengine: at_xdmac: creation of the atmel
      eXtended DMA Controller driver")
      Cc: stable@vger.kernel.org #4.1 and later
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      25c5e962
    • Paolo Bonzini's avatar
      KVM: MMU: fix reserved bit check for ept=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 · 5f0b8199
      Paolo Bonzini authored
      KVM has special logic to handle pages with pte.u=1 and pte.w=0 when
      CR0.WP=1.  These pages' SPTEs flip continuously between two states:
      U=1/W=0 (user and supervisor reads allowed, supervisor writes not allowed)
      and U=0/W=1 (supervisor reads and writes allowed, user writes not allowed).
      
      When SMEP is in effect, however, U=0 will enable kernel execution of
      this page.  To avoid this, KVM also sets NX=1 in the shadow PTE together
      with U=0, making the two states U=1/W=0/NX=gpte.NX and U=0/W=1/NX=1.
      When guest EFER has the NX bit cleared, the reserved bit check thinks
      that the latter state is invalid; teach it that the smep_andnot_wp case
      will also use the NX bit of SPTEs.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarXiao Guangrong <guangrong.xiao@linux.inel.com>
      Fixes: c258b62bSigned-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5f0b8199
    • Paolo Bonzini's avatar
      KVM: MMU: fix ept=0/pte.u=1/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo · 844a5fe2
      Paolo Bonzini authored
      Yes, all of these are needed. :) This is admittedly a bit odd, but
      kvm-unit-tests access.flat tests this if you run it with "-cpu host"
      and of course ept=0.
      
      KVM runs the guest with CR0.WP=1, so it must handle supervisor writes
      specially when pte.u=1/pte.w=0/CR0.WP=0.  Such writes cause a fault
      when U=1 and W=0 in the SPTE, but they must succeed because CR0.WP=0.
      When KVM gets the fault, it sets U=0 and W=1 in the shadow PTE and
      restarts execution.  This will still cause a user write to fault, while
      supervisor writes will succeed.  User reads will fault spuriously now,
      and KVM will then flip U and W again in the SPTE (U=1, W=0).  User reads
      will be enabled and supervisor writes disabled, going back to the
      originary situation where supervisor writes fault spuriously.
      
      When SMEP is in effect, however, U=0 will enable kernel execution of
      this page.  To avoid this, KVM also sets NX=1 in the shadow PTE together
      with U=0.  If the guest has not enabled NX, the result is a continuous
      stream of page faults due to the NX bit being reserved.
      
      The fix is to force EFER.NX=1 even if the CPU is taking care of the EFER
      switch.  (All machines with SMEP have the CPU_LOAD_IA32_EFER vm-entry
      control, so they do not use user-return notifiers for EFER---if they did,
      EFER.NX would be forced to the same value as the host).
      
      There is another bug in the reserved bit check, which I've split to a
      separate patch for easier application to stable kernels.
      
      Cc: stable@vger.kernel.org
      Cc: Andy Lutomirski <luto@amacapital.net>
      Reviewed-by: default avatarXiao Guangrong <guangrong.xiao@linux.intel.com>
      Fixes: f6577a5fSigned-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      844a5fe2
    • Martin Schwidefsky's avatar
      s390/mm: four page table levels vs. fork · 3446c13b
      Martin Schwidefsky authored
      The fork of a process with four page table levels is broken since
      git commit 6252d702 "[S390] dynamic page tables."
      
      All new mm contexts are created with three page table levels and
      an asce limit of 4TB. If the parent has four levels dup_mmap will
      add vmas to the new context which are outside of the asce limit.
      The subsequent call to copy_page_range will walk the three level
      page table structure of the new process with non-zero pgd and pud
      indexes. This leads to memory clobbers as the pgd_index *and* the
      pud_index is added to the mm->pgd pointer without a pgd_deref
      in between.
      
      The init_new_context() function is selecting the number of page
      table levels for a new context. The function is used by mm_init()
      which in turn is called by dup_mm() and mm_alloc(). These two are
      used by fork() and exec(). The init_new_context() function can
      distinguish the two cases by looking at mm->context.asce_limit,
      for fork() the mm struct has been copied and the number of page
      table levels may not change. For exec() the mm_alloc() function
      set the new mm structure to zero, in this case a three-level page
      table is created as the temporary stack space is located at
      STACK_TOP_MAX = 4TB.
      
      This fixes CVE-2016-2143.
      Reported-by: default avatarMarcin Kościelnicki <koriakin@0x04.net>
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      3446c13b
    • Linus Torvalds's avatar
      Merge tag 'spi-fix-v4.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi · 8e0f93cd
      Linus Torvalds authored
      Pull spi fixes from Mark Brown:
       "A few driver specific fixes for the Rockchip and i.MX SPI controllers,
        especially for the i.MX they're annoying bugs if you run into them"
      
      * tag 'spi-fix-v4.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
        spi: imx: fix spi resource leak with dma transfer
        spi: imx: allow only WML aligned transfers to use DMA
        spi: rockchip: add missing spi_master_put
        spi: rockchip: disable runtime pm when in err case
      8e0f93cd
    • Mark Brown's avatar
    • Mark Brown's avatar
      c23663ac
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 718e47a5
      Linus Torvalds authored
      Pull ext4 fix from Ted Ts'o:
       "This fixes a regression which crept in v4.5-rc5"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: iterate over buffer heads correctly in move_extent_per_page()
      718e47a5
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · a6e434e9
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "A few imx fixes I missed from a couple of weeks ago, they still aren't
        that big and fix some regression and a fail to boot problem.
      
        Other than that, a couple of regression fixes for radeon/amdgpu, one
        regression fix for vmwgfx and one regression fix for tda998x"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        Revert "drm/radeon/pm: adjust display configuration after powerstate"
        drm/amdgpu/dp: add back special handling for NUTMEG
        drm/radeon/dp: add back special handling for NUTMEG
        drm/i2c: tda998x: Choose between atomic or non atomic dpms helper
        drm/vmwgfx: Add back ->detect() and ->fill_modes()
        drm/radeon: Fix error handling in radeon_flip_work_func.
        drm/amdgpu: Fix error handling in amdgpu_flip_work_func.
        drm/imx: Add missing DRM_FORMAT_RGB565 to ipu_plane_formats
        drm/imx: notify DRM core about CRTC vblank state
        gpu: ipu-v3: Reset IPU before activating IRQ
        gpu: ipu-v3: Do not bail out on missing optional port nodes
      a6e434e9
    • Linus Torvalds's avatar
      Merge tag 'trace-fixes-v4.5-rc7' of... · 8205ff1d
      Linus Torvalds authored
      Merge tag 'trace-fixes-v4.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
      
      Pull tracing fix from Steven Rostedt:
       "I previously sent a fix that prevents all trace events from being
        called if the current cpu is offline.
      
        But I forgot that in 3.18, we added lockdep checks to test RCU usage
        even when the event is disabled.  Although there cannot be any bug
        when a cpu is going offline, we now get false warnings triggered by
        the added checks of the event being disabled.
      
        I removed the check from the tracepoint code itself, and added it to
        the condition section (which is "1" for 'no condition').  This way the
        online cpu check will get checked in all the right locations"
      
      * tag 'trace-fixes-v4.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Fix check for cpu online when event is disabled
      8205ff1d
    • Eryu Guan's avatar
      ext4: iterate over buffer heads correctly in move_extent_per_page() · 6ffe77ba
      Eryu Guan authored
      In commit bcff2488 ("ext4: don't read blocks from disk after extents
      being swapped") bh is not updated correctly in the for loop and wrong
      data has been written to disk. generic/324 catches this on sub-page
      block size ext4.
      
      Fixes: bcff2488 ("ext4: don't read blocks from disk after extentsbeing swapped")
      Signed-off-by: default avatarEryu Guan <guaneryu@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      6ffe77ba
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 380173ff
      Linus Torvalds authored
      Merge fixes from Andrew Morton:
       "13 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        dma-mapping: avoid oops when parameter cpu_addr is null
        mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers
        memremap: check pfn validity before passing to pfn_to_page()
        mm, thp: fix migration of PTE-mapped transparent huge pages
        dax: check return value of dax_radix_entry()
        ocfs2: fix return value from ocfs2_page_mkwrite()
        arm64: kasan: clear stale stack poison
        sched/kasan: remove stale KASAN poison after hotplug
        kasan: add functions to clear stack poison
        mm: fix mixed zone detection in devm_memremap_pages
        list: kill list_force_poison()
        mm: __delete_from_page_cache show Bad page if mapped
        mm/hugetlb: hugetlb_no_page: rate-limit warning message
      380173ff
  3. 09 Mar, 2016 18 commits
    • Zhen Lei's avatar
      dma-mapping: avoid oops when parameter cpu_addr is null · d6b7eaeb
      Zhen Lei authored
      To keep consistent with kfree, which tolerate ptr is NULL.  We do this
      because sometimes we may use goto statement, so that success and failure
      case can share parts of the code.  But unfortunately, dma_free_coherent
      called with parameter cpu_addr is null will cause oops, such as showed
      below:
      
        Unable to handle kernel paging request at virtual address ffffffc020d3b2b8
        pgd = ffffffc083a61000
        [ffffffc020d3b2b8] *pgd=0000000000000000, *pud=0000000000000000
        CPU: 4 PID: 1489 Comm: malloc_dma_1 Tainted: G           O    4.1.12 #1
        Hardware name: ARM64 (DT)
        PC is at __dma_free_coherent.isra.10+0x74/0xc8
        LR is at __dma_free+0x9c/0xb0
        Process malloc_dma_1 (pid: 1489, stack limit = 0xffffffc0837fc020)
        [...]
        Call trace:
          __dma_free_coherent.isra.10+0x74/0xc8
          __dma_free+0x9c/0xb0
          malloc_dma+0x104/0x158 [dma_alloc_coherent_mtmalloc]
          kthread+0xec/0xfc
      Signed-off-by: default avatarZhen Lei <thunder.leizhen@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d6b7eaeb
    • Jan Stancek's avatar
      mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers · 86613628
      Jan Stancek authored
      Replace ENOTSUPP with EOPNOTSUPP.  If hugepages are not supported, this
      value is propagated to userspace.  EOPNOTSUPP is part of uapi and is
      widely supported by libc libraries.
      
      It gives nicer message to user, rather than:
      
        # cat /proc/sys/vm/nr_hugepages
        cat: /proc/sys/vm/nr_hugepages: Unknown error 524
      
      And also LTP's proc01 test was failing because this ret code (524)
      was unexpected:
      
        proc01      1  TFAIL  :  proc01.c:396: read failed: /proc/sys/vm/nr_hugepages: errno=???(524): Unknown error 524
        proc01      2  TFAIL  :  proc01.c:396: read failed: /proc/sys/vm/nr_hugepages_mempolicy: errno=???(524): Unknown error 524
        proc01      3  TFAIL  :  proc01.c:396: read failed: /proc/sys/vm/nr_overcommit_hugepages: errno=???(524): Unknown error 524
      Signed-off-by: default avatarJan Stancek <jstancek@redhat.com>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarHillf Danton <hillf.zj@alibaba-inc.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      86613628
    • Ard Biesheuvel's avatar
      memremap: check pfn validity before passing to pfn_to_page() · ac343e88
      Ard Biesheuvel authored
      In memremap's helper function try_ram_remap(), we dereference a struct
      page pointer that was derived from a PFN that is known to be covered by
      a 'System RAM' iomem region, and is thus assumed to be a 'valid' PFN,
      i.e., a PFN that has a struct page associated with it and is covered by
      the kernel direct mapping.
      
      However, the assumption that there is a 1:1 relation between the System
      RAM iomem region and the kernel direct mapping is not universally valid
      on all architectures, and on ARM and arm64, 'System RAM' may include
      regions for which pfn_valid() returns false.
      
      Generally speaking, both __va() and pfn_to_page() should only ever be
      called on PFNs/physical addresses for which pfn_valid() returns true, so
      add that check to try_ram_remap().
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ac343e88
    • Kirill A. Shutemov's avatar
      mm, thp: fix migration of PTE-mapped transparent huge pages · 0a2e280b
      Kirill A. Shutemov authored
      We don't have native support of THP migration, so we have to split huge
      page into small pages in order to migrate it to different node.  This
      includes PTE-mapped huge pages.
      
      I made mistake in refcounting patchset: we don't actually split
      PTE-mapped huge page in queue_pages_pte_range(), if we step on head
      page.
      
      The result is that the head page is queued for migration, but none of
      tail pages: putting head page on queue takes pin on the page and any
      subsequent attempts of split_huge_pages() would fail and we skip queuing
      tail pages.
      
      unmap_and_move_huge_page() will eventually split the huge pages, but
      only one of 512 pages would get migrated.
      
      Let's fix the situation.
      
      Fixes: 248db92d ("migrate_pages: try to split pages on queuing")
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0a2e280b
    • Ross Zwisler's avatar
      dax: check return value of dax_radix_entry() · 30f471fd
      Ross Zwisler authored
      dax_pfn_mkwrite() previously wasn't checking the return value of the
      call to dax_radix_entry(), which was a mistake.
      
      Instead, capture this return value and return the appropriate VM_FAULT_
      value.
      Signed-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      30f471fd
    • Jan Kara's avatar
      ocfs2: fix return value from ocfs2_page_mkwrite() · 566e8dfd
      Jan Kara authored
      ocfs2_page_mkwrite() could mistakenly return error code instead of
      mkwrite status value.  Fix it.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <joseph.qi@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      566e8dfd
    • Mark Rutland's avatar
      arm64: kasan: clear stale stack poison · 0d97e6d8
      Mark Rutland authored
      Functions which the compiler has instrumented for KASAN place poison on
      the stack shadow upon entry and remove this poison prior to returning.
      
      In the case of cpuidle, CPUs exit the kernel a number of levels deep in
      C code.  Any instrumented functions on this critical path will leave
      portions of the stack shadow poisoned.
      
      If CPUs lose context and return to the kernel via a cold path, we
      restore a prior context saved in __cpu_suspend_enter are forgotten, and
      we never remove the poison they placed in the stack shadow area by
      functions calls between this and the actual exit of the kernel.
      
      Thus, (depending on stackframe layout) subsequent calls to instrumented
      functions may hit this stale poison, resulting in (spurious) KASAN
      splats to the console.
      
      To avoid this, clear any stale poison from the idle thread for a CPU
      prior to bringing a CPU online.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reviewed-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0d97e6d8
    • Mark Rutland's avatar
      sched/kasan: remove stale KASAN poison after hotplug · e1b77c92
      Mark Rutland authored
      Functions which the compiler has instrumented for KASAN place poison on
      the stack shadow upon entry and remove this poision prior to returning.
      
      In the case of CPU hotplug, CPUs exit the kernel a number of levels deep
      in C code.  Any instrumented functions on this critical path will leave
      portions of the stack shadow poisoned.
      
      When a CPU is subsequently brought back into the kernel via a different
      path, depending on stackframe, layout calls to instrumented functions
      may hit this stale poison, resulting in (spurious) KASAN splats to the
      console.
      
      To avoid this, clear any stale poison from the idle thread for a CPU
      prior to bringing a CPU online.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e1b77c92
    • Mark Rutland's avatar
      kasan: add functions to clear stack poison · e3ae1163
      Mark Rutland authored
      Functions which the compiler has instrumented for ASAN place poison on
      the stack shadow upon entry and remove this poison prior to returning.
      
      In some cases (e.g. hotplug and idle), CPUs may exit the kernel a
      number of levels deep in C code.  If there are any instrumented
      functions on this critical path, these will leave portions of the idle
      thread stack shadow poisoned.
      
      If a CPU returns to the kernel via a different path (e.g. a cold
      entry), then depending on stack frame layout subsequent calls to
      instrumented functions may use regions of the stack with stale poison,
      resulting in (spurious) KASAN splats to the console.
      
      Contemporary GCCs always add stack shadow poisoning when ASAN is
      enabled, even when asked to not instrument a function [1], so we can't
      simply annotate functions on the critical path to avoid poisoning.
      
      Instead, this series explicitly removes any stale poison before it can
      be hit.  In the common hotplug case we clear the entire stack shadow in
      common code, before a CPU is brought online.
      
      On architectures which perform a cold return as part of cpu idle may
      retain an architecture-specific amount of stack contents.  To retain the
      poison for this retained context, the arch code must call the core KASAN
      code, passing a "watermark" stack pointer value beyond which shadow will
      be cleared.  Architectures which don't perform a cold return as part of
      idle do not need any additional code.
      
      This patch (of 3):
      
      Functions which the compiler has instrumented for KASAN place poison on
      the stack shadow upon entry and remove this poision prior to returning.
      
      In some cases (e.g.  hotplug and idle), CPUs may exit the kernel a number
      of levels deep in C code.  If there are any instrumented functions on this
      critical path, these will leave portions of the stack shadow poisoned.
      
      If a CPU returns to the kernel via a different path (e.g.  a cold entry),
      then depending on stack frame layout subsequent calls to instrumented
      functions may use regions of the stack with stale poison, resulting in
      (spurious) KASAN splats to the console.
      
      To avoid this, we must clear stale poison from the stack prior to
      instrumented functions being called.  This patch adds functions to the
      KASAN core for removing poison from (portions of) a task's stack.  These
      will be used by subsequent patches to avoid problems with hotplug and
      idle.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e3ae1163
    • Dan Williams's avatar
      mm: fix mixed zone detection in devm_memremap_pages · 5f29a77c
      Dan Williams authored
      The check for whether we overlap "System RAM" needs to be done at
      section granularity.  For example a system with the following mapping:
      
          100000000-37bffffff : System RAM
          37c000000-837ffffff : Persistent Memory
      
      ...is unable to use devm_memremap_pages() as it would result in two
      zones colliding within a given section.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Reviewed-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5f29a77c
    • Dan Williams's avatar
      list: kill list_force_poison() · d77a117e
      Dan Williams authored
      Given we have uninitialized list_heads being passed to list_add() it
      will always be the case that those uninitialized values randomly trigger
      the poison value.  Especially since a list_add() operation will seed the
      stack with the poison value for later stack allocations to trip over.
      
      For example, see these two false positive reports:
      
        list_add attempted on force-poisoned entry
        WARNING: at lib/list_debug.c:34
        [..]
        NIP [c00000000043c390] __list_add+0xb0/0x150
        LR [c00000000043c38c] __list_add+0xac/0x150
        Call Trace:
          __list_add+0xac/0x150 (unreliable)
          __down+0x4c/0xf8
          down+0x68/0x70
          xfs_buf_lock+0x4c/0x150 [xfs]
      
        list_add attempted on force-poisoned entry(0000000000000500),
         new->next == d0000000059ecdb0, new->prev == 0000000000000500
        WARNING: at lib/list_debug.c:33
        [..]
        NIP [c00000000042db78] __list_add+0xa8/0x140
        LR [c00000000042db74] __list_add+0xa4/0x140
        Call Trace:
          __list_add+0xa4/0x140 (unreliable)
          rwsem_down_read_failed+0x6c/0x1a0
          down_read+0x58/0x60
          xfs_log_commit_cil+0x7c/0x600 [xfs]
      
      Fixes: commit 5c2c2587 ("mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup")
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Reported-by: default avatarEryu Guan <eguan@redhat.com>
      Tested-by: default avatarEryu Guan <eguan@redhat.com>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d77a117e
    • Hugh Dickins's avatar
      mm: __delete_from_page_cache show Bad page if mapped · 06b241f3
      Hugh Dickins authored
      Commit e1534ae9 ("mm: differentiate page_mapped() from
      page_mapcount() for compound pages") changed the famous
      BUG_ON(page_mapped(page)) in __delete_from_page_cache() to
      VM_BUG_ON_PAGE(page_mapped(page)): which gives us more info when
      CONFIG_DEBUG_VM=y, but nothing at all when not.
      
      Although it has not usually been very helpul, being hit long after the
      error in question, we do need to know if it actually happens on users'
      systems; but reinstating a crash there is likely to be opposed :)
      
      In the non-debug case, pr_alert("BUG: Bad page cache") plus dump_page(),
      dump_stack(), add_taint() - I don't really believe LOCKDEP_NOW_UNRELIABLE,
      but that seems to be the standard procedure now.  Move that, or the
      VM_BUG_ON_PAGE(), up before the deletion from tree: so that the
      unNULLified page->mapping gives a little more information.
      
      If the inode is being evicted (rather than truncated), it won't have any
      vmas left, so it's safe(ish) to assume that the raised mapcount is
      erroneous, and we can discount it from page_count to avoid leaking the
      page (I'm less worried by leaking the occasional 4kB, than losing a
      potential 2MB page with each 4kB page leaked).
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      06b241f3
    • Geoffrey Thomas's avatar
      mm/hugetlb: hugetlb_no_page: rate-limit warning message · 910154d5
      Geoffrey Thomas authored
      The warning message "killed due to inadequate hugepage pool" simply
      indicates that SIGBUS was sent, not that the process was forcibly killed.
      If the process has a signal handler installed does not fix the problem,
      this message can rapidly spam the kernel log.
      
      On my amd64 dev machine that does not have hugepages configured, I can
      reproduce the repeated warnings easily by setting vm.nr_hugepages=2 (i.e.,
      4 megabytes of huge pages) and running something that sets a signal
      handler and forks, like
      
        #include <sys/mman.h>
        #include <signal.h>
        #include <stdlib.h>
        #include <unistd.h>
      
        sig_atomic_t counter = 10;
        void handler(int signal)
        {
            if (counter-- == 0)
               exit(0);
        }
      
        int main(void)
        {
            int status;
            char *addr = mmap(NULL, 4 * 1048576, PROT_READ | PROT_WRITE,
                    MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);
            if (addr == MAP_FAILED) {perror("mmap"); return 1;}
            *addr = 'x';
            switch (fork()) {
               case -1:
                  perror("fork"); return 1;
               case 0:
                  signal(SIGBUS, handler);
                  *addr = 'x';
                  break;
               default:
                  *addr = 'x';
                  wait(&status);
                  if (WIFSIGNALED(status)) {
                     psignal(WTERMSIG(status), "child");
                  }
                  break;
            }
        }
      Signed-off-by: default avatarGeoffrey Thomas <geofft@ldpreload.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      910154d5
    • Linus Torvalds's avatar
      Merge tag 'pci-v4.5-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · 2f0d94ea
      Linus Torvalds authored
      Pull PCI fix from Bjorn Helgaas:
       "Here's another fix for v4.5.  It fixes an ARM regression in v4.0 that
        causes many boxes to crash on boot, including cns3xxx, dove,
        footbridge, iopl13xx, ip32x, iop33x, ixp4xx, ks8695, mv78xx0, orion5x,
        pxa, sa1100, etc.
      
        The change is in code that's only built for ARM and ARM64.
      
        Summary:
      
        Enumeration:
          Allow generic PCI domains without bridge "parent" pointer (Krzysztof Hałasa)"
      
      * tag 'pci-v4.5-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
        PCI: Allow a NULL "parent" pointer in pci_bus_assign_domain_nr()
      2f0d94ea
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix check for cpu online when event is disabled · dc17147d
      Steven Rostedt (Red Hat) authored
      Commit f3775549 ("tracepoints: Do not trace when cpu is offline") added
      a check to make sure that tracepoints only get called when the cpu is
      online, as it uses rcu_read_lock_sched() for protection.
      
      Commit 3a630178 ("tracing: generate RCU warnings even when tracepoints
      are disabled") added lockdep checks (including rcu checks) for events that
      are not enabled to catch possible RCU issues that would only be triggered if
      a trace event was enabled. Commit f3775549 only stopped the warnings
      when the trace event was enabled but did not prevent warnings if the trace
      event was called when disabled.
      
      To fix this, the cpu online check is moved to where the condition is added
      to the trace event. This will place the cpu online check in all places that
      it may be used now and in the future.
      
      Cc: stable@vger.kernel.org # v3.18+
      Fixes: f3775549 ("tracepoints: Do not trace when cpu is offline")
      Fixes: 3a630178 ("tracing: generate RCU warnings even when tracepoints are disabled")
      Reported-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Tested-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      dc17147d
    • Will Deacon's avatar
      arm64: hugetlb: partial revert of 66b3923a · ff792584
      Will Deacon authored
      Commit 66b3923a ("arm64: hugetlb: add support for PTE contiguous bit")
      introduced support for huge pages using the contiguous bit in the PTE
      as opposed to block mappings, which may be slightly unwieldy (512M) in
      64k page configurations.
      
      Unfortunately, this support has resulted in some late regressions when
      running the libhugetlbfs test suite with 64k pages and CONFIG_DEBUG_VM
      as a result of a BUG:
      
       | readback (2M: 64):	------------[ cut here ]------------
       | kernel BUG at fs/hugetlbfs/inode.c:446!
       | Internal error: Oops - BUG: 0 [#1] SMP
       | Modules linked in:
       | CPU: 7 PID: 1448 Comm: readback Not tainted 4.5.0-rc7 #148
       | Hardware name: linux,dummy-virt (DT)
       | task: fffffe0040964b00 ti: fffffe00c2668000 task.ti: fffffe00c2668000
       | PC is at remove_inode_hugepages+0x44c/0x480
       | LR is at remove_inode_hugepages+0x264/0x480
      
      Rather than revert the entire patch, simply avoid advertising the
      contiguous huge page sizes for now while people are actively working on
      a fix. This patch can then be reverted once things have been sorted out.
      
      Cc: David Woods <dwoods@ezchip.com>
      Reported-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ff792584
    • Ard Biesheuvel's avatar
      arm64: account for sparsemem section alignment when choosing vmemmap offset · 36e5cd6b
      Ard Biesheuvel authored
      Commit dfd55ad8 ("arm64: vmemmap: use virtual projection of linear
      region") fixed an issue where the struct page array would overflow into the
      adjacent virtual memory region if system RAM was placed so high up in
      physical memory that its addresses were not representable in the build time
      configured virtual address size.
      
      However, the fix failed to take into account that the vmemmap region needs
      to be relatively aligned with respect to the sparsemem section size, so that
      a sequence of page structs corresponding with a sparsemem section in the
      linear region appears naturally aligned in the vmemmap region.
      
      So round up vmemmap to sparsemem section size. Since this essentially moves
      the projection of the linear region up in memory, also revert the reduction
      of the size of the vmemmap region.
      
      Cc: <stable@vger.kernel.org>
      Fixes: dfd55ad8 ("arm64: vmemmap: use virtual projection of linear region")
      Tested-by: default avatarMark Langsdorf <mlangsdo@redhat.com>
      Tested-by: default avatarDavid Daney <david.daney@cavium.com>
      Tested-by: default avatarRobert Richter <rrichter@cavium.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      36e5cd6b
    • David Matlack's avatar
      kvm: cap halt polling at exactly halt_poll_ns · 313f636d
      David Matlack authored
      When growing halt-polling, there is no check that the poll time exceeds
      the limit. It's possible for vcpu->halt_poll_ns grow once past
      halt_poll_ns, and stay there until a halt which takes longer than
      vcpu->halt_poll_ns. For example, booting a Linux guest with
      halt_poll_ns=11000:
      
       ... kvm:kvm_halt_poll_ns: vcpu 0: halt_poll_ns 0 (shrink 10000)
       ... kvm:kvm_halt_poll_ns: vcpu 0: halt_poll_ns 10000 (grow 0)
       ... kvm:kvm_halt_poll_ns: vcpu 0: halt_poll_ns 20000 (grow 10000)
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      Fixes: aca6ff29
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      313f636d