From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5528C2D0C0 for ; Thu, 19 Dec 2019 09:45:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8E54C206D8 for ; Thu, 19 Dec 2019 09:45:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E54C206D8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1E43F8E015F; Thu, 19 Dec 2019 04:45:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 194B28E00F5; Thu, 19 Dec 2019 04:45:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AB9E8E015F; Thu, 19 Dec 2019 04:45:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id E56458E00F5 for ; Thu, 19 Dec 2019 04:45:46 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 462DC181AEF10 for ; Thu, 19 Dec 2019 09:45:46 +0000 (UTC) X-FDA: 76281409092.08.year05_6c87e60f91f4f X-HE-Tag: year05_6c87e60f91f4f X-Filterd-Recvd-Size: 2872 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Thu, 19 Dec 2019 09:45:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 80B2AAE4B; Thu, 19 Dec 2019 09:45:43 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 30E2B1E0B38; Thu, 19 Dec 2019 10:45:42 +0100 (CET) Date: Thu, 19 Dec 2019 10:45:42 +0100 From: Jan Kara To: Tetsuo Handa Cc: Vlastimil Babka , syzbot , linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, Jan Kara , linux-fsdevel@vger.kernel.org Subject: Re: WARNING in unaccount_page_cache_page Message-ID: <20191219094542.GA24349@quack2.suse.cz> References: <00000000000046fd2f059877e20e@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat 30-11-19 00:30:03, Tetsuo Handa wrote: > On 2019/11/29 23:41, Vlastimil Babka wrote: > > On 11/29/19 9:19 AM, syzbot wrote: > >> Hello, > >> > >> syzbot found the following crash on: > >> > >> HEAD commit: 089cf7f6 Linux 5.3-rc7 > > > > Ugh, why test previous cycle's rc7 now? Typo for 5.4? > > > >> git tree: upstream > >> console output: https://syzkaller.appspot.com/x/log.txt?x=1210a761600000 > >> kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4 > >> dashboard link: https://syzkaller.appspot.com/bug?extid=fe601f9e887449d40112 > >> compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Please open the dashboard link. The first occurrence was 5.3-rc7 and the last > occurrence was 5.4-rc7+. In other words, this bug is likely not yet fixed. I've briefly looked at this so I'll dump my memory state here in case someone wants to have a look (or for me when I get more time to look into this): The problem always happens on block device mapping. What I think is happening is that truncate_inode_pages() races with some filesystem on top of that block device holding buffer_head reference and calling mark_buffer_dirty(). The buffer_head reference makes block_invalidatepage() fail invalidating page buffers (try_to_release_page() respectively) and following mark_buffer_dirty() call will happily redirty the page in whatever state it is. Now I didn't yet made up my mind what would be a proper way to fix this... Honza -- Jan Kara SUSE Labs, CR