1. 26 Jul, 2014 13 commits
    • Linus Torvalds's avatar
      Fix gcc-4.9.0 miscompilation of load_balance() in scheduler · 2062afb4
      Linus Torvalds authored
      Michel Dänzer and a couple of other people reported inexplicable random
      oopses in the scheduler, and the cause turns out to be gcc mis-compiling
      the load_balance() function when debugging is enabled.  The gcc bug
      apparently goes back to gcc-4.5, but slight optimization changes means
      that it now showed up as a problem in 4.9.0 and 4.9.1.
      
      The instruction scheduling problem causes gcc to schedule a spill
      operation to before the stack frame has been created, which in turn can
      corrupt the spilled value if an interrupt comes in.  There may be other
      effects of this bug too, but that's the code generation problem seen in
      Michel's case.
      
      This is fixed in current gcc HEAD, but the workaround as suggested by
      Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
      when compiling the kernel, which disables the gcc code that causes the
      problem.  This can result in slightly worse debug information for
      variable accesses, but that is infinitely preferable to actual code
      generation problems.
      
      Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
      non-debug builds to verify that the debug build would be identical: we
      can do
      
          export GCC_COMPARE_DEBUG=1
      
      to make gcc internally verify that the result of the build is
      independent of the "-g" flag (it will make the compiler build everything
      twice, toggling the debug flag, and compare the results).
      
      Without the "-fno-var-tracking-assignments" option, the build would fail
      (even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
      compare failure.
      
      See also gcc bugzilla:
      
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801Reported-by: default avatarMichel Dänzer <michel@daenzer.net>
      Suggested-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2062afb4
    • Hugh Dickins's avatar
      mm: fix direct reclaim writeback regression · 8bdd6380
      Hugh Dickins authored
      Shortly before 3.16-rc1, Dave Jones reported:
      
        WARNING: CPU: 3 PID: 19721 at fs/xfs/xfs_aops.c:971
                 xfs_vm_writepage+0x5ce/0x630 [xfs]()
        CPU: 3 PID: 19721 Comm: trinity-c61 Not tainted 3.15.0+ #3
        Call Trace:
          xfs_vm_writepage+0x5ce/0x630 [xfs]
          shrink_page_list+0x8f9/0xb90
          shrink_inactive_list+0x253/0x510
          shrink_lruvec+0x563/0x6c0
          shrink_zone+0x3b/0x100
          shrink_zones+0x1f1/0x3c0
          try_to_free_pages+0x164/0x380
          __alloc_pages_nodemask+0x822/0xc90
          alloc_pages_vma+0xaf/0x1c0
          handle_mm_fault+0xa31/0xc50
        etc.
      
       970   if (WARN_ON_ONCE((current->flags & (PF_MEMALLOC|PF_KSWAPD)) ==
       971                   PF_MEMALLOC))
      
      I did not respond at the time, because a glance at the PageDirty block
      in shrink_page_list() quickly shows that this is impossible: we don't do
      writeback on file pages (other than tmpfs) from direct reclaim nowadays.
      Dave was hallucinating, but it would have been disrespectful to say so.
      
      However, my own /var/log/messages now shows similar complaints
      
        WARNING: CPU: 1 PID: 28814 at fs/ext4/inode.c:1881 ext4_writepage+0xa7/0x38b()
        WARNING: CPU: 0 PID: 27347 at fs/ext4/inode.c:1764 ext4_writepage+0xa7/0x38b()
      
      from stressing some mmotm trees during July.
      
      Could a dirty xfs or ext4 file page somehow get marked PageSwapBacked,
      so fail shrink_page_list()'s page_is_file_cache() test, and so proceed
      to mapping->a_ops->writepage()?
      
      Yes, 3.16-rc1's commit 68711a74 ("mm, migration: add destination
      page freeing callback") has provided such a way to compaction: if
      migrating a SwapBacked page fails, its newpage may be put back on the
      list for later use with PageSwapBacked still set, and nothing will clear
      it.
      
      Whether that can do anything worse than issue WARN_ON_ONCEs, and get
      some statistics wrong, is unclear: easier to fix than to think through
      the consequences.
      
      Fixing it here, before the put_new_page(), addresses the bug directly,
      but is probably the worst place to fix it.  Page migration is doing too
      many parts of the job on too many levels: fixing it in
      move_to_new_page() to complement its SetPageSwapBacked would be
      preferable, except why is it (and newpage->mapping and newpage->index)
      done there, rather than down in migrate_page_move_mapping(), once we are
      sure of success? Not a cleanup to get into right now, especially not
      with memcg cleanups coming in 3.17.
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8bdd6380
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · b401796c
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "This is radeon and intel fixes, and is a small bit larger than I'm
        guessing you'd like it to be.
      
         - i915: fixes 32-bit highmem i915 blank screen, semaphore hang and
           runtime pm fix
      
         - radeon: gpuvm stability fix for hangs since 3.15, and hang/reboot
           regression on TN/RL devices,
      
        The only slightly controversial one is the change to use GB for the
        vm_size, which I'm letting through as its a new interface we defined
        in this merge window, and I'd prefer to have the released kernel have
        the final interface rather than changing it later"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/radeon: fix cut and paste issue for hawaii.
        drm/radeon: fix irq ring buffer overflow handling
        drm/i915: Simplify i915_gem_release_all_mmaps()
        drm/radeon: fix error handling in radeon_vm_bo_set_addr
        drm/i915: fix freeze with blank screen booting highmem
        drm/i915: Reorder the semaphore deadlock check, again
        drm/radeon/TN: only enable bapm on MSI systems
        drm/radeon: fix VM IB handling
        drm/radeon: fix handling of radeon_vm_bo_rmv v3
        drm/radeon: let's use GB for vm_size (v2)
      b401796c
    • Linus Torvalds's avatar
      Merge tag 'sound-3.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 9c550218
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "Here contains only the fixes for the new FireWire bebob driver.  All
        fairly trivial and local fixes, so safe to apply"
      
      * tag 'sound-3.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: bebob: Correction for return value of special_clk_ctl_put() in error
        ALSA: bebob: Correction for return value of .put callback
        ALSA: bebob: Use different labels for digital input/output
        ALSA: bebob: Fix a missing to unlock mutex in error handling case
      9c550218
    • Linus Torvalds's avatar
      Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging · 051c2a9f
      Linus Torvalds authored
      Pull hwmon fix from Guenter Roeck:
       "Fixes to temperature limit and vrm write operations in smsc47m192
        driver"
      
      * tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
        hwmon: (smsc47m192) Fix temperature limit and vrm write operations
      051c2a9f
    • Randy Dunlap's avatar
      parport: fix menu breakage · edffe1b6
      Randy Dunlap authored
      Do not split the PARPORT-related symbols with the new kconfig
      symbol ARCH_MIGHT_HAVE_PC_PARPORT. The split was causing incorrect
      display of these symbols -- they were not being displayed together
      as they should be.
      
      Fixes: d90c3eb3 "Kconfig cleanup (PARPORT_PC dependencies)"
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: stable@vger.kernel.org # for 3.13, 3.14, 3.15
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      edffe1b6
    • Linus Torvalds's avatar
      Merge tag 'blackfin-3.16-fixes' of... · 32e6e5c3
      Linus Torvalds authored
      Merge tag 'blackfin-3.16-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux
      
      Pull blackfin fixes from Steven Miao:
       "smc nor flash PM fix, pinctrl group fix, update defconfig, and build
        fixes"
      
      * tag 'blackfin-3.16-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux:
        blackfin: vmlinux.lds.S: reserve 32 bytes space at the end of data section for XIP kernel
        defconfig: BF609: update spi config name
        irq: blackfin sec: drop duplicated sec priority set
        blackfin: bind different groups of one pinmux function to different state name
        blackfin: fix some bf5xx boards build for missing <linux/gpio.h>
        pm: bf609: cleanup smc nor flash
      32e6e5c3
    • Steven Miao's avatar
      blackfin: vmlinux.lds.S: reserve 32 bytes space at the end of data section for XIP kernel · b76f9823
      Steven Miao authored
      to collect some undefined section to the end of the data section and avoid section overlap
      Signed-off-by: default avatarSteven Miao <realmz6@gmail.com>
      b76f9823
    • Steven Miao's avatar
      defconfig: BF609: update spi config name · ac425b61
      Steven Miao authored
      Signed-off-by: default avatarSteven Miao <realmz6@gmail.com>
      ac425b61
    • Steven Miao's avatar
      814ecd0d
    • Sonic Zhang's avatar
    • Steven Miao's avatar
    • Steven Miao's avatar
      pm: bf609: cleanup smc nor flash · c6a26ce9
      Steven Miao authored
      drop smc pin state change code, pin state will be saved in pinctrl-adi2 driver
      cleanup nor flash init/exit for pm suspend/resume
      Signed-off-by: default avatarSteven Miao <realmz6@gmail.com>
      c6a26ce9
  2. 25 Jul, 2014 2 commits
  3. 24 Jul, 2014 11 commits
  4. 23 Jul, 2014 14 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input · b292d6b5
      Linus Torvalds authored
      Pull input layer fixes from Dmitry Torokhov:
       "A few fixups for the input subsystem"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
        Input: document INPUT_PROP_TOPBUTTONPAD
        Input: fix defuzzing logic
        Input: sirfsoc-onkey - fix GPL v2 license string typo
        Input: st-keyscan - fix 'defined but not used' compiler warnings
        Input: synaptics - add min/max quirk for pnp-id LEN2002 (Edge E531)
        Input: i8042 - add Acer Aspire 5710 to nomux blacklist
        Input: ti_am335x_tsc - warn about incorrect spelling
        Input: wacom - cleanup multitouch code when touch_max is 2
      b292d6b5
    • Linus Torvalds's avatar
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc · 7442cf9a
      Linus Torvalds authored
      Pull powerpc fixes from Ben Herrenschmidt:
       "Here is a handful of powerpc fixes for 3.16.  They are all pretty
        simple and self contained and should still make this release"
      
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
        powerpc: use _GLOBAL_TOC for memmove
        powerpc/pseries: dynamically added OF nodes need to call of_node_init
        powerpc: subpage_protect: Increase the array size to take care of 64TB
        powerpc: Fix bugs in emulate_step()
        powerpc: Disable doorbells on Power8 DD1.x
      7442cf9a
    • Linus Torvalds's avatar
      Merge tag 'urgent-slab-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · 355cb093
      Linus Torvalds authored
      Pull slab fix from Mike Snitzer:
       "This fixes the broken duplicate slab name check in
        kmem_cache_sanity_check() that has been repeatedly reported (as
        recently as today against Fedora rawhide).
      
        Pekka seemed to have it staged for a late 3.15-rc in his 'slab/urgent'
        branch but never sent a pull request, see:
            https://lkml.org/lkml/2014/5/23/648"
      
      * tag 'urgent-slab-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        slab_common: fix the check for duplicate slab names
      355cb093
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew Morton) · ed4a1084
      Linus Torvalds authored
      Merge fixes from Andrew Morton:
       "10 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        mm: hugetlb: fix copy_hugetlb_page_range()
        simple_xattr: permit 0-size extended attributes
        mm/fs: fix pessimization in hole-punching pagecache
        shmem: fix splicing from a hole while it's punched
        shmem: fix faulting into a hole, not taking i_mutex
        mm: do not call do_fault_around for non-linear fault
        sh: also try passing -m4-nofpu for SH2A builds
        zram: avoid lockdep splat by revalidate_disk
        mm/rmap.c: fix pgoff calculation to handle hugepage correctly
        coredump: fix the setting of PF_DUMPCORE
      ed4a1084
    • Naoya Horiguchi's avatar
      mm: hugetlb: fix copy_hugetlb_page_range() · 0253d634
      Naoya Horiguchi authored
      Commit 4a705fef ("hugetlb: fix copy_hugetlb_page_range() to handle
      migration/hwpoisoned entry") changed the order of
      huge_ptep_set_wrprotect() and huge_ptep_get(), which leads to breakage
      in some workloads like hugepage-backed heap allocation via libhugetlbfs.
      This patch fixes it.
      
      The test program for the problem is shown below:
      
        $ cat heap.c
        #include <unistd.h>
        #include <stdlib.h>
        #include <string.h>
      
        #define HPS 0x200000
      
        int main() {
        	int i;
        	char *p = malloc(HPS);
        	memset(p, '1', HPS);
        	for (i = 0; i < 5; i++) {
        		if (!fork()) {
        			memset(p, '2', HPS);
        			p = malloc(HPS);
        			memset(p, '3', HPS);
        			free(p);
        			return 0;
        		}
        	}
        	sleep(1);
        	free(p);
        	return 0;
        }
      
        $ export HUGETLB_MORECORE=yes ; export HUGETLB_NO_PREFAULT= ; hugectl --heap ./heap
      
      Fixes 4a705fef ("hugetlb: fix copy_hugetlb_page_range() to handle
      migration/hwpoisoned entry"), so is applicable to -stable kernels which
      include it.
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Reported-by: default avatarGuillaume Morin <guillaume@morinfr.org>
      Suggested-by: default avatarGuillaume Morin <guillaume@morinfr.org>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Cc: <stable@vger.kernel.org>	[2.6.37+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0253d634
    • Hugh Dickins's avatar
      simple_xattr: permit 0-size extended attributes · 4e66d445
      Hugh Dickins authored
      If a filesystem uses simple_xattr to support user extended attributes,
      LTP setxattr01 and xfstests generic/062 fail with "Cannot allocate
      memory": simple_xattr_alloc()'s wrap-around test mistakenly excludes
      values of zero size.  Fix that off-by-one (but apparently no filesystem
      needs them yet).
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Jeff Layton <jlayton@poochiereds.net>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4e66d445
    • Hugh Dickins's avatar
      mm/fs: fix pessimization in hole-punching pagecache · 792ceaef
      Hugh Dickins authored
      I wanted to revert my v3.1 commit d0823576 ("mm: pincer in
      truncate_inode_pages_range"), to keep truncate_inode_pages_range() in
      synch with shmem_undo_range(); but have stepped back - a change to
      hole-punching in truncate_inode_pages_range() is a change to
      hole-punching in every filesystem (except tmpfs) that supports it.
      
      If there's a logical proof why no filesystem can depend for its own
      correctness on the pincer guarantee in truncate_inode_pages_range() - an
      instant when the entire hole is removed from pagecache - then let's
      revisit later.  But the evidence is that only tmpfs suffered from the
      livelock, and we have no intention of extending hole-punch to ramfs.  So
      for now just add a few comments (to match or differ from those in
      shmem_undo_range()), and fix one silliness noticed in d0823576...
      
      Its "index == start" addition to the hole-punch termination test was
      incomplete: it opened a way for the end condition to be missed, and the
      loop go on looking through the radix_tree, all the way to end of file.
      Fix that pessimization by resetting index when detected in inner loop.
      
      Note that it's actually hard to hit this case, without the obsessive
      concurrent faulting that trinity does: normally all pages are removed in
      the initial trylock_page() pass, and this loop finds nothing to do.  I
      had to "#if 0" out the initial pass to reproduce bug and test fix.
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Lukas Czerner <lczerner@redhat.com>
      Cc: Dave Jones <davej@redhat.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      792ceaef
    • Hugh Dickins's avatar
      shmem: fix splicing from a hole while it's punched · b1a36650
      Hugh Dickins authored
      shmem_fault() is the actual culprit in trinity's hole-punch starvation,
      and the most significant cause of such problems: since a page faulted is
      one that then appears page_mapped(), needing unmap_mapping_range() and
      i_mmap_mutex to be unmapped again.
      
      But it is not the only way in which a page can be brought into a hole in
      the radix_tree while that hole is being punched; and Vlastimil's testing
      implies that if enough other processors are busy filling in the hole,
      then shmem_undo_range() can be kept from completing indefinitely.
      
      shmem_file_splice_read() is the main other user of SGP_CACHE, which can
      instantiate shmem pagecache pages in the read-only case (without holding
      i_mutex, so perhaps concurrently with a hole-punch).  Probably it's
      silly not to use SGP_READ already (using the ZERO_PAGE for holes): which
      ought to be safe, but might bring surprises - not a change to be rushed.
      
      shmem_read_mapping_page_gfp() is an internal interface used by
      drivers/gpu/drm GEM (and next by uprobes): it should be okay.  And
      shmem_file_read_iter() uses the SGP_DIRTY variant of SGP_CACHE, when
      called internally by the kernel (perhaps for a stacking filesystem,
      which might rely on holes to be reserved): it's unclear whether it could
      be provoked to keep hole-punch busy or not.
      
      We could apply the same umbrella as now used in shmem_fault() to
      shmem_file_splice_read() and the others; but it looks ugly, and use over
      a range raises questions - should it actually be per page? can these get
      starved themselves?
      
      The origin of this part of the problem is my v3.1 commit d0823576
      ("mm: pincer in truncate_inode_pages_range"), once it was duplicated
      into shmem.c.  It seemed like a nice idea at the time, to ensure
      (barring RCU lookup fuzziness) that there's an instant when the entire
      hole is empty; but the indefinitely repeated scans to ensure that make
      it vulnerable.
      
      Revert that "enhancement" to hole-punch from shmem_undo_range(), but
      retain the unproblematic rescanning when it's truncating; add a couple
      of comments there.
      
      Remove the "indices[0] >= end" test: that is now handled satisfactorily
      by the inner loop, and mem_cgroup_uncharge_start()/end() are too light
      to be worth avoiding here.
      
      But if we do not always loop indefinitely, we do need to handle the case
      of swap swizzled back to page before shmem_free_swap() gets it: add a
      retry for that case, as suggested by Konstantin Khlebnikov; and for the
      case of page swizzled back to swap, as suggested by Johannes Weiner.
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Suggested-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Lukas Czerner <lczerner@redhat.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: <stable@vger.kernel.org>	[3.1+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b1a36650
    • Hugh Dickins's avatar
      shmem: fix faulting into a hole, not taking i_mutex · 8e205f77
      Hugh Dickins authored
      Commit f00cdc6d ("shmem: fix faulting into a hole while it's
      punched") was buggy: Sasha sent a lockdep report to remind us that
      grabbing i_mutex in the fault path is a no-no (write syscall may already
      hold i_mutex while faulting user buffer).
      
      We tried a completely different approach (see following patch) but that
      proved inadequate: good enough for a rational workload, but not good
      enough against trinity - which forks off so many mappings of the object
      that contention on i_mmap_mutex while hole-puncher holds i_mutex builds
      into serious starvation when concurrent faults force the puncher to fall
      back to single-page unmap_mapping_range() searches of the i_mmap tree.
      
      So return to the original umbrella approach, but keep away from i_mutex
      this time.  We really don't want to bloat every shmem inode with a new
      mutex or completion, just to protect this unlikely case from trinity.
      So extend the original with wait_queue_head on stack at the hole-punch
      end, and wait_queue item on the stack at the fault end.
      
      This involves further use of i_lock to guard against the races: lockdep
      has been happy so far, and I see fs/inode.c:unlock_new_inode() holds
      i_lock around wake_up_bit(), which is comparable to what we do here.
      i_lock is more convenient, but we could switch to shmem's info->lock.
      
      This issue has been tagged with CVE-2014-4171, which will require commit
      f00cdc6d and this and the following patch to be backported: we
      suggest to 3.1+, though in fact the trinity forkbomb effect might go
      back as far as 2.6.16, when madvise(,,MADV_REMOVE) came in - or might
      not, since much has changed, with i_mmap_mutex a spinlock before 3.0.
      Anyone running trinity on 3.0 and earlier? I don't think we need care.
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Tested-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Lukas Czerner <lczerner@redhat.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: <stable@vger.kernel.org>	[3.1+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8e205f77
    • Konstantin Khlebnikov's avatar
      mm: do not call do_fault_around for non-linear fault · c118678b
      Konstantin Khlebnikov authored
      Ingo Korb reported that "repeated mapping of the same file on tmpfs
      using remap_file_pages sometimes triggers a BUG at mm/filemap.c:202 when
      the process exits".
      
      He bisected the bug to d7c17551 ("mm: implement ->map_pages for
      shmem/tmpfs"), although the bug was actually added by commit
      8c6e50b0 ("mm: introduce vm_ops->map_pages()").
      
      The problem is caused by calling do_fault_around for a _non-linear_
      fault.  In this case pgoff is shifted and might become negative during
      calculation.
      
      Faulting around non-linear page-fault makes no sense and breaks the
      logic in do_fault_around because pgoff is shifted.
      Signed-off-by: default avatarKonstantin Khlebnikov <koct9i@gmail.com>
      Reported-by: default avatarIngo Korb <ingo.korb@tu-dortmund.de>
      Tested-by: default avatarIngo Korb <ingo.korb@tu-dortmund.de>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Ning Qu <quning@google.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: <stable@vger.kernel.org>	[3.15.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c118678b
    • Geert Uytterhoeven's avatar
      sh: also try passing -m4-nofpu for SH2A builds · b1923b55
      Geert Uytterhoeven authored
      When compiling a SH2A kernel (e.g.  se7206_defconfig or rsk7203_defconfig)
      using sh4-linux-gcc, linking fails with:
      
        net/built-in.o: In function `__sk_run_filter':
        net/core/filter.c:566: undefined reference to `__fpscr_values'
        net/core/filter.c:269: undefined reference to `__fpscr_values'
        ...
        net/built-in.o:net/core/filter.c:580: more undefined references to `__fpscr_values' follow
      
      This happens because sh4-linux-gcc doesn't support the "-m2a-nofpu",
      which is thus filtered out by "$(call cc-option, ...)".
      
      As compiling using sh4-linux-gcc is useful for compile coverage, also
      try passing "-m4-nofpu" (which is presumably filtered out when using a
      real sh2a-linux toolchain) to disable the generation of FPU instructions
      and references to __fpscr_values[].
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Tony Breeds <tony@bakeyournoodle.com>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Daniel Borkmann <dborkman@redhat.com>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b1923b55
    • Minchan Kim's avatar
      zram: avoid lockdep splat by revalidate_disk · b4c5c609
      Minchan Kim authored
      Sasha reported lockdep warning [1] introduced by [2].
      
      It could be fixed by doing disk revalidation out of the init_lock.  It's
      okay because disk capacity change is protected by init_lock so that
      revalidate_disk always sees up-to-date value so there is no race.
      
      [1] https://lkml.org/lkml/2014/7/3/735
      [2] zram: revalidate disk after capacity change
      
      Fixes 2e32baea ("zram: revalidate disk after capacity change").
      Signed-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Cc: "Alexander E. Patrakov" <patrakov@gmail.com>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b4c5c609
    • Naoya Horiguchi's avatar
      mm/rmap.c: fix pgoff calculation to handle hugepage correctly · a0f7a756
      Naoya Horiguchi authored
      I triggered VM_BUG_ON() in vma_address() when I tried to migrate an
      anonymous hugepage with mbind() in the kernel v3.16-rc3.  This is
      because pgoff's calculation in rmap_walk_anon() fails to consider
      compound_order() only to have an incorrect value.
      
      This patch introduces page_to_pgoff(), which gets the page's offset in
      PAGE_CACHE_SIZE.
      
      Kirill pointed out that page cache tree should natively handle
      hugepages, and in order to make hugetlbfs fit it, page->index of
      hugetlbfs page should be in PAGE_CACHE_SIZE.  This is beyond this patch,
      but page_to_pgoff() contains the point to be fixed in a single function.
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Hillf Danton <dhillf@gmail.com>
      Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a0f7a756
    • Silesh C V's avatar
      coredump: fix the setting of PF_DUMPCORE · aed8adb7
      Silesh C V authored
      Commit 079148b9 ("coredump: factor out the setting of PF_DUMPCORE")
      cleaned up the setting of PF_DUMPCORE by removing it from all the
      linux_binfmt->core_dump() and moving it to zap_threads().But this ended
      up clearing all the previously set flags.  This causes issues during
      core generation when tsk->flags is checked again (eg.  for PF_USED_MATH
      to dump floating point registers).  Fix this.
      Signed-off-by: default avatarSilesh C V <svellattu@mvista.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Mandeep Singh Baines <msb@chromium.org>
      Cc: <stable@vger.kernel.org>	[3.10+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      aed8adb7