Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp212105ybv; Wed, 12 Feb 2020 22:39:59 -0800 (PST) X-Google-Smtp-Source: APXvYqyD0BxpFo6Dmes9QN+4pKvGBzu4piEHle7YYPo429kqH6riFlwaRVx1A8KDss99ntQYPDzd X-Received: by 2002:a05:6830:1289:: with SMTP id z9mr12608537otp.317.1581575999762; Wed, 12 Feb 2020 22:39:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581575999; cv=none; d=google.com; s=arc-20160816; b=HmF/WvBN2pusXYVWqVIoHefHfJKt+ilqMHJlilWQNHejIw9C5QRHNhCjHim/trzWWu XA/tMMaxraReh/fw6OYR+xpMgwci7TCZvyUBOCRrp/Cor+hoayDQPN0ZuWFBHkZC38rN jgKjAFHEVEe+1aHMc52XvcdMAz1iEsdOfuTW7x1Ty4agB3MPk47DygC/a5EB9vmrBI4b EQqSpb4x7ZdzcPpkDRDwfI5RB/7ykI9CryVtict0Q2rMGsWxgMvPUf7uWKrjf75zWHnX kYGeFK6g7kcK/j//Y+2GT892MOa2iFakKI1GwBVaCzn4QoXGeP2ijPZ8PgyUrK8qVQF9 os9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=lwtJMezj67H5pf+YApQj1j9m6AOO0k4BjS6uDg0ySD0=; b=xc1OL2uNWsOwzxNAdB+zIdnp3hJk7A8Q4kCm8KElS/hggZQrIXOS/Ynp0NCM9jltkE hh2A6RR4+htAlXCUCvcRu8f06HIgv1mlXBfriaxdCdosYAlFxH4j2GTVXNanbYxh040d t6BLWuibTTnsD2J7O6cmNU7uClRS3UQm1EGNUUzhZzpQUPEZBOw971viTAET0b9i9cgD PbKQcjVag4KK3QAGZ6dz5Hfj4zar8+8irPxS05z8kIW1iZee4bXeMJ+5IKecC9rPYps0 SAHoki4Sy7TBRVVLO+lnD/8XArCCeexCIisKEf0U3KIbEW3oE+jeYg+THHyIA+KWv5SA eIVw== 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 b21si903719ots.38.2020.02.12.22.39.41; Wed, 12 Feb 2020 22:39:59 -0800 (PST) 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 S1727123AbgBMGjh (ORCPT + 99 others); Thu, 13 Feb 2020 01:39:37 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:9729 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729383AbgBMGjh (ORCPT ); Thu, 13 Feb 2020 01:39:37 -0500 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 50EF229A9E062636A5FA; Thu, 13 Feb 2020 14:39:34 +0800 (CST) Received: from huawei.com (10.175.124.28) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.439.0; Thu, 13 Feb 2020 14:39:26 +0800 From: "zhangyi (F)" To: , CC: , , , Subject: [PATCH v3 2/2] jbd2: do not clear the BH_Mapped flag when forgetting a metadata buffer Date: Thu, 13 Feb 2020 14:38:21 +0800 Message-ID: <20200213063821.30455-3-yi.zhang@huawei.com> X-Mailer: git-send-email 2.17.2 In-Reply-To: <20200213063821.30455-1-yi.zhang@huawei.com> References: <20200213063821.30455-1-yi.zhang@huawei.com> 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 Commit 904cdbd41d74 ("jbd2: clear dirty flag when revoking a buffer from an older transaction") set the BH_Freed flag when forgetting a metadata buffer which belongs to the committing transaction, it indicate the committing process clear dirty bits when it is done with the buffer. But it also clear the BH_Mapped flag at the same time, which may trigger below NULL pointer oops when block_size < PAGE_SIZE. rmdir 1 kjournald2 mkdir 2 jbd2_journal_commit_transaction commit transaction N jbd2_journal_forget set_buffer_freed(bh1) jbd2_journal_commit_transaction commit transaction N+1 ... clear_buffer_mapped(bh1) ext4_getblk(bh2 ummapped) ... grow_dev_page init_page_buffers bh1->b_private=NULL bh2->b_private=NULL jbd2_journal_put_journal_head(jh1) __journal_remove_journal_head(hb1) jh1 is NULL and trigger oops *) Dir entry block bh1 and bh2 belongs to one page, and the bh2 has already been unmapped. For the metadata buffer we forgetting, we should always keep the mapped flag and clear the dirty flags is enough, so this patch pick out the these buffers and keep their BH_Mapped flag. Fixes: 904cdbd41d74 ("jbd2: clear dirty flag when revoking a buffer from an older transaction") Signed-off-by: zhangyi (F) --- fs/jbd2/commit.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c index 6396fe70085b..27373f5792a4 100644 --- a/fs/jbd2/commit.c +++ b/fs/jbd2/commit.c @@ -985,12 +985,29 @@ void jbd2_journal_commit_transaction(journal_t *journal) * pagesize and it is attached to the last partial page. */ if (buffer_freed(bh) && !jh->b_next_transaction) { + struct address_space *mapping; + clear_buffer_freed(bh); clear_buffer_jbddirty(bh); - clear_buffer_mapped(bh); - clear_buffer_new(bh); - clear_buffer_req(bh); - bh->b_bdev = NULL; + + /* + * Block device buffers need to stay mapped all the + * time, so it is enough to clear buffer_jbddirty and + * buffer_freed bits. For the file mapping buffers (i.e. + * journalled data) we need to unmap buffer and clear + * more bits. We also need to be careful about the check + * because the data page mapping can get cleared under + * out hands, which alse need not to clear more bits + * because the page and buffers will be freed and can + * never be reused once we are done with them. + */ + mapping = READ_ONCE(bh->b_page->mapping); + if (mapping && !sb_is_blkdev_sb(mapping->host->i_sb)) { + clear_buffer_mapped(bh); + clear_buffer_new(bh); + clear_buffer_req(bh); + bh->b_bdev = NULL; + } } if (buffer_jbddirty(bh)) { -- 2.17.2