1. 16 Feb, 2015 11 commits
  2. 15 Feb, 2015 6 commits
  3. 12 Feb, 2015 2 commits
  4. 10 Feb, 2015 1 commit
  5. 09 Feb, 2015 5 commits
    • Linus Torvalds's avatar
      Linux 3.19 · bfa76d49
      Linus Torvalds authored
      bfa76d49
    • Linus Torvalds's avatar
      Merge tag 'nios2-fixes-v3.19-final' of git://git.rocketboards.org/linux-socfpga-next · da2d96d3
      Linus Torvalds authored
      Pull nios2 fix from Ley Foon Tan:
       "This fixes incorrect behavior of some user programs"
      
      * tag 'nios2-fixes-v3.19-final' of git://git.rocketboards.org/linux-socfpga-next:
        nios2: fix unhandled signals
      da2d96d3
    • Linus Torvalds's avatar
      Merge git://git.kvack.org/~bcrl/aio-fixes · cdecbb33
      Linus Torvalds authored
      Pull aio nested sleep annotation from Ben LaHaise,
      
      * git://git.kvack.org/~bcrl/aio-fixes:
        aio: annotate aio_read_event_ring for sleep patterns
      cdecbb33
    • Linus Torvalds's avatar
      Merge tag 'trace-fixes-v3.19-rc7' of... · 4e02370f
      Linus Torvalds authored
      Merge tag 'trace-fixes-v3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
      
      Pull ftrace fixes from Steven Rostedt:
       "During testing Sedat Dilek hit a "suspicious RCU usage" splat that
        pointed out a real bug.  During suspend and resume the tlb_flush
        tracepoint is called when the CPU is going offline.  As the CPU has
        been noted as offline, RCU is ignoring that CPU, which means that it
        can not use RCU protected locks.  When tracepoints are activated, they
        require RCU locking, and if RCU is ignoring a CPU that runs a
        tracepoint, there is a chance that the tracepoint could cause
        corruption.
      
        The solution was to change the tracepoint into a
        TRACE_EVENT_CONDITION() which allows us to check a condition to
        determine if the tracepoint should be called or not.  If the condition
        is not met, the rcu protected code will not be executed.  By adding
        the condition "cpu_online(smp_processor_id())", this will prevent the
        RCU protected code from being executed if the CPU is marked offline.
      
        After adding this, another bug was discovered.  As RCU checks rcu
        callers, if a rcu call is not done, there is no check (obviously).  We
        found that tracepoints could be added in RCU ignored locations and not
        have lockdep complain until the tracepoint is activated.  This missed
        places where tracepoints were added in places they should not have
        been.  To fix this, code was added in 3.18 that if lockdep is enabled,
        any tracepoint will still call the rcu checks even if the tracepoint
        is not enabled.  The bug here, is that the check does not take the
        CONDITION into account.  As the condition may prevent tracepoints from
        being activated in RCU ignored areas (as the one patch does), we get
        false positives when we enable lockdep and hit a tracepoint that the
        condition prevents it from being called in a RCU ignored location.
      
        The fix for this is to add the CONDITION to the rcu checks, even if
        the tracepoint is not enabled"
      
      * tag 'trace-fixes-v3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        x86/tlb/trace: Do not trace on CPU that is offline
        tracing: Add condition check to RCU lockdep checks
      4e02370f
    • Chung-Ling Tang's avatar
      nios2: fix unhandled signals · a3248d60
      Chung-Ling Tang authored
      Follow other architectures for user fault handling.
      Signed-off-by: default avatarChung-Ling Tang <cltang@codesourcery.com>
      Acked-by: default avatarLey Foon Tan <lftan@altera.com>
      a3248d60
  6. 08 Feb, 2015 2 commits
    • Steven Rostedt (Red Hat)'s avatar
      x86/tlb/trace: Do not trace on CPU that is offline · 6c8465a8
      Steven Rostedt (Red Hat) authored
      When taking a CPU down for suspend and resume, a tracepoint may be called
      when the CPU has been designated offline. As tracepoints require RCU for
      protection, they must not be called if the current CPU is offline.
      
      Unfortunately, trace_tlb_flush() is called in this scenario as was noted
      by LOCKDEP:
      
      ...
      
       Disabling non-boot CPUs ...
       intel_pstate CPU 1 exiting
      
       ===============================
       smpboot: CPU 1 didn't die...
       [ INFO: suspicious RCU usage. ]
       3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted
       -------------------------------
       include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage!
      
       other info that might help us debug this:
      
       RCU used illegally from offline CPU!
       rcu_scheduler_active = 1, debug_locks = 0
       no locks held by swapper/1/0.
      
       stack backtrace:
       CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc7-next-20150204.1-iniza-small #1
       Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
        0000000000000001 ffff88011a44fe18 ffffffff817e370d 0000000000000011
        ffff88011a448290 ffff88011a44fe48 ffffffff810d6847 ffff8800c66b9600
        0000000000000001 ffff88011a44c000 ffffffff81cb3900 ffff88011a44fe78
       Call Trace:
        [<ffffffff817e370d>] dump_stack+0x4c/0x65
        [<ffffffff810d6847>] lockdep_rcu_suspicious+0xe7/0x120
        [<ffffffff810b71a5>] idle_task_exit+0x205/0x2c0
        [<ffffffff81054c4e>] play_dead_common+0xe/0x50
        [<ffffffff81054ca5>] native_play_dead+0x15/0x140
        [<ffffffff8102963f>] arch_cpu_idle_dead+0xf/0x20
        [<ffffffff810cd89e>] cpu_startup_entry+0x37e/0x580
        [<ffffffff81053e20>] start_secondary+0x140/0x150
       intel_pstate CPU 2 exiting
      
      ...
      
      By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the
      condition is cpu_online(smp_processor_id()), we can avoid calling RCU protected
      code when the CPU is offline.
      
      Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com
      
      Cc: stable@vger.kernel.org # 3.17+
      Fixes: d17d8f9d "x86/mm: Add tracepoints for TLB flushes"
      Reported-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Suggested-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: default avatarDave Hansen <dave@sr71.net>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      6c8465a8
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Add condition check to RCU lockdep checks · a05d59a5
      Steven Rostedt (Red Hat) authored
      The trace_tlb_flush() tracepoint can be called when a CPU is going offline.
      When a CPU is offline, RCU is no longer watching that CPU and since the
      tracepoint is protected by RCU, it must not be called. To prevent the
      tlb_flush tracepoint from being called when the CPU is offline, it was
      converted to a TRACE_EVENT_CONDITION where the condition checks if the
      CPU is online before calling the tracepoint.
      
      Unfortunately, this was not enough to stop lockdep from complaining about
      it. Even though the RCU protected code of the tracepoint will never be
      called, the condition is hidden within the tracepoint, and even though the
      condition prevents RCU code from being called, the lockdep checks are
      outside the tracepoint (this is to test tracepoints even when they are not
      enabled).
      
      Even though tracepoints should be checked to be RCU safe when they are not
      enabled, the condition should still be considered when checking RCU.
      
      Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com
      
      Fixes: 3a630178 "tracing: generate RCU warnings even when tracepoints are disabled"
      Cc: stable@vger.kernel.org # 3.18+
      Acked-by: default avatarDave Hansen <dave@sr71.net>
      Reported-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      a05d59a5
  7. 07 Feb, 2015 2 commits
  8. 06 Feb, 2015 9 commits
  9. 05 Feb, 2015 2 commits
    • Joonsoo Kim's avatar
      mm/debug_pagealloc: fix build failure on ppc and some other archs · 7b02190c
      Joonsoo Kim authored
      Kim Phillips reported following build failure.
      
        LD      init/built-in.o
        mm/built-in.o: In function `free_pages_prepare':
        mm/page_alloc.c:770: undefined reference to `.kernel_map_pages'
        mm/built-in.o: In function `prep_new_page':
        mm/page_alloc.c:933: undefined reference to `.kernel_map_pages'
        mm/built-in.o: In function `map_pages':
        mm/compaction.c:61: undefined reference to `.kernel_map_pages'
        make: *** [vmlinux] Error 1
      
      Reason for this problem is that commit 031bc574
      ("mm/debug-pagealloc: make debug-pagealloc boottime configurable")
      forgot to remove the old declaration of kernel_map_pages() for some
      architectures.  This patch removes them to fix build failure.
      Reported-by: default avatarKim Phillips <kim.phillips@freescale.com>
      Signed-off-by: default avatarJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7b02190c
    • Ryusuke Konishi's avatar
      nilfs2: fix deadlock of segment constructor over I_SYNC flag · 7ef3ff2f
      Ryusuke Konishi authored
      Nilfs2 eventually hangs in a stress test with fsstress program.  This
      issue was caused by the following deadlock over I_SYNC flag between
      nilfs_segctor_thread() and writeback_sb_inodes():
      
        nilfs_segctor_thread()
          nilfs_segctor_thread_construct()
            nilfs_segctor_unlock()
              nilfs_dispose_list()
                iput()
                  iput_final()
                    evict()
                      inode_wait_for_writeback()  * wait for I_SYNC flag
      
        writeback_sb_inodes()
           * set I_SYNC flag on inode->i_state
          __writeback_single_inode()
            do_writepages()
              nilfs_writepages()
                nilfs_construct_dsync_segment()
                  nilfs_segctor_sync()
                     * wait for completion of segment constructor
          inode_sync_complete()
             * clear I_SYNC flag after __writeback_single_inode() completed
      
      writeback_sb_inodes() calls do_writepages() for dirty inodes after
      setting I_SYNC flag on inode->i_state.  do_writepages() in turn calls
      nilfs_writepages(), which can run segment constructor and wait for its
      completion.  On the other hand, segment constructor calls iput(), which
      can call evict() and wait for the I_SYNC flag on
      inode_wait_for_writeback().
      
      Since segment constructor doesn't know when I_SYNC will be set, it
      cannot know whether iput() will block or not unless inode->i_nlink has a
      non-zero count.  We can prevent evict() from being called in iput() by
      implementing sop->drop_inode(), but it's not preferable to leave inodes
      with i_nlink == 0 for long periods because it even defers file
      truncation and inode deallocation.  So, this instead resolves the
      deadlock by calling iput() asynchronously with a workqueue for inodes
      with i_nlink == 0.
      Signed-off-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Tested-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      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>
      7ef3ff2f