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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 9742EC6379F for ; Tue, 24 Nov 2020 05:01:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D24DF20679 for ; Tue, 24 Nov 2020 05:01:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="SwaVIz6Z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D24DF20679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F2C146B0070; Tue, 24 Nov 2020 00:01:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB1F26B0071; Tue, 24 Nov 2020 00:01:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA0C66B0072; Tue, 24 Nov 2020 00:01:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id A7B696B0070 for ; Tue, 24 Nov 2020 00:01:45 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 52CF58249980 for ; Tue, 24 Nov 2020 05:01:45 +0000 (UTC) X-FDA: 77518114170.08.side82_2910b512736b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 3B4C01819E76F for ; Tue, 24 Nov 2020 05:01:45 +0000 (UTC) X-HE-Tag: side82_2910b512736b X-Filterd-Recvd-Size: 6169 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Nov 2020 05:01:44 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id a9so27056877lfh.2 for ; Mon, 23 Nov 2020 21:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=39gr2tFdgeuXdCwWbn22GRnP3K3VvibhIlGf9k17rGw=; b=SwaVIz6ZuT6iXE5tagOrwT7N6KNmmSkcEsDFfOdmzj5yjFEuDkdXhaHbzf22ipogzf zWRWhpolqbEMbnZmb7w8SY8YssaOfvRbra2P6MvkDrdQIcceCNS8eCPycSxvqCyBE/Wt Aogcb79k9z8ri+jJ6nmyXvkP8hv8F792ZSl3g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=39gr2tFdgeuXdCwWbn22GRnP3K3VvibhIlGf9k17rGw=; b=NnkBHnsDWvmLD9iUqS8zFIkhH+zC/FUIMSs0d69A8S2L0r/j5CsBdM8rELmpzregIx LH1Kp02nq+VQxMtNKT/nkx8qezufcAKiYmpnMYTPidJK+RRJquB9CakJgZ6Su9OgzQV/ d00CXmXZOneh9Dv5+tU2Dux7IFNZPvAfh1wd+7NQxCQXQN6SmzjIahP+ayQ7lC+Wjh0P 9X8h4nPX4UEcxKdgmez8SwfgzSdtmhIYFRtvkJ9VqMaku6xjH7Z9bgqkNcxkhNtCTcq/ f+I/fPNnh+SnUkTUn0NDXPGqom60CCnTys5kdpPXBqlbyDHnVxdIkA3sM91Oez3dIWCZ QRUQ== X-Gm-Message-State: AOAM530lxJguESQBwhciPyR3mp/TcqT83X1cS4mH0+OQDiIItvqB1RuA TCVAb2HbGHUsILOvemTao17tGTbiC/h8wQ== X-Google-Smtp-Source: ABdhPJxwVzCYZrFHVx9Lnfrrf/+cg0HJC9NG5M1lJs3d/NOZA5ksglTjKl0kscuj9Nf+0+3jPqq8BQ== X-Received: by 2002:a05:6512:3093:: with SMTP id z19mr903942lfd.213.1606194103009; Mon, 23 Nov 2020 21:01:43 -0800 (PST) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com. [209.85.208.178]) by smtp.gmail.com with ESMTPSA id j13sm1607035lfk.164.2020.11.23.21.01.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 21:01:42 -0800 (PST) Received: by mail-lj1-f178.google.com with SMTP id b17so20513906ljf.12 for ; Mon, 23 Nov 2020 21:01:42 -0800 (PST) X-Received: by 2002:a19:ae06:: with SMTP id f6mr1057406lfc.133.1606193616810; Mon, 23 Nov 2020 20:53:36 -0800 (PST) MIME-Version: 1.0 References: <000000000000d3a33205add2f7b2@google.com> <20200828100755.GG7072@quack2.suse.cz> <20200831100340.GA26519@quack2.suse.cz> In-Reply-To: From: Linus Torvalds Date: Mon, 23 Nov 2020 20:53:20 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: kernel BUG at fs/ext4/inode.c:LINE! To: Hugh Dickins Cc: Jan Kara , syzbot , Andreas Dilger , Ext4 Developers List , Linux Kernel Mailing List , syzkaller-bugs , "Theodore Ts'o" , Linux-MM , Oleg Nesterov , Andrew Morton , "Kirill A. Shutemov" , Nicholas Piggin , Alex Shi , Qian Cai , Christoph Hellwig , "Darrick J. Wong" , Matthew Wilcox , William Kucharski , Jens Axboe , linux-fsdevel , linux-xfs Content-Type: text/plain; charset="UTF-8" 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 Mon, Nov 23, 2020 at 8:07 PM Hugh Dickins wrote: > > Then on crashing a second time, realized there's a stronger reason against > that approach. If my testing just occasionally crashes on that check, > when the page is reused for part of a compound page, wouldn't it be much > more common for the page to get reused as an order-0 page before reaching > wake_up_page()? And on rare occasions, might that reused page already be > marked PageWriteback by its new user, and already be waited upon? What > would that look like? > > It would look like BUG_ON(PageWriteback) after wait_on_page_writeback() > in write_cache_pages() (though I have never seen that crash myself). So looking more at the patch, I started looking at this part: > + writeback = TestClearPageWriteback(page); > + /* No need for smp_mb__after_atomic() after TestClear */ > + waiters = PageWaiters(page); > + if (waiters) { > + /* > + * Writeback doesn't hold a page reference on its own, relying > + * on truncation to wait for the clearing of PG_writeback. > + * We could safely wake_up_page_bit(page, PG_writeback) here, > + * while holding i_pages lock: but that would be a poor choice > + * if the page is on a long hash chain; so instead choose to > + * get_page+put_page - though atomics will add some overhead. > + */ > + get_page(page); > + } and thinking more about this, my first reaction was "but that has the same race, just a smaller window". And then reading the comment more, I realize you relied on the i_pages lock, and that this odd ordering was to avoid the possible latency. But what about the non-mapping case? I'm not sure how that happens, but this does seem very fragile. I'm wondering why you didn't want to just do the get_page() unconditionally and early. Is avoiding the refcount really such a big optimization? Linus