comments inline, > 8 дек. 2016 г., в 5:32, Oleg Drokin <green@xxxxxxxxxxxxxx> написал(а): > > > On Nov 30, 2016, at 11:18 PM, Alexey Lyashkov wrote: > >> rehash process protected with d_seq and d_lock locks, but VFS have access to the >> d_hashed field without any locks sometimes. It produce errors with get cwd >> operations or fsnotify may report an unlink event sometimes. d_seq lock isn’t >> used to protect due possibility to sleep with holding locks, and d_lock is too >> hot to check a simple state, lets return a DCACHE_DENTRY_UNHASHED flag to >> ability to check a unhashed state without locks held. > > While Lustre-wise the patch is ok, I guess, > I wonder if the underlying idea is sound? > Lockless access is inherently racy, so if you replace the list check with just > a bit check, it's still racy, just the window is a bit smaller, no? > Or are you only concerned about d_move's very nonatomic unhash/rehash? > You are right. I concerned about d_move and non atomic rehash, but it not a decrease a race window. hashed flag live cycle it - dentry unhashed while don’t connected to the tree, but hashed until it dentry is valid (file isn’t unlinked) or dentry killed via low memory conditional and new lookup is needs. I guess, you talk about - how it will affect a lustre? it bug was discovered in lustre workstation previously. Lustre uses a d_move as part of lookup process to reuse an unprotected dentries to connect into dentry tree. get_cwd was confused in that time as threat a unhashed dentry as unlinked, who is correct from d_drop use case. Alexey-- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
