Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "zhangxiaoxu (A)" <zhangxiaoxu5@huawei.com>
Subject: Re: [PATCH] fs/buffer.c: Fix data corruption when buffer write with
 IO error
To:     Jan Kara <jack@suse.cz>
CC:     <viro@zeniv.linux.org.uk>, <tytso@mit.edu>,
        <adilger.kernel@dilger.ca>, <linux-fsdevel@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux-ext4@vger.kernel.org>,
        <yi.zhang@huawei.com>
References: <1554534793-31444-1-git-send-email-zhangxiaoxu5@huawei.com>
 <20190408111108.GB18662@quack2.suse.cz>
Message-ID: <cdc7faed-20a0-4024-9405-ab74d7d18ab8@huawei.com>
Date:   Tue, 9 Apr 2019 21:11:22 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <20190408111108.GB18662@quack2.suse.cz>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 4/8/2019 7:11 PM, Jan Kara wrote:
> On Sat 06-04-19 15:13:13, ZhangXiaoxu wrote:
>> When the buffer write failed, 'end_buffer_write_sync' and
>> 'end_buffer_async_write' will clear the uptodate flag. But the
>> data in the buffer maybe newer than disk. In some case, this
>> will lead data corruption.
>>
>> For example: ext4 flush metadata to disk failed, it will clear
>> the uptodate flag. when a new coming call want the buffer, it will
>> read it from the disk(because the buffer no uptodate flag). But
>> the journal not checkpoint now, it will read old data from disk.
>> If read successfully, ext4 will write the old data to the new
>> journal, the data will corruption.
>>
>> So, don't clear the uptodate flag when write the buffer failed.
>>
>> Signed-off-by: ZhangXiaoxu<zhangxiaoxu5@huawei.com>
> Thanks for the patch. But what are the chances that after the write has
> failed the read will succeed? Also there were places that were using
> buffer_uptodate() to detect IO errors. Did you check all those got
> converted to using buffer_write_io_error() instead?
> 
> 								Honza
> 
I encountered this situation when using iscsi target as the ext4 volume,
if the network down a while when ext4 write metadata to disk, and maybe
read will success after the network recovered.
In my testcase, just create and delete files, when disconnect the network,
the dir entry maybe corruption. I add some logs when read entry buffer from
disk, the buffer stats maybe buffer_write_io_error() and !buffer_uptodate().
In this case, the ext4 will corruption high probability. Because the buffer
is read from disk, and some newer information just on journal. In this case,
we should not read buffer from the disk.

I don't know any other filesystem how to use the uptodate flag. But I think
uptodate means the buffer is valid and newer than disk, am I right?

I just test ext4 use the xfstest.

Any other idea about my problem?