On Mon, Nov 22, 2010 at 2:37 AM, Ted Ts'o <tytso@xxxxxxx> wrote: > On Mon, Nov 22, 2010 at 12:39:49AM +0900, Minchan Kim wrote: >> >> I think it's no problem. >> >> That's because migration always holds lock_page on the file page. >> So the page couldn't remove from radix. > > It may be "ok" in that it won't cause a race, but it still leaves an > unsightly warning if LOCKDEP is enabled, and LOCKDEP warnings will > cause /proc_lock_stat to be disabled. So I think it still needs to be > fixed by adding rcu_read_lock()/rcu_read_unlock() to > migrate_page_move_mapping(). > > - Ted > Yes. if it is really "ok" about race, we will add rcu_read_lock with below comment to prevent false positive. "suppress RCU lockdep false positives". But I am not sure it's good although rcu_read_lock is little cost. Whenever we find false positive, should we add rcu_read_lock to suppress although it's no problem in real product? Couldn't we provide following function? (or we might have already it but I missed it. ) /* * Suppress RCU lockdep false positive. */ #ifdef CONFIG_PROVE_RCU #define rcu_read_lock_suppress rcu_read_lock #else #define rcu_read_lock_suppress #endif -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href