linux-ext4 - Re: [PATCH] ext4: restart ext4_ext_remove

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]

Date:	Tue, 25 May 2010 09:55:11 -0400
From:	tytso@....edu
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:	linux-ext4@...r.kernel.org, jack@...e.cz,
	aneesh.kumar@...ux.vnet.ibm.com, tytso@....ed
Subject: Re: [PATCH] ext4: restart ext4_ext_remove_space() after
 transaction restart

On Thu, Apr 22, 2010 at 08:31:11AM +0400, Dmitry Monakhov wrote:
> If i_data_sem was internally dropped due to transaction restart, it is
> necessary to restart path look-up because extents tree was possibly
> modified by ext4_get_block().
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=15827
> 
> Signed-off-by: Dmitry Monakhov <dmonakhov@...nvz.org>

I *think* it would be more efficient to add the additional change:

  	  if (ext4_ext_more_to_rm(path + i)) {

to:

  	  if ((err != -EAGAIN) && ext4_ext_more_to_rm(path + i)) {

in ext4_ext_remove_space() but I would like your opinion...

If we do this optimization I'll probably do it in a separate patch.
It just seems that we're doing a lot of extra work once we fail to
extend the transaction, so it would be good to optimize more of this
out.  It also makes it easier to convince oneself that that all of the
spinning around that happens after returning EAGAIN won't cause any
harm.  After going through the patch carefully I'm pretty sure the
extra work is pointless, but not harmful, but it's better to skip it
entirely if it's not needed.

					 - Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html