Skip to contentSkip to conversation

radix-tree: document wrap-around issue of radix_tree_next_hole()

PATCH In review Wu Fengguang 2 participants 3 messages Nov 23, 2008 – Nov 27, 2008

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 radix-tree: document wrap-around issue of radix_tree_next_hole()

And some 80-line cleanups.

---
 lib/radix-tree.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
lib/radix-tree.c +6 -5
@@ -640,13 +640,14 @@ EXPORT_SYMBOL(radix_tree_tag_get);
  *
  *	Returns: the index of the hole if found, otherwise returns an index
  *	outside of the set specified (in which case 'return - index >= max_scan'
- *	will be true).
+ *	will be true). In rare cases of index wrap-around, 0 will be returned.
  *
  *	radix_tree_next_hole may be called under rcu_read_lock. However, like
- *	radix_tree_gang_lookup, this will not atomically search a snapshot of the
- *	tree at a single point in time. For example, if a hole is created at index
- *	5, then subsequently a hole is created at index 10, radix_tree_next_hole
- *	covering both indexes may return 10 if called under rcu_read_lock.
+ *	radix_tree_gang_lookup, this will not atomically search a snapshot of
+ *	the tree at a single point in time. For example, if a hole is created
+ *	at index 5, then subsequently a hole is created at index 10,
+ *	radix_tree_next_hole covering both indexes may return 10 if called
+ *	under rcu_read_lock.
  */
 unsigned long radix_tree_next_hole(struct radix_tree_root *root,
 				unsigned long index, unsigned long max_scan)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#1 lore raw
Quoted 20 lines · Wu Fengguang

And some 80-line cleanups.

---
 lib/radix-tree.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
lib/radix-tree.c +1 -3
@@ -640,13 +640,14 @@ EXPORT_SYMBOL(radix_tree_tag_get);
  *
  *	Returns: the index of the hole if found, otherwise returns an index
  *	outside of the set specified (in which case 'return - index >= max_scan'
- *	will be true).
+ *	will be true). In rare cases of index wrap-around, 0 will be returned.
  *
  *	radix_tree_next_hole may be called under rcu_read_lock. However, like
- *	radix_tree_gang_lookup, this will not atomically search a snapshot of the
- *	tree at a single point in time. For example, if a hole is created at index

lib/radix-tree.c EXPORT_SYMBOL(radix_tree_tag_get); · line 653

Quoted 10 lines
lib/radix-tree.c +5 -2
- *	5, then subsequently a hole is created at index 10, radix_tree_next_hole
- *	covering both indexes may return 10 if called under rcu_read_lock.
+ *	radix_tree_gang_lookup, this will not atomically search a snapshot of
+ *	the tree at a single point in time. For example, if a hole is created
+ *	at index 5, then subsequently a hole is created at index 10,
+ *	radix_tree_next_hole covering both indexes may return 10 if called
+ *	under rcu_read_lock.
  */
 unsigned long radix_tree_next_hole(struct radix_tree_root *root,
 				unsigned long index, unsigned long max_scan)

I don't see this applied in any of the publically visible trees, so I have taken this into -trivial. Please let me know if it has been through any other channel already.

Thanks,

Signature · 8 lines
Jiri Kosina
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#2 lore raw
Quoted 28 lines · Jiri Kosina
Quoted 26 lines · Wu Fengguang

And some 80-line cleanups.

---
 lib/radix-tree.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
lib/radix-tree.c +6 -5
@@ -640,13 +640,14 @@ EXPORT_SYMBOL(radix_tree_tag_get);
  *
  *	Returns: the index of the hole if found, otherwise returns an index
  *	outside of the set specified (in which case 'return - index >= max_scan'
- *	will be true).
+ *	will be true). In rare cases of index wrap-around, 0 will be returned.
  *
  *	radix_tree_next_hole may be called under rcu_read_lock. However, like
- *	radix_tree_gang_lookup, this will not atomically search a snapshot of the
- *	tree at a single point in time. For example, if a hole is created at index
- *	5, then subsequently a hole is created at index 10, radix_tree_next_hole
- *	covering both indexes may return 10 if called under rcu_read_lock.
+ *	radix_tree_gang_lookup, this will not atomically search a snapshot of
+ *	the tree at a single point in time. For example, if a hole is created
+ *	at index 5, then subsequently a hole is created at index 10,
+ *	radix_tree_next_hole covering both indexes may return 10 if called
+ *	under rcu_read_lock.
Quoted 8 lines

lib/radix-tree.c EXPORT_SYMBOL(radix_tree_tag_get); · line 653

Quoted 4 lines
lib/radix-tree.c +0 -0
  */
 unsigned long radix_tree_next_hole(struct radix_tree_root *root,
 				unsigned long index, unsigned long max_scan)

I don't see this applied in any of the publically visible trees, so I have taken this into -trivial. Please let me know if it has been through any other channel already.

OK, thank you.

Fengguang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>