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  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)" <>
To:     Jan Kara <>, "Theodore Y. Ts'o" <>
CC:     <>, <>,
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

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 ?


Powered by blists - more mailing lists