1. 21 Aug, 2009 5 commits
    • Linus Torvalds's avatar
      Merge branch 'btrfs' of git://git.kernel.dk/linux-2.6-block · b57f9215
      Linus Torvalds authored
      * 'btrfs' of git://git.kernel.dk/linux-2.6-block:
        btrfs: fix inode rbtree corruption
      b57f9215
    • Linus Torvalds's avatar
      x86: don't call '->send_IPI_mask()' with an empty mask · b04e6373
      Linus Torvalds authored
      As noted in 83d349f3 ("x86: don't send
      an IPI to the empty set of CPU's"), some APIC's will be very unhappy
      with an empty destination mask.  That commit added a WARN_ON() for that
      case, and avoided the resulting problem, but didn't fix the underlying
      reason for why those empty mask cases happened.
      
      This fixes that, by checking the result of 'cpumask_andnot()' of the
      current CPU actually has any other CPU's left in the set of CPU's to be
      sent a TLB flush, and not calling down to the IPI code if the mask is
      empty.
      
      The reason this started happening at all is that we started passing just
      the CPU mask pointers around in commit 4595f962 ("x86: change
      flush_tlb_others to take a const struct cpumask"), and when we did that,
      the cpumask was no longer thread-local.
      
      Before that commit, flush_tlb_mm() used to create it's own copy of
      'mm->cpu_vm_mask' and pass that copy down to the low-level flush
      routines after having tested that it was not empty.  But after changing
      it to just pass down the CPU mask pointer, the lower level TLB flush
      routines would now get a pointer to that 'mm->cpu_vm_mask', and that
      could still change - and become empty - after the test due to other
      CPU's having flushed their own TLB's.
      
      See
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13933
      
      for details.
      Tested-by: default avatarThomas Björnell <thomas.bjornell@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b04e6373
    • Linus Torvalds's avatar
      Make bitmask 'and' operators return a result code · f4b0373b
      Linus Torvalds authored
      When 'and'ing two bitmasks (where 'andnot' is a variation on it), some
      cases want to know whether the result is the empty set or not.  In
      particular, the TLB IPI sending code wants to do cpumask operations and
      determine if there are any CPU's left in the final set.
      
      So this just makes the bitmask (and cpumask) functions return a boolean
      for whether the result has any bits set.
      
      Cc: stable@kernel.org (2.6.30, needed by TLB shootdown fix)
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f4b0373b
    • Linus Torvalds's avatar
      x86: don't send an IPI to the empty set of CPU's · 83d349f3
      Linus Torvalds authored
      The default_send_IPI_mask_logical() function uses the "flat" APIC mode
      to send an IPI to a set of CPU's at once, but if that set happens to be
      empty, some older local APIC's will apparently be rather unhappy.  So
      just warn if a caller gives us an empty mask, and ignore it.
      
      This fixes a regression in 2.6.30.x, due to commit 4595f962 ("x86:
      change flush_tlb_others to take a const struct cpumask"), documented
      here:
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13933
      
      which causes a silent lock-up.  It only seems to happen on PPro, P2, P3
      and Athlon XP cores.  Most developers sadly (or not so sadly, if you're
      a developer..) have more modern CPU's.  Also, on x86-64 we don't use the
      flat APIC mode, so it would never trigger there even if the APIC didn't
      like sending an empty IPI mask.
      Reported-by: default avatarPavel Vilim <wylda@volny.cz>
      Reported-and-tested-by: default avatarThomas Björnell <thomas.bjornell@gmail.com>
      Reported-and-tested-by: default avatarMartin Rogge <marogge@onlinehome.de>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      83d349f3
    • From: Nick Piggin's avatar
      btrfs: fix inode rbtree corruption · 03e860bd
      From: Nick Piggin authored
      Node may not be inserted over existing node. This causes inode tree
      corruption and I was seeing crashes in inode_tree_del which I can not
      reproduce after this patch.
      
      The other way to fix this would be to tie inode lifetime in the rbtree
      with inode while not in freeing state. I had a look at this but it is
      not so trivial at this point. At least this patch gets things working again.
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Cc: Chris Mason <chris.mason@oracle.com>
      Acked-by: default avatarYan Zheng <zheng.yan@oracle.com>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      03e860bd
  2. 20 Aug, 2009 6 commits
  3. 19 Aug, 2009 14 commits
  4. 18 Aug, 2009 15 commits