linux-ext4 - Re: [PATCH 2/4] ext4: fix deadlock between inline_data and ext4_expand_extra_isize

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: <20170125013248.lmxkc4ruh66o4p7b@thunk.org>
Date:   Tue, 24 Jan 2017 20:32:48 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Jan Kara <jack@...e.cz>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>,
        linux@...encehorizons.net, stable@...r.kernel.org, #@...nk.org
Subject: Re: [PATCH 2/4] ext4: fix deadlock between inline_data and
 ext4_expand_extra_isize_ea()

On Tue, Jan 24, 2017 at 01:27:22PM +0100, Jan Kara wrote:
> I see, thanks for explanation. Well seeing all these problems with
> ext4_expand_extra_isize() wouldn't we be better off by not calling it from
> ext4_mark_inode_dirty() but rather explicitely from several well-defined
> places? Because this implicit calling looks like it causes us too much
> trouble.

Yeah, I suppose that might be a better way to go.  We could only do it
on a file open, perhaps.  It might not be as important it is to expand
the extra_isize on, say, a chmod, for example.

It's certainly worth looking to see whether it would simplify things
to go that way.

					- Ted