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,URIBL_BLOCKED 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 33647C56202 for ; Tue, 24 Nov 2020 20:34:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7B0C2206E0 for ; Tue, 24 Nov 2020 20:34:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="YiUauuLl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B0C2206E0 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 A77006B006E; Tue, 24 Nov 2020 15:34:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FFDE6B0070; Tue, 24 Nov 2020 15:34:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C8466B0071; Tue, 24 Nov 2020 15:34:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 71CA86B006E for ; Tue, 24 Nov 2020 15:34:55 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 33E97180AD802 for ; Tue, 24 Nov 2020 20:34:55 +0000 (UTC) X-FDA: 77520465750.11.eye50_1b0acd527371 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 0A4A2180F8B90 for ; Tue, 24 Nov 2020 20:34:55 +0000 (UTC) X-HE-Tag: eye50_1b0acd527371 X-Filterd-Recvd-Size: 5921 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Nov 2020 20:34:54 +0000 (UTC) Received: by mail-lf1-f50.google.com with SMTP id u19so30794018lfr.7 for ; Tue, 24 Nov 2020 12:34:54 -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=AEOjqbrPL7ThHmqZn4HHPdQNZCU9KRjN0OANoYqF+LI=; b=YiUauuLl4oDGTRL45zuGDHR2J5VSlaFB7O6pBpiLin0jYi4oMDEyJ6WnB0ezsU1+lJ /Xr+VMmFy6Yl0v0tfocLf0a2OpJoR4jkrZf+QWqP87nKzXSlOFC8xx9JTBLeqme23GEA yBj2rHCTti3flo3PfXBjCwjdx6z70F417NynU= 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=AEOjqbrPL7ThHmqZn4HHPdQNZCU9KRjN0OANoYqF+LI=; b=BdOWszHWGhjhbb3PbYblhZJ8yxVKVe4X6BkFZJcDmbSiXK5KDBKncleGOvrgwg+B+y 8tQmqr90XTqkNzl3IdiELJ1+ZJLFz2hlp85oDQVG87DbjxQDQN2XSBWcw7nyCZ+rx8kd pv7Yam5UUEtKfQGDwEA8TuqIN+f/+OricpjmhxL+U6ItTK0bFbI59luTrXeiDg+4FYHp baIA1lFZJMJo6Fviq/Mv+Hn3XSdvv6wI+5jlitNlAmE4ZThB/xSeHuGYdMwHqzcuEHKj 6I5bNFGFdrrDnNXME8gYGUouedjUp5azqRfE1xS3GgZQ4rG5zI9aNwJZlEf+311Rh5Le kq1A== X-Gm-Message-State: AOAM533Z0R/NCW3ABux8ki21Ecqh9geznDcvJDM1jo82JQ8clxtna81o pk6jbvwL36tkoRZwZ+ctdEuurLCAIDqfnA== X-Google-Smtp-Source: ABdhPJzrz5uXOOA8huVT6pfuu77jVdQDCfO2JRY0ZvySRc3AAQ32VaDkqoRcPVJBA1M3NngUyQWRBA== X-Received: by 2002:a19:4154:: with SMTP id o81mr2400357lfa.540.1606250092428; Tue, 24 Nov 2020 12:34:52 -0800 (PST) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id x5sm15853ljj.121.2020.11.24.12.34.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 12:34:50 -0800 (PST) Received: by mail-lj1-f182.google.com with SMTP id f24so10696104ljk.13 for ; Tue, 24 Nov 2020 12:34:49 -0800 (PST) X-Received: by 2002:a2e:8701:: with SMTP id m1mr27321lji.314.1606250089295; Tue, 24 Nov 2020 12:34:49 -0800 (PST) MIME-Version: 1.0 References: <000000000000d3a33205add2f7b2@google.com> <20200828100755.GG7072@quack2.suse.cz> <20200831100340.GA26519@quack2.suse.cz> <20201124121912.GZ4327@casper.infradead.org> <20201124183351.GD4327@casper.infradead.org> <20201124201552.GE4327@casper.infradead.org> In-Reply-To: <20201124201552.GE4327@casper.infradead.org> From: Linus Torvalds Date: Tue, 24 Nov 2020 12:34:33 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: kernel BUG at fs/ext4/inode.c:LINE! To: Matthew Wilcox Cc: Hugh Dickins , 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" , 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 Tue, Nov 24, 2020 at 12:16 PM Matthew Wilcox wrote: > > So my s/if/while/ suggestion is wrong and we need to do something to > prevent spurious wakeups. Unless we bury the spurious wakeup logic > inside wait_on_page_writeback() ... We can certainly make the "if()" in that loop be a "while()'. That's basically what the old code did - simply by virtue of the wakeup not happening if the writeback bit was set in wake_page_function(): if (test_bit(key->bit_nr, &key->page->flags)) return -1; of course, the race was still there - because the writeback bit might be clear at that point, but another CPU would reallocate and dirty it, and then autoremove_wake_function() would happen anyway. But back in the bad old days, the wait_on_page_bit_common() code would then double-check in a loop, so it would catch that case, re-insert itself on the wait queue, and try again. Except for the DROP case, which isn't used by writeback. Anyway, making that "if()" be a "while()" in wait_on_page_writeback() would basically re-introduce that old behavior. I don't really care, because it was the lock bit that really mattered, the writeback bit is not really all that interesting (except from a "let's fix this bug" angle) I'm not 100% sure I like the fragility of this writeback thing. Anyway, I'm certainly happy with either model, whether it be an added while() in wait_on_page_writeback(), or it be the page reference count in end_page_writeback(). Strong opinions? Linus