[lkml]   [2016]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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
> >
> > ./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 <>



 \ /
  Last update: 2016-09-27 19:29    [W:0.046 / U:3.272 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site