Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3055616ybi; Fri, 5 Jul 2019 01:04:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqw5Cn3MHmXuQzS28tn9SvG3iy527t6E9wEVbNQwMMh5zRa33JrHis9arTwcauErqwO7P02P X-Received: by 2002:a65:43c2:: with SMTP id n2mr3701122pgp.110.1562313875684; Fri, 05 Jul 2019 01:04:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562313875; cv=none; d=google.com; s=arc-20160816; b=ZMfrnrG3Hj8DRsBoolwJncK2eoC/U4uUwYAfAQALxnj63TIgPSKduKqRCfmyGyPYvb dDbTgT0zZlBlzbEVI1uu4IJZxfDunTlARIr8EeuXjvYW5HmdV66jCRm3Bzh7TbWT7Otu hUTbb2kGA+Fvl7uvWIJyEbLoIO68dEwh94zy3DgyTQXhtZmdRmAI3o5GLp5G/Y/0x5cX Sxv5D7sK3oRoEwtKqFVSCiHpogqWl4QjjQbxLy8B3X6igIunCscPxgvL2G5ymJiwCndJ xmQuK8uoe6GDcyaMSuAoBL0keirNDrwNhA8hPNRtxwvv8/RYkeH5TXV5t/rOZl1SVgse y/DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=faiR1LTPemAmnhtconfJ6e/qY8HyIwdDUXzddZ34Hsc=; b=ivWMdU2r6RSy9mpDdJirwwxn8+NKtXUHzt9u9UiYvpKmPMm4t/49fBe7o689py3W3f rIDqc2RDK9eWja6y5/nKUNU80ZDEg+JlgTvk9Pvd7yH9BHFr2FV3SGsDx4/s2SsGPMrw vMYsWPdhAZ0MO7snXH8d49of9L/wm1+v1UAPECeeHvG7z353TDcuO1YXgcAgAFLLOehC 0IVRhE1TigTSb/7kp+ImTWW8QJc2qXyxoF5YHnb3QuNWFzx8+JDzY8iWaLuRP08bMOkV 0EgP4reBsNRJvklmVdee52rIaoswNLZ3T6C0wbKRo8rPaqajb4hrEzQWPfqikbczALKU V8iw== 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 i18si7894606pfd.64.2019.07.05.01.04.12; Fri, 05 Jul 2019 01:04:35 -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 S1727455AbfGEHwx (ORCPT + 99 others); Fri, 5 Jul 2019 03:52:53 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:8144 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725894AbfGEHwx (ORCPT ); Fri, 5 Jul 2019 03:52:53 -0400 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 7064E3D7CA6B7F996B6D; Fri, 5 Jul 2019 15:52:48 +0800 (CST) Received: from [127.0.0.1] (10.133.210.141) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.439.0; Fri, 5 Jul 2019 15:52:42 +0800 Subject: Re: [PATCH] ext4: fix warning when turn on dioread_nolock and inline_data To: Jan Kara CC: , Jan Kara , , , , References: <1562244632-134963-1-git-send-email-yangerkun@huawei.com> <20190704145514.GC31037@quack2.suse.cz> From: yangerkun Message-ID: Date: Fri, 5 Jul 2019 15:52:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190704145514.GC31037@quack2.suse.cz> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.133.210.141] X-CFilter-Loop: Reflected Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Thanks a lot! Will resend the patch soon! On 2019/7/4 22:55, Jan Kara wrote: > On Thu 04-07-19 20:50:32, yangerkun wrote: >> mkfs.ext4 -O inline_data /dev/vdb >> mount -o dioread_nolock /dev/vdb /mnt >> echo "some inline data..." >> /mnt/test-file >> echo "some inline data..." >> /mnt/test-file >> sync >> >> With upon script, system will trigger >> "WARN_ON(!io_end->handle && sbi->s_journal)" since the wrong order >> between rsv_blocks calculate and destroy inline data for dealloc. > Thanks for the patch! Good catch! I'd just rephrase the last paragraph as: > > The above script will trigger "WARN_ON(!io_end->handle && sbi->s_journal)" > because ext4_should_dioread_nolock() returns false for a file with inline > data. Move the check to a place after we have already removed the inline > data and prepared inode to write normal pages. > > Otherwise the patch looks good to me so feel free to add: > > Reviewed-by: Jan Kara > > Honza > >> Signed-off-by: yangerkun >> --- >> fs/ext4/inode.c | 18 +++++++++--------- >> 1 file changed, 9 insertions(+), 9 deletions(-) >> >> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c >> index c7f77c6..3f2a366 100644 >> --- a/fs/ext4/inode.c >> +++ b/fs/ext4/inode.c >> @@ -2769,15 +2769,6 @@ static int ext4_writepages(struct address_space *mapping, >> goto out_writepages; >> } >> >> - if (ext4_should_dioread_nolock(inode)) { >> - /* >> - * We may need to convert up to one extent per block in >> - * the page and we may dirty the inode. >> - */ >> - rsv_blocks = 1 + ext4_chunk_trans_blocks(inode, >> - PAGE_SIZE >> inode->i_blkbits); >> - } >> - >> /* >> * If we have inline data and arrive here, it means that >> * we will soon create the block for the 1st page, so >> @@ -2796,6 +2787,15 @@ static int ext4_writepages(struct address_space *mapping, >> ext4_journal_stop(handle); >> } >> >> + if (ext4_should_dioread_nolock(inode)) { >> + /* >> + * We may need to convert up to one extent per block in >> + * the page and we may dirty the inode. >> + */ >> + rsv_blocks = 1 + ext4_chunk_trans_blocks(inode, >> + PAGE_SIZE >> inode->i_blkbits); >> + } >> + >> if (wbc->range_start == 0 && wbc->range_end == LLONG_MAX) >> range_whole = 1; >> >> -- >> 2.7.4 >> >>