summaryrefslogtreecommitdiff
path: root/arch/s390
diff options
context:
space:
mode:
authorNick Piggin <npiggin@kernel.dk>2010-11-11 14:05:19 -0800
committerGreg Kroah-Hartman <gregkh@suse.de>2010-12-09 13:32:53 -0800
commit8301e7e3480ecabce25e116f1e6072b88f6167b4 (patch)
tree57b9e77164968c841822856787f617df771c1a39 /arch/s390
parentd033ce761865fec8580d394b1c13d60010cebead (diff)
radix-tree: fix RCU bug
commit 27d20fddc8af539464fc3ba499d6a830054c3bd6 upstream. Salman Qazi describes the following radix-tree bug: In the following case, we get can get a deadlock: 0. The radix tree contains two items, one has the index 0. 1. The reader (in this case find_get_pages) takes the rcu_read_lock. 2. The reader acquires slot(s) for item(s) including the index 0 item. 3. The non-zero index item is deleted, and as a consequence the other item is moved to the root of the tree. The place where it used to be is queued for deletion after the readers finish. 3b. The zero item is deleted, removing it from the direct slot, it remains in the rcu-delayed indirect node. 4. The reader looks at the index 0 slot, and finds that the page has 0 ref count 5. The reader looks at it again, hoping that the item will either be freed or the ref count will increase. This never happens, as the slot it is looking at will never be updated. Also, this slot can never be reclaimed because the reader is holding rcu_read_lock and is in an infinite loop. The fix is to re-use the same "indirect" pointer case that requires a slot lookup retry into a general "retry the lookup" bit. Signed-off-by: Nick Piggin <npiggin@kernel.dk> Reported-by: Salman Qazi <sqazi@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'arch/s390')
0 files changed, 0 insertions, 0 deletions