1. 30 Aug, 2015 13 commits
  2. 28 Aug, 2015 3 commits
  3. 27 Aug, 2015 2 commits
  4. 25 Aug, 2015 8 commits
  5. 24 Aug, 2015 2 commits
  6. 23 Aug, 2015 3 commits
  7. 22 Aug, 2015 7 commits
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm · b7dec838
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Another couple of small ARM fixes.
      
        A patch from Masahiro Yamada who noticed that "make -jN all zImage"
        would end up generating bad images where N > 1, and a patch from
        Nicolas to fix the Marvell CPU user access optimisation code when page
        faults are disabled"
      
      * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
        ARM: 8418/1: add boot image dependencies to not generate invalid images
        ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usage
      b7dec838
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · d0b89bd5
      Linus Torvalds authored
      Pull x86 fixes from Ingo Molnar:
       "Various low level fixes: fix more fallout from the FPU rework and the
        asm entry code rework, plus an MSI rework fix, and an idle-tracing fix"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/fpu/math-emu: Fix crash in fork()
        x86/fpu/math-emu: Fix math-emu boot crash
        x86/idle: Restore trace_cpu_idle to mwait_idle() calls
        x86/irq: Build correct vector mapping for multiple MSI interrupts
        Revert "sched/x86_64: Don't save flags on context switch"
      d0b89bd5
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · c3a06514
      Linus Torvalds authored
      Pull perf fixes from Ingo Molnar:
       "Tooling fixes: a 'perf record' deadlock fix plus debuggability fixes"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf top: Show backtrace when handling a SIGSEGV on --stdio mode
        perf tools: Fix buildid processing
        perf tools: Make fork event processing more resilient
        perf tools: Avoid deadlock when map_groups are broken
      c3a06514
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 84f3fe46
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "A series of small fixlets for a regression visible on OMAP devices
        caused by the conversion of the OMAP interrupt chips to hierarchical
        interrupt domains.  Mostly one liners on the driver side plus a small
        helper function in the core to avoid open coded mess in the drivers"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip/crossbar: Restore set_wake functionality
        irqchip/crossbar: Restore the mask on suspend behaviour
        ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism
        irqchip/crossbar: Restore the irq_set_type() mechanism
        genirq: Introduce irq_chip_set_type_parent() helper
        genirq: Don't return ENOSYS in irq_chip_retrigger_hierarchy
      84f3fe46
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f8a89fc0
      Linus Torvalds authored
      Pull timer fixes from Thomas Gleixner:
       "Two minimalistic fixes for 4.2 regressions:
      
         - Eric fixed a thinko in the timer_list base switching code caused by
           the overhaul of the timer wheel.  It can cause a cpu to see the
           wrong base for a timer while we move the timer around.
      
         - Guenter fixed a regression for IMX if booted w/o device tree, where
           the timer interrupt is not initialized and therefor the machine
           fails to boot"
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        clocksource/imx: Fix boot with non-DT systems
        timer: Write timer->flags atomically
      f8a89fc0
    • Ingo Molnar's avatar
      x86/fpu/math-emu: Fix crash in fork() · 827409b2
      Ingo Molnar authored
      During later stages of math-emu bootup the following crash triggers:
      
      	 math_emulate: 0060:c100d0a8
      	 Kernel panic - not syncing: Math emulation needed in kernel
      	 CPU: 0 PID: 1511 Comm: login Not tainted 4.2.0-rc7+ #1012
      	 [...]
      	 Call Trace:
      	  [<c181d50d>] dump_stack+0x41/0x52
      	  [<c181c918>] panic+0x77/0x189
      	  [<c1003530>] ? math_error+0x140/0x140
      	  [<c164c2d7>] math_emulate+0xba7/0xbd0
      	  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
      	  [<c1109c3c>] ? __alloc_pages_nodemask+0x12c/0x870
      	  [<c136ac20>] ? proc_clear_tty+0x40/0x70
      	  [<c136ac6e>] ? session_clear_tty+0x1e/0x30
      	  [<c1003530>] ? math_error+0x140/0x140
      	  [<c1003575>] do_device_not_available+0x45/0x70
      	  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
      	  [<c18258e6>] error_code+0x5a/0x60
      	  [<c1003530>] ? math_error+0x140/0x140
      	  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
      	  [<c100c205>] arch_dup_task_struct+0x25/0x30
      	  [<c1048cea>] copy_process.part.51+0xea/0x1480
      	  [<c115a8e5>] ? dput+0x175/0x200
      	  [<c136af70>] ? no_tty+0x30/0x30
      	  [<c1157242>] ? do_vfs_ioctl+0x322/0x540
      	  [<c104a21a>] _do_fork+0xca/0x340
      	  [<c1057b06>] ? SyS_rt_sigaction+0x66/0x90
      	  [<c104a557>] SyS_clone+0x27/0x30
      	  [<c1824a80>] sysenter_do_call+0x12/0x12
      
      The reason is the incorrect assumption in fpu_copy(), that FNSAVE
      can be executed from math-emu kernels as well.
      
      Don't try to copy the registers, the soft state will be copied
      by fork anyway, so the child task inherits the parent task's
      soft math state.
      
      With this fix applied math-emu kernels boot up fine on modern
      hardware and the 'no387 nofxsr' boot options.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Bobby Powers <bobbypowers@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      827409b2
    • Ingo Molnar's avatar
      x86/fpu/math-emu: Fix math-emu boot crash · 5fc96038
      Ingo Molnar authored
      On a math-emu bootup the following crash occurs:
      
      	Initializing CPU#0
      	------------[ cut here ]------------
      	kernel BUG at arch/x86/kernel/traps.c:779!
      	invalid opcode: 0000 [#1] SMP
      	[...]
      	EIP is at do_device_not_available+0xe/0x70
      	[...]
      	Call Trace:
      	 [<c18238e6>] error_code+0x5a/0x60
      	 [<c1002bd0>] ? math_error+0x140/0x140
      	 [<c100bbd9>] ? fpu__init_cpu+0x59/0xa0
      	 [<c1012322>] cpu_init+0x202/0x330
      	 [<c104509f>] ? __native_set_fixmap+0x1f/0x30
      	 [<c1b56ab0>] trap_init+0x305/0x346
      	 [<c1b548af>] start_kernel+0x1a5/0x35d
      	 [<c1b542b4>] i386_start_kernel+0x82/0x86
      
      The reason is that in the following commit:
      
        b1276c48 ("x86/fpu: Initialize fpregs in fpu__init_cpu_generic()")
      
      I failed to consider math-emu's limitation that it cannot execute the
      FNINIT instruction in kernel mode.
      
      The long term fix might be to allow math-emu to execute (certain) kernel
      mode FPU instructions, but for now apply the safe (albeit somewhat ugly)
      fix: initialize the emulation state explicitly without trapping out to
      the FPU emulator.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5fc96038
  8. 21 Aug, 2015 2 commits
    • Christoph Hellwig's avatar
      Add hch to .get_maintainer.ignore · e525293d
      Christoph Hellwig authored
      While the idea behind get_maintainer seems highly useful it's
      unfortunately way to trigger happy to grab people that once had a few
      commits to files.  For someone like me who does a lot of tree-wide API
      work that leads to an incredible amount of Cc spam.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e525293d
    • Michal Hocko's avatar
      mm: make page pfmemalloc check more robust · 2f064f34
      Michal Hocko authored
      Commit c48a11c7 ("netvm: propagate page->pfmemalloc to skb") added
      checks for page->pfmemalloc to __skb_fill_page_desc():
      
              if (page->pfmemalloc && !page->mapping)
                      skb->pfmemalloc = true;
      
      It assumes page->mapping == NULL implies that page->pfmemalloc can be
      trusted.  However, __delete_from_page_cache() can set set page->mapping
      to NULL and leave page->index value alone.  Due to being in union, a
      non-zero page->index will be interpreted as true page->pfmemalloc.
      
      So the assumption is invalid if the networking code can see such a page.
      And it seems it can.  We have encountered this with a NFS over loopback
      setup when such a page is attached to a new skbuf.  There is no copying
      going on in this case so the page confuses __skb_fill_page_desc which
      interprets the index as pfmemalloc flag and the network stack drops
      packets that have been allocated using the reserves unless they are to
      be queued on sockets handling the swapping which is the case here and
      that leads to hangs when the nfs client waits for a response from the
      server which has been dropped and thus never arrive.
      
      The struct page is already heavily packed so rather than finding another
      hole to put it in, let's do a trick instead.  We can reuse the index
      again but define it to an impossible value (-1UL).  This is the page
      index so it should never see the value that large.  Replace all direct
      users of page->pfmemalloc by page_is_pfmemalloc which will hide this
      nastiness from unspoiled eyes.
      
      The information will get lost if somebody wants to use page->index
      obviously but that was the case before and the original code expected
      that the information should be persisted somewhere else if that is
      really needed (e.g.  what SLAB and SLUB do).
      
      [akpm@linux-foundation.org: fix blooper in slub]
      Fixes: c48a11c7 ("netvm: propagate page->pfmemalloc to skb")
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Debugged-by: default avatarVlastimil Babka <vbabka@suse.com>
      Debugged-by: default avatarJiri Bohac <jbohac@suse.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: <stable@vger.kernel.org>	[3.6+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f064f34