1. 28 7月, 2014 4 次提交
  2. 27 7月, 2014 2 次提交
    • L
      Fix gcc-4.9.0 miscompilation of load_balance() in scheduler · 2062afb4
      Linus Torvalds 提交于
      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: NMichel Dänzer <michel@daenzer.net>
      Suggested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2062afb4
    • H
      mm: fix direct reclaim writeback regression · 8bdd6380
      Hugh Dickins 提交于
      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: NDave Jones <davej@redhat.com>
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bdd6380
  3. 26 7月, 2014 13 次提交
  4. 25 7月, 2014 6 次提交
    • H
      x86: Merge tag 'ras_urgent' into x86/urgent · bf72f5de
      H. Peter Anvin 提交于
      Promote one fix for 3.16
      
      This fix was necessary after
      
      9c15a24b ("x86/mce: Improve mcheck_init_device() error handling")
      
      went in. What this patch did was, among others, check the return value
      of misc_register and exit early if it encountered an error. Original
      code sloppily didn't do that.
      
      However,
      
              cef12ee5 ("xen/mce: Add mcelog support for Xen platform")
      
      made it so that xen's init routine xen_late_init_mcelog runs first. This
      was needed for the xen mcelog device which is supposed to be independent
      from the baremetal one.
      
      Initially it was reported that misc_register() fails often on xen and
      that's why it needed fixing. However, it is *supposed* to fail by
      design, when running in dom0 so that the xen mcelog device file gets
      registered first.
      
      And *then* you need the notifier *not* unregistered on the error path so
      that the timer does get deleted properly in the CPU hotplug notifier.
      
      Btw, this fix is needed also on baremetal in the unlikely event that
      misc_register(&mce_chrdev_device) fails there too.
      
      I was unsure whether to rush it in now and decided to delay it to 3.17.
      However, xen people wanted it promoted as it breaks xen when doing cpu
      hotplug there. So, after a bit of simmering in tip/master for initial
      smoke testing, let's move it to 3.16. It fixes a semi-regression which
      got introduced in 3.16 so no need for stable tagging.
      
      tip/x86/ras contains that exact same commit but we can't remove it
      there as it is not the last one. It won't cause any merge issues, as I
      confirmed locally but I should state here the special situation of this
      one fix explicitly anyway.
      
      Thanks.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      bf72f5de
    • J
      drm/radeon: fix cut and paste issue for hawaii. · 1b2c4869
      Jerome Glisse 提交于
      This is a halfway fix for hawaii acceleration. More fixes to come
      but hopefully isolated to userspace.
      Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      1b2c4869
    • D
      Merge branch 'drm-fixes-3.16' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · 97cefc3e
      Dave Airlie 提交于
      two more radeon fixes.
      
      * 'drm-fixes-3.16' of git://people.freedesktop.org/~agd5f/linux:
        drm/radeon: fix irq ring buffer overflow handling
        drm/radeon: fix error handling in radeon_vm_bo_set_addr
      97cefc3e
    • D
      Merge tag 'drm-intel-fixes-2014-07-24' of git://anongit.freedesktop.org/drm-intel into drm-fixes · 9d6ed3c6
      Dave Airlie 提交于
      This time in time! Just 32bit-pae fix from Hugh, semaphores fun from Chris
      and a fix for runtime pm cherry-picked from next.
      
      Paulo is still working on a fix for runtime pm when X does cursor fun when
      the display is off, but that one isn't ready yet.
      
      * tag 'drm-intel-fixes-2014-07-24' of git://anongit.freedesktop.org/drm-intel:
        drm/i915: Simplify i915_gem_release_all_mmaps()
        drm/i915: fix freeze with blank screen booting highmem
        drm/i915: Reorder the semaphore deadlock check, again
      9d6ed3c6
    • H
      parisc: Eliminate memset after alloc_bootmem_pages · 9794144d
      HIMANGI SARAOGI 提交于
      alloc_bootmem and related function always return zeroed region of
      memory. Thus a memset after calls to these functions is unnecessary.
      
      The following Coccinelle semantic patch was used for making the change:
      
      @@
      expression E,E1;
      @@
      
      E = \(alloc_bootmem\|alloc_bootmem_low\|alloc_bootmem_pages\|alloc_bootmem_low_pages\)(...)
      ... when != E
      - memset(E,0,E1);
      Signed-off-by: NHimangi Saraogi <himangi774@gmail.com>
      Acked-by: NJulia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      9794144d
    • J
      parisc: Remove SA_RESTORER define · 20dbea49
      John David Anglin 提交于
      The sa_restorer field in struct sigaction is obsolete and no longer in
      the parisc implementation.  However, the core code assumes the field is
      present if SA_RESTORER is defined. So, the define needs to be removed.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      20dbea49
  5. 24 7月, 2014 15 次提交