Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp608440ybe; Thu, 19 Sep 2019 00:28:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqweYRP9XuWAg/XozS+LH5/6trAi0RtRSWtzqo3DUM1VJW6mU+TE9nhjtv1Ky/+36O1OObX6 X-Received: by 2002:aa7:c614:: with SMTP id h20mr2208893edq.209.1568878132786; Thu, 19 Sep 2019 00:28:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568878132; cv=none; d=google.com; s=arc-20160816; b=BB1fDSjbTGDxkmwloFENWtSNaeBpIvx2mvatATTtwXD1RX7Kct2uiQJWSSNJCm9I7E hIETFp5ja/CM89Xz68c1RaA6id54qCRThMrzNN1RyPMKScPxMFHHDo2PL9iqgrwLhxFV DNCNhVeXZkzFh41LlaeToC+7M95At/uqzq+SOhqh/Meae943yv6KNm3FNndo7cYHNExS rl0pX2qqaGluHc50DblnYxR2IGoyxk5xzHSfw/XbvGIiCSa33h5R2PQUtp64dilBY0DN Ve7W0zD0sVKJhqRs/ZqzYydAYIzFSPqlpos1SfptCZ2IqHqWifHqZdW/7IeAzOS9fTYB K74Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=e3JFXpoTZ+9fT9zPp8D903TN9jzlIUcKNpdyRvz8n9k=; b=ajx9LndwPrC8AYaWp44GHXBfZZaZ584Hk01EBkk/itiahsOyh5Mgq07cKUnUSq9v6/ z4vP9XUc4dEYi0NxKnj5aMZ/UkoGpWFgAyZt4/OMmn4tTu9vpzffsryhnmFwrKGEwRAD Cv7cN6OjLxASAfbjLqJw2I8W2F0yynukePvuNxH8XVMj3pTlp5nl3tE2QUB4nwzH4ezE 2DEMllG6mknlUbcKoqFQsP8dwAvQL5Kjpif0M5Upjhm4bfAJo5UC4CPoGkfjuHts3yBg QuvODhrJ6Frp6050lxOawDU6Akspr++Hd9aMC0T9qe6bIDEXvKwAKaxP7YCpZvQ5fezP K2Wg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j18si4038646ejv.201.2019.09.19.00.28.17; Thu, 19 Sep 2019 00:28:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726142AbfISGOt (ORCPT + 99 others); Thu, 19 Sep 2019 02:14:49 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:2733 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725320AbfISGOt (ORCPT ); Thu, 19 Sep 2019 02:14:49 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 1954AB99B21F0921EAFE; Thu, 19 Sep 2019 14:14:47 +0800 (CST) Received: from localhost.localdomain (10.175.124.28) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.439.0; Thu, 19 Sep 2019 14:14:38 +0800 From: yangerkun To: , CC: , , , Subject: [PATCH v2] ext4: fix a bug in ext4_wait_for_tail_page_commit Date: Thu, 19 Sep 2019 14:35:08 +0800 Message-ID: <20190919063508.1045-1-yangerkun@huawei.com> X-Mailer: git-send-email 2.17.2 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.124.28] X-CFilter-Loop: Reflected Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org No need to wait for any commit once the page is fully truncated. Besides, it may confuse e.g. concurrent ext4_writepage() with the page still be dirty (will be cleared by truncate_pagecache() in ext4_setattr()) but buffers has been freed; and then trigger a bug show as below: [ 26.057508] ------------[ cut here ]------------ [ 26.058531] kernel BUG at fs/ext4/inode.c:2134! ... [ 26.088130] Call trace: [ 26.088695] ext4_writepage+0x914/0xb28 [ 26.089541] writeout.isra.4+0x1b4/0x2b8 [ 26.090409] move_to_new_page+0x3b0/0x568 [ 26.091338] __unmap_and_move+0x648/0x988 [ 26.092241] unmap_and_move+0x48c/0xbb8 [ 26.093096] migrate_pages+0x220/0xb28 [ 26.093945] kernel_mbind+0x828/0xa18 [ 26.094791] __arm64_sys_mbind+0xc8/0x138 [ 26.095716] el0_svc_common+0x190/0x490 [ 26.096571] el0_svc_handler+0x60/0xd0 [ 26.097423] el0_svc+0x8/0xc Run the procedure (generate by syzkaller) parallel with ext3. void main() { int fd, fd1, ret; void *addr; size_t length = 4096; int flags; off_t offset = 0; char *str = "12345"; fd = open("a", O_RDWR | O_CREAT); assert(fd >= 0); /* Truncate to 4k */ ret = ftruncate(fd, length); assert(ret == 0); /* Journal data mode */ flags = 0xc00f; ret = ioctl(fd, _IOW('f', 2, long), &flags); assert(ret == 0); /* Truncate to 0 */ fd1 = open("a", O_TRUNC | O_NOATIME); assert(fd1 >= 0); addr = mmap(NULL, length, PROT_WRITE | PROT_READ, MAP_SHARED, fd, offset); assert(addr != (void *)-1); memcpy(addr, str, 5); mbind(addr, length, 0, 0, 0, MPOL_MF_MOVE); } And the bug will be triggered once we seen the below order. reproduce1 reproduce2 ... | ... truncate to 4k | change to journal data mode | | memcpy(set page dirty) truncate to 0: | ext4_setattr: | ... | ext4_wait_for_tail_page_commit | | mbind(trigger bug) truncate_pagecache(clean dirty)| ... ... | mbind will call ext4_writepage() since the page still be dirty, and then report the bug since the buffers has been free. Fix it by return directly once offset equals to 0 which means the page has been fully truncated. Reported-by: Hulk Robot Signed-off-by: yangerkun --- fs/ext4/inode.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 006b7a2070bf..db273d23dfba 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -5475,11 +5475,15 @@ static void ext4_wait_for_tail_page_commit(struct inode *inode) offset = inode->i_size & (PAGE_SIZE - 1); /* - * All buffers in the last page remain valid? Then there's nothing to - * do. We do the check mainly to optimize the common PAGE_SIZE == - * blocksize case + * If the page is fully truncated, we don't need to wait for any commit + * (and we even should not as __ext4_journalled_invalidatepage() may + * strip all buffers from the page but keep the page dirty which can then + * confuse e.g. concurrent ext4_writepage() seeing dirty page without + * buffers). Also we don't need to wait for any commit if all buffers in + * the page remain valid. This is most beneficial for the common case of + * blocksize == PAGESIZE. */ - if (offset > PAGE_SIZE - i_blocksize(inode)) + if (!offset || offset > (PAGE_SIZE - i_blocksize(inode))) return; while (1) { page = find_lock_page(inode->i_mapping, -- 2.17.2