linux-ext4 - Re: [PATCH 00/10] ext4: fix inconsistency since reading old metadata from disk

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Jun 2020 10:12:45 +0800
From:   "zhangyi (F)" <yi.zhang@...wei.com>
To:     Jan Kara <jack@...e.cz>, "Theodore Y. Ts'o" <tytso@....edu>
CC:     <linux-ext4@...r.kernel.org>, <adilger.kernel@...ger.ca>,
        <zhangxiaoxu5@...wei.com>
Subject: Re: [PATCH 00/10] ext4: fix inconsistency since reading old metadata
 from disk

On 2020/6/11 0:27, Jan Kara wrote:
> On Wed 10-06-20 11:45:43, Theodore Y. Ts'o wrote:
>> On Wed, Jun 10, 2020 at 11:57:39AM +0200, Jan Kara wrote:
>>>> So I guess it may still lead to inconsistency. How about add this checking
>>>> into ext4_journal_get_write_access() ?
>>>
>>> Yes, this also occured to me later. Adding the check to
>>> ext4_journal_get_write_access() should be safer.
>>
>> There's another thing which we could do.  One of the issues is that we
>> allow buffered writeback for block devices once the change to the
>> block has been committed.  What if we add a change to block device
>> writeback code and in fs/buffer.c so that optionally, the file system
>> can specify a callback function can get called when an I/O error has
>> been reflected back up from the block layer?
>>
>> It seems unfortunate that currently, we can immediately report the I/O
>> error for buffered writes to *files*, but for metadata blocks, we
>> would only be able to report the problem when we next try to modify
>> it.
>>
>> Making changes to fs/buffer.c might be controversial, but I think it
>> might be result in a better solution.
> 
> Yeah, what you propose certainly makes sence could be relatively easily
> done by blkdev_writepage() using __block_write_full_page() with appropriate
> endio handler which calls fs callback. I'm just not sure how propagate the
> callback function from the fs to the blkdev...
>

I have thought about this solution, we could add a hook in 'struct super_operations'
and call it in blkdev_writepage() like blkdev_releasepage() does, and pick out a
wrapper from block_write_full_page() to pass our endio handler in, something like
this.

static const struct super_operations ext4_sops = {
...
	.bdev_write_page = ext4_bdev_write_page,
...
};

static int blkdev_writepage(struct page *page, struct writeback_control *wbc)
{
	struct super_block *super = BDEV_I(page->mapping->host)->bdev.bd_super;

	if (super && super->s_op->bdev_write_page)
		return super->s_op->bdev_write_page(page, blkdev_get_block, wbc);

	return block_write_full_page(page, blkdev_get_block, wbc);
}

But I'm not sure it's a optimal ieda. So I continue to realize the "wb_err"
solution now ?

Thanks,
Yi.