On 09/27, Jan Kara wrote: > > On Mon 26-09-16 18:55:25, Oleg Nesterov wrote: > > > > Heh ;) if only I knew how to test this... I ran the following script > > under qemu > > > > mkfs.xfs -f /dev/vda > > mkfs.xfs -f /dev/vdb > > > > mkdir -p TEST SCRATCH > > > > TEST_DEV=/dev/vda TEST_DIR=TEST SCRATCH_DEV=/dev/vdb SCRATCH_MNT=SCRATCH \ > > ./check `grep -il freeze tests/*/???` > > You can run either: > > ./check -g freeze passed all 6 tests. > to check just the freezing tests or > > ./check > > to run all sensible tests which is what I'd do (but it will take couple of > hours to pass). If that passes, chances are good there are no easy false > positives. It seems that generic/001 just hangs on my laptop. With or without this change. Or perhaps I didn't wait enough... Or perhaps something is wrong with my very limited testing environment. I'll reserve a testing machine tomorrow. > > And yes, I'm afraid this change can uncover some false positives later. > > But at the same time potentially it can find the real problems. > > Well, sure it's not an end of world if there is some false positive - we > can just revert the change - but lockdep false positives are always > annoying because they take time to analyze and until they are fixed, you > are unable to see other probles found by lockdep... Yes, yes, agreed. > > It would be nice to remove another hack in __sb_start_write under > > ifdef(CONFIG_LOCKDEP), but iirc XFS actually takes the same rw_sem twice > > for reading, so we can't do this. > > Yes, and I don't really consider this a hack. Ah, sorry, I didn't try to blame XFS/fs. I meant, this "force_trylock" hack doesn't look nice. Perhaps we can use rwsem_acquire_nest() instead. > Reviewed-by: Jan Kara <jack@xxxxxxx> Thanks! 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
