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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 10 Jun 2020 18:27:15 +0200 From: Jan Kara <jack@...e.cz> To: "Theodore Y. Ts'o" <tytso@....edu> Cc: Jan Kara <jack@...e.cz>, "zhangyi (F)" <yi.zhang@...wei.com>, 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 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... Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists