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:	Thu, 7 Jul 2016 13:21:55 +0200
From:	Vegard Nossum <vegard.nossum@...cle.com>
To:	tytso@....edu
Cc:	linux-ext4@...r.kernel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: [PATCH] ext4: fix reference counting bug on block allocation
 error

On 07/06/2016 03:57 PM, Vegard Nossum wrote:
> If we hit this error when mounted with errors=continue or
> errors=remount-ro:
>
>      EXT4-fs error (device loop0): ext4_mb_mark_diskspace_used:2940: comm ext4.exe: Allocating blocks 5090-6081 which overlap fs metadata
>
> then ext4_mb_new_blocks() will call ext4_mb_release_context() and try to
> continue. However, ext4_mb_release_context() is the wrong thing to call
> here since we are still actually using the allocation context.
>
> Instead, handle it the same way that we handle other errors, except that
> we retry the allocation instead of immediately returning an error (if we
> were mounted with errors=continue, then ext4_mb_mark_diskspace_used()
> should have fixed the original error and will either succeed or give a
> different error; if we were mounted with errors=remount-ro, then it will
> not be able to fix the original error and will raise a different error).

This didn't really work as I thought and I'm now getting stuck in an
infinite loop here where it tries (and fails) to allocate the same
blocks over and over.

The attached new patch just returns on error instead of trying to fix
the problem.


Vegard

View attachment "0001-ext4-fix-reference-counting-bug-on-block-allocation-.patch" of type "text/x-patch" (1791 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ