linux-kernel - Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and thaw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160927172901.GA11879@redhat.com>
Date:   Tue, 27 Sep 2016 19:29:01 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Dave Chinner <david@...morbit.com>,
        Nikolay Borisov <kernel@...p.com>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
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@...e.cz>

Thanks!

Oleg.