On Tue, Jul 14, 2015 at 12:42:37AM +0200, Oleg Nesterov wrote: > On 07/14, Dave Chinner wrote: > > > > [ Please cc linux-fsdevel@xxxxxxxxxxxxxxx on filesystem > > infrastructure changes! ] > > OK, will do. > > > On Mon, Jul 13, 2015 at 11:25:36PM +0200, Oleg Nesterov wrote: > > > > > > - sb_lockdep_release() and sb_lockdep_acquire() play with > > > percpu_rw_semaphore's internals. > > > > > > Trivial, we need a couple of new helper in percpu-rwsem.c. > > > > - try compiling XFS, watch it break on freeze lockdep > > annotations > > Thanks a lot! I see. Still trivial, xfs can use the same helpers > rather the abuse lockdep directly. > > > > - Most probably I missed something else, and I do not need > > > how to test. > > > > xfstests has many freeze related stress tests. IIRC, generic/068 is > > the test that historically causes the most problems for freeze > > infrastructure changes. You'll also need to test at least ext4, XFS > > and btrfs, because they all stress the freeze code differently. > > Testing XFS, in particular, is a good idea because it has several > > custom freeze tests that aren't run on any other filesystem type. > > Thanks again. > > Do you see something fundamentally wrong with this change? I haven't looked particularly closely at the implementation, just enough to get an idea of the semantics of the new infrasructure (I didn't know that per-cpu rwsems existed!). The freeze code is essentially a multi-level read-optimised read/write barrier and AFAICT the per-cpu rw-sem has those semantics. From that perspective I don't see any fundamental problems, but there may be details that I've missed.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
