From patchwork Sat Apr 6 07:13:13 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Xiaoxu X-Patchwork-Id: 10888087 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 148F715AC for ; Sat, 6 Apr 2019 07:09:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D576F2857B for ; Sat, 6 Apr 2019 07:09:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C532728B79; Sat, 6 Apr 2019 07:09:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2FDF82857B for ; Sat, 6 Apr 2019 07:09:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726464AbfDFHJG (ORCPT ); Sat, 6 Apr 2019 03:09:06 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:35830 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725934AbfDFHJG (ORCPT ); Sat, 6 Apr 2019 03:09:06 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 67E9DF9E5D7211D795D6; Sat, 6 Apr 2019 15:09:03 +0800 (CST) Received: from RH5885H-V3.huawei.com (10.90.53.225) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.408.0; Sat, 6 Apr 2019 15:08:55 +0800 From: ZhangXiaoxu To: , , , , , , CC: Subject: [PATCH] fs/buffer.c: Fix data corruption when buffer write with IO error Date: Sat, 6 Apr 2019 15:13:13 +0800 Message-ID: <1554534793-31444-1-git-send-email-zhangxiaoxu5@huawei.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 X-Originating-IP: [10.90.53.225] X-CFilter-Loop: Reflected Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- fs/buffer.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/buffer.c b/fs/buffer.c index ce35760..9fe1827 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -172,7 +172,6 @@ void end_buffer_write_sync(struct buffer_head *bh, int uptodate) } else { buffer_io_error(bh, ", lost sync page write"); mark_buffer_write_io_error(bh); - clear_buffer_uptodate(bh); } unlock_buffer(bh); put_bh(bh); @@ -325,7 +324,6 @@ void end_buffer_async_write(struct buffer_head *bh, int uptodate) } else { buffer_io_error(bh, ", lost async page write"); mark_buffer_write_io_error(bh); - clear_buffer_uptodate(bh); SetPageError(page); }