Skip to content

L
linux
Switch branch/tag
  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
  3. 20 Aug, 2009 6 commits
  5. 19 Aug, 2009 14 commits
  7. 18 Aug, 2009 15 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7