On 08/13, Jan Kara wrote: > > On Wed 12-08-15 15:11:38, Oleg Nesterov wrote: > > On 08/11, Oleg Nesterov wrote: > > > > > > The only essential change is that I dropped the lockdep improvements > > > as we discussed. This means that 8/8 was changed a bit, and I decided > > > to add the new documentation patch, see 3/8. > > > > Update: The recent > > > > [PATCH 0/2] xfs: kill lockdep false positives from readdir > > > > changes from Dave fixed the problems ILOCK false-positives. So we can > > add the additional patch which (modulo comments) just turns v2 back into > > v1. > > > > Dave, Jan, you seem to agree with these patches. How should we route > > this all? > > Regarding the routing, ideally Al Viro should take these as a VFS > maintainer. OK. I'll send v3. But to remind, this particular patch depends on Dave's fixes, so I will send it later. And I forgot to mention that I have another patch which removes the trylock hack from __sb_start_write() as Dave suggested, it passed the tests. But again, I'd really like to send it separately so that it can be reverted in (unlikely) case something else does recursive read_lock(). > > Subject: [PATCH v2 9/8] don't fool lockdep in freeze_super() and thaw_super() paths > > > > sb_wait_write()->percpu_rwsem_release() fools lockdep to avoid the > > false-positives. Now that xfs was fixed by Dave we can remove it and > > change freeze_super() and thaw_super() to run with s_writers.rw_sem > > locks held; we add two trivial helpers for that, sb_freeze_release() > > and sb_freeze_acquire(). > > > > While at it, kill the outdated part of the comment above sb_wait_write. > > > > Signed-off-by: Oleg Nesterov <oleg@xxxxxxxxxx> > > The patch looks good. Just one nit: > > > + for (level = SB_FREEZE_LEVELS; --level >= 0; ) > > + percpu_rwsem_release(sb->s_writers.rw_sem + level, 0, _THIS_IP_); > > It is more common (and to me more readable) to have the loop written as: > > for (level = SB_FREEZE_LEVELS - 1; level >= 0; level--) > > I agree what you do is shorter but IMHO it's just an unnecessary > obfuscation :) Agreed, will fix. Oleg. -- 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
