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:	Mon, 07 Dec 2009 14:39:44 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Josef Bacik <josef@...hat.com>
CC:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] Ext4: wait for log to commit when putting super

Josef Bacik wrote:
> On Mon, Dec 07, 2009 at 02:26:21PM -0600, Eric Sandeen wrote:
>> Josef Bacik wrote:
>>> There is a problem where a transaction will be committing while we're unmounting
>>> the filesystem and you will get a panic because EXT4_SB(sb)->s_group_info has
>>> been kfree'ed in ext4_put_super.  The commit code does the callback for the
>>> mballoc stuff to release free'ed blocks in the transaction and panic's trying to
>>> access s_group_info.  The fix is to wait for the transaction to finish
>>> committing before we start cleaning up the mballoc stuff.  This patch hasn't
>>> been tested yet, but its an obvious fix.
>> Hm, doesn't jbd2_journal_destroy already do that, but we just
>> call it -after- we've done ext4_mb_release which leads to freeing
>> EXT4_SB(sb)->s_group_info ?
>>
>> Can we just do jbd2_journal_destroy() earlier before we tear
>> down things it may depend on?
>>
> 
> That seems reasonable.  We do
> 
>         ext4_release_system_zone(sb);
>         ext4_mb_release(sb);
>         ext4_ext_release(sb);
>         ext4_xattr_put_super(sb);
> 
> before the journal_destroy, and all thats doing is cleaning up our internal
> stuff.  If we want to keep it close to what ext3 does we can just move
> 
>         ext4_release_system_zone(sb);
>         ext4_mb_release(sb);
>         ext4_ext_release(sb);
> 
> under the journal_destroy or just move the journal destroy above all of that
> stuff.  Whichever you prefer.  Thanks,

I guess it doesn't matter much to me, I just preferred rearranging
teardown order to adding more logic that I think is already taken care
of in the jbd2_journal_destroy call ..

Thanks for finding this! :)

-Eric

> Josef

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ