linux-ext4 - Re: [RFC] inode.i_opflags - Usage of two different locking schemes

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: <0e308673-a350-98af-b0a7-cde63abd4579@tu-dortmund.de>
Date:   Fri, 26 Mar 2021 17:37:34 +0100
From:   Alexander Lochmann <alexander.lochmann@...dortmund.de>
To:     Jan Kara <jack@...e.cz>
Cc:     "Theodore Ts'o" <tytso@....edu>,
        Horst Schirmeier <horst.schirmeier@...dortmund.de>,
        Jan Kara <jack@...e.com>, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] inode.i_opflags - Usage of two different locking schemes



On 16.03.21 18:14, Jan Kara wrote:
> 
> So i_lock is supposed to protect i_opflags for writing AFAICT. For reading
> we don't seem to bother in some cases and I agree that is potentially
> problematic. It is *mostly* OK because we initialize i_opflags when loading
> inode into memory / adding it to dcache. But sometimes we also update them
> while the inode is alive. Now this is fine for the particular flag we
> update but in theory, if the compiler wants to screw us and stores
> temporarily some nonsensical value in i_opflags we'd have a problem. This
> is mostly a theoretical issue but eventually we probably want to fix this.
> 
> 								Honza
> 
Thx for the detailed explanation. :-)

- Alex

-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al