On Wed, 2007-10-03 at 22:59 +0900, Tetsuo Handa wrote: > Hello. > > KaiGai Kohei wrote: > > If so, you can apply RCU instead to avoid read lock > > when scanning the list, like: > > > > rcu_read_lock(); > > list_for_each_entry(...) { > > .... > > } > > rcu_read_unlock(); > > Can I sleep between rcu_read_lock() and rcu_read_unlock() ? > As far as I saw, rcu_read_lock() makes in_atomic() true, so I think I can't > sleep. > > If I use RCU, I have to give up " [TOMOYO 13/15] Conditional permission > support" > because tmy_check_condition() can sleep.
You can indeed not sleep in an rcu_read_lock() section. However, you could grab a reference on an item, stop the iteration, drop rcu_read_lock. Do you thing, re-acquire rcu_read_lock(), drop the ref, and continue the iteration. Also, how do you avoid referencing dead data with your sll? I haven't actually looked at your patches, but the simple scheme you outlined didn't handle the iteration + concurrent removal scenario: thread 1 thread 2 foo = ptr->next < schedule > killme = ptr->next (same item) ptr->next = ptr->next->next; kfree(killme) < schedule > foo->bar <-- *BANG* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/