Home
last modified time | relevance | path

Searched hist:"87 ef2bb4" (Results 1 – 2 of 2) sorted by relevance

/openbmc/linux/fs/btrfs/
H A Dtransaction.c87ef2bb4 Thu Oct 30 10:23:27 CDT 2008 Chris Mason <chris.mason@oracle.com> Btrfs: prevent looping forever in finish_current_insert and del_pending_extents

finish_current_insert and del_pending_extents process extent tree modifications
that build up while we are changing the extent tree. It is a confusing
bit of code that prevents recursion.

Both functions run through a list of pending operations and both funcs
add to the list of pending operations. If you have two procs in either
one of them, they can end up looping forever making more work for each other.

This patch makes them walk forward through the list of pending changes instead
of always trying to process the entire list. At transaction commit
time, we catch any changes that were left over.

Signed-off-by: Chris Mason <chris.mason@oracle.com>
87ef2bb4 Thu Oct 30 10:23:27 CDT 2008 Chris Mason <chris.mason@oracle.com> Btrfs: prevent looping forever in finish_current_insert and del_pending_extents

finish_current_insert and del_pending_extents process extent tree modifications
that build up while we are changing the extent tree. It is a confusing
bit of code that prevents recursion.

Both functions run through a list of pending operations and both funcs
add to the list of pending operations. If you have two procs in either
one of them, they can end up looping forever making more work for each other.

This patch makes them walk forward through the list of pending changes instead
of always trying to process the entire list. At transaction commit
time, we catch any changes that were left over.

Signed-off-by: Chris Mason <chris.mason@oracle.com>
H A Dextent-tree.c87ef2bb4 Thu Oct 30 10:23:27 CDT 2008 Chris Mason <chris.mason@oracle.com> Btrfs: prevent looping forever in finish_current_insert and del_pending_extents

finish_current_insert and del_pending_extents process extent tree modifications
that build up while we are changing the extent tree. It is a confusing
bit of code that prevents recursion.

Both functions run through a list of pending operations and both funcs
add to the list of pending operations. If you have two procs in either
one of them, they can end up looping forever making more work for each other.

This patch makes them walk forward through the list of pending changes instead
of always trying to process the entire list. At transaction commit
time, we catch any changes that were left over.

Signed-off-by: Chris Mason <chris.mason@oracle.com>