Messages in this thread | | | Date | Tue, 27 Sep 2016 19:29:01 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and thaw_super() paths |
| |
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@suse.cz>
Thanks!
Oleg.
| |