Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp6614621ybe; Wed, 18 Sep 2019 06:26:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqxNyINhA/jcfd0Iohi54zmyI063s2Yl2AKTYr/+JAZ6Wn+FLmHKWeNwzg6nPkotWQk4LAuh X-Received: by 2002:a17:907:214e:: with SMTP id rk14mr9589410ejb.60.1568813161048; Wed, 18 Sep 2019 06:26:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568813161; cv=none; d=google.com; s=arc-20160816; b=cgv+icv1q2w6u02pZSzigNKuIiSd7TI0/Lw5laacEQdRuL7fbSBfzJpdk/OQ4DopRS Cr8lWD9f9Z41S308IGfYizGZPhwdaKI8vAxZTWhvvrhMoOG0YZw3voMwl0wNwTVZ8EYM wPYcRZYGGk+Qf1MbahyP2jzJFV5WVziEwnPFP9VOIvoY7/iQz+9OWjBIX8oo5ml2sWU3 AID90RSn+kJDqRL4VdEsnCN+5d6MI41JO3tgpqp46B4PTK85k7Dt1tAsw6qsQm4iTerd YhGz+1q4UTCn4GYde27Sbr3lzLu/9O6TW2nAB0BcM/EZJcCPRnijOSlRTP7AgaOiaq+H UlPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=TMQJcifCw18Ew0iiV066Ev9O+N8bfDATFtO+8P5m54c=; b=TZ5HzDGXTcz6No/qRr85qQg+4WcEYkAupBktLOC/W6fngqrx1A5icOmFcQNSvO0XZJ L/g/7b7QRMh4qVXrAEkvmuHu62HXiLm0wt+Dve1AzU6j45nkQTJN8L5HFQzfMc5EuDni 1927G3PBhCP5uT8ajetjtdOGAoi605IIv7LH8Rwl8kgl4wI0u9rh++Vi5PYTfZydXJlm rph+6bATvLHaSLEUupFajXZD+7Ea44azYrcZD3p93uLa3kxmSH93UjXGn+/tNVK2xoQj mT96CiATVZB/kJtDm30G1AOM7E7swoUJkXu4yfYRb4tj+t5x8Q3oj2lvru47grosGQKh skag== 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 c7si2614339ejr.360.2019.09.18.06.25.30; Wed, 18 Sep 2019 06:26:01 -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 S1730608AbfIRMPG (ORCPT + 99 others); Wed, 18 Sep 2019 08:15:06 -0400 Received: from mx2.suse.de ([195.135.220.15]:52192 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730634AbfIRMPF (ORCPT ); Wed, 18 Sep 2019 08:15:05 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5EC9CAD4E; Wed, 18 Sep 2019 12:15:03 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 2E6D01E47E2; Wed, 18 Sep 2019 12:45:35 +0200 (CEST) Date: Wed, 18 Sep 2019 12:45:35 +0200 From: Jan Kara To: yangerkun Cc: tytso@mit.edu, jack@suse.cz, linux-ext4@vger.kernel.org, yi.zhang@huawei.com, houtao1@huawei.com Subject: Re: [PATCH] ext4: fix a bug in ext4_wait_for_tail_page_commit Message-ID: <20190918104535.GC25056@quack2.suse.cz> References: <20190917084814.40370-1-yangerkun@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190917084814.40370-1-yangerkun@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue 17-09-19 16:48:14, yangerkun wrote: > No need to wait when offset equals to 0. And it will trigger a bug since > the latter __ext4_journalled_invalidatepage can free the buffers but leave > page still dirty. > > [ 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 below parallel can reproduce it easily(ext3): > void main() > { > int fd, fd1, fd2, fd3, 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); > > ret = ftruncate(fd, length); > assert(ret == 0); > > fd1 = open("a", O_RDWR | O_CREAT, -1); > assert(fd1 >= 0); > > flags = 0xc00f;/*Journal data mode*/ > ret = ioctl(fd1, _IOW('f', 2, long), &flags); > assert(ret == 0); > > fd2 = open("a", O_RDWR | O_CREAT); > assert(fd2 >= 0); > > fd3 = open("a", O_TRUNC | O_NOATIME); > assert(fd3 >= 0); > > addr = mmap(NULL, length, 0xe, 0x28013, fd2, offset); Ugh, these mmap flags look pretty bogus. Were they generated by some fuzzer? > assert(addr != (void *)-1); > memcpy(addr, str, 5); Also the O_TRUNC open above will truncate "a" to 0 so the mapping is actually beyond i_size and this memcpy should fail with SIGBUS. So I'm surprised your test program gets up to mbind()... > mbind(addr, length, 0, 0, 0, 2); > > close(fd); > munmap(addr, length); > } > > Signed-off-by: yangerkun I agree that there's no need to wait for transaction commit when offset == 0. So your patch is correct in that regard. What still escapes me is why this is necessary. I have a feeling that it just papers over the real problem. You mention crash in ext4_writepage() because page is dirty but has no buffers - but how come the page is dirty? If offset == 0 for a page, truncate_inode_pages() should have cleaned PageDirty flag so the page should never get to ext4_writepage() in the first place. Together with my comments about the test case this is still a bit mystery to me... I guess I'll try to reproduce this to understand this better. Honza > --- > fs/ext4/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > index 006b7a2070bf..a9943ae4f74d 100644 > --- a/fs/ext4/inode.c > +++ b/fs/ext4/inode.c > @@ -5479,7 +5479,7 @@ static void ext4_wait_for_tail_page_commit(struct inode *inode) > * do. We do the check mainly to optimize the common PAGE_SIZE == > * blocksize case > */ > - 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 > -- Jan Kara SUSE Labs, CR