linux-kernel - Re: linux-next: manual merge of the vfs-brauner tree with the djw-vfs tree

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] [day] [month] [year] [list]

Message-ID: <20230823-wuseln-adrett-2b10dfcb3dee@brauner>
Date:   Wed, 23 Aug 2023 09:44:49 +0200
From:   Christian Brauner <brauner@...nel.org>
To:     "Darrick J. Wong" <djwong@...nel.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the vfs-brauner tree with the
 djw-vfs tree

> Hmm.  Looking at the {up,down}_write -> super_{un,}lock_excl conversion,
> I think you missed wait_for_partially_frozen:

Maha, I sure did. Thanks, converted as well.

> That said, freeze_super() took an s_active refcount at the top, called
> super_lock_excl (which means the sb isn't DYING and has been BORN) and
> doesn't release it before calling wait_for_partially_frozen.

Yes.

> AFAICT, the subsequent down_write -> super_lock_excl conversions in
> freeze_super do not gain us much since I don't think the sb can get to
> SB_DYING state without s_active reaching zero, right?  According to

Yes, if you have an active reference count the superblock stays alive.
If it ever gets into SB_DYING we have a bug.

> The missing conversion isn't strictly necessary, but it probably makese
> sense to do it anyway.

I did. Thanks for pointing that out!

> (Aside from that, the conversion looks correct to me.)

Thanks!