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=-3.8 required=3.0 tests=BAYES_00, 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 533A8C433B4 for ; Tue, 11 May 2021 09:34:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BF20F61001 for ; Tue, 11 May 2021 09:34:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF20F61001 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0A5786B006E; Tue, 11 May 2021 05:34:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 042186B0071; Tue, 11 May 2021 05:34:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4B986B0072; Tue, 11 May 2021 05:34:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id CB5BE6B006E for ; Tue, 11 May 2021 05:34:13 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8C768989A for ; Tue, 11 May 2021 09:34:13 +0000 (UTC) X-FDA: 78128439186.16.60BB33D Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf19.hostedemail.com (Postfix) with ESMTP id E9C0390009DE for ; Tue, 11 May 2021 09:33:39 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9D934AFEC; Tue, 11 May 2021 09:34:11 +0000 (UTC) Date: Tue, 11 May 2021 11:34:07 +0200 From: Oscar Salvador To: Jan Kara Cc: yangerkun , naoya.horiguchi@nec.com, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, tytso@mit.edu, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, yi.zhang@huawei.com, yukuai3@huawei.com, houtao1@huawei.com, yebin10@huawei.com Subject: Re: [PATCH] mm/memory-failure: make sure wait for page writeback in memory_failure Message-ID: References: <20210511070329.2002597-1-yangerkun@huawei.com> <20210511084600.GG24154@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210511084600.GG24154@quack2.suse.cz> X-Rspamd-Queue-Id: E9C0390009DE Authentication-Results: imf19.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf19.hostedemail.com: domain of osalvador@suse.de designates 195.135.220.15 as permitted sender) smtp.mailfrom=osalvador@suse.de X-Rspamd-Server: rspam04 X-Stat-Signature: do89es6da4exy883twbnymy6oww9dorj Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf19; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1620725619-550276 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, May 11, 2021 at 10:46:00AM +0200, Jan Kara wrote: > We definitely need to wait for writeback of these pages and the change you > suggest makes sense to me. I'm just not sure whether the only problem with > these "pages in the process of being munlocked()" cannot confuse the state > machinery in memory_failure() also in some other way. Also I'm not sure if > are really allowed to call wait_on_page_writeback() on just any page that > hits memory_failure() - there can be slab pages, anon pages, completely > unknown pages given out by page allocator to device drivers etc. That needs > someone more familiar with these MM details than me. I am not really into mm/writeback stuff, but: shake_page() a few lines before tries to identifiy the page, and make those sitting in lruvec real PageLRU, and then we take page's lock. I thought that such pages (pages on writeback) are stored in the file LRU, and maybe the code was written with that in mind? And given that we are under the PageLock, such state could not have changed. But if such pages are allowed to not be in the LRU (maybe they are taken off before initiating the writeback?), I guess the change is correct. Checking wait_on_page_writeback(), it seems it first checks for Writeback bit, and since that bit is not "shared" and only being set in mm/writeback code, it should be fine to call that. But alternatively, we could also modify the check and go with: if (!PageTransTail(p) && !PageLRU(p) && !PageWriteBack(p)) goto identify_page_state; and stating why a page under writeback might not be in the LRU, as I think the code assumes. AFAUI, mm/writeback locks the page before setting the bit, and since we hold the lock, we could not race here. -- Oscar Salvador SUSE L3