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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21114C433EF for ; Thu, 4 Nov 2021 22:07:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A02E960F9B for ; Thu, 4 Nov 2021 22:07:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A02E960F9B 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=kvack.org Received: by kanga.kvack.org (Postfix) id 124B46B0071; Thu, 4 Nov 2021 18:07:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D4236B0072; Thu, 4 Nov 2021 18:07:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F05186B0073; Thu, 4 Nov 2021 18:07:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id E202B6B0071 for ; Thu, 4 Nov 2021 18:07:21 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8EF5B1848A03B for ; Thu, 4 Nov 2021 22:07:21 +0000 (UTC) X-FDA: 78772634682.08.4F7D227 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf18.hostedemail.com (Postfix) with ESMTP id 2F429400208D for ; Thu, 4 Nov 2021 22:07:21 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 0196C60EB4; Thu, 4 Nov 2021 22:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1636063640; bh=hiW21M8IbjMnysrLz02OTr1uCPLSmAnYYpV34I+FcwE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DKcWVOCeT6uvpUrM3DSraHq727l4tf7ibOBqBj+QXlnFIa286EcEgf3FKCgbEkWyt xjmRfoDNT5GVuUvOGjgc0HoBd9AIlXaAyD7tGqMmhIgKggmdNV2K5GYkcVtqg5ebZ8 6ri0/fHb4E2Xdv+89HNyn19OVN9i1sWX9oO/WB0s= Date: Thu, 4 Nov 2021 15:07:17 -0700 From: Andrew Morton To: Miaohe Lin Cc: HORIGUCHI =?UTF-8?B?TkFPWUE=?=(=?UTF-8?B?5aCA5Y+jIOebtOS5nw==?=) , "mhocko@suse.com" , "minchan@kernel.org" , "cgoldswo@codeaurora.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 3/3] mm/memory_hotplug: make HWPoisoned dirty swapcache pages unmovable Message-Id: <20211104150717.d235501b802868d578639422@linux-foundation.org> In-Reply-To: References: <20210821094246.10149-1-linmiaohe@huawei.com> <20210821094246.10149-4-linmiaohe@huawei.com> <20210823082646.GB1452382@hori.linux.bs1.fc.nec.co.jp> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=DKcWVOCe; dmarc=none; spf=pass (imf18.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 2F429400208D X-Stat-Signature: jse4zbsre8ewzafghr7kmwc7mm7tf6p8 X-HE-Tag: 1636063641-928 Content-Transfer-Encoding: quoted-printable 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, 23 Aug 2021 17:14:29 +0800 Miaohe Lin wrot= e: > On 2021/8/23 16:26, HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3 =E7=9B=B4=E4=B9=9F= ) wrote: > > On Sat, Aug 21, 2021 at 05:42:46PM +0800, Miaohe Lin wrote: > >> HWPoisoned dirty swapcache pages are kept for killing owner processe= s. > >> We should not offline these pages or do_swap_page() would access the > >> offline pages and lead to bad ending. > >> > >=20 > > Thank you for the report. I'm not yet sure of the whole picture of t= his > > issue. do_swap_page() is expected to return with fault VM_FAULT_HWPO= ISON > > when called via the access to the error page, so I wonder why this do= esn't > > work for your situation. And what is the "bad ending" in the descrip= tion? > >=20 >=20 > IMO we might hotremove the page while SwapCache still have ref to it. T= hus the page > struct would be accessed after offlined. The page struct should be inva= lid in this case > and this would make do_swap_page fragile. Or am I miss something? >=20 > > I feel that aborting memory hotremove due to a hwpoisoned dirty swapc= ache > > might be too hard, so I'd like to find another solution if we have. >=20 > If there is a better way, we can just drop this one. >=20 > Many thanks for your review and reply! :) >=20 > > # You may separate this patch from former two to make them merged to > > # mainline soon. > > ... > > >> --- a/mm/memory_hotplug.c > >> +++ b/mm/memory_hotplug.c > >> @@ -1664,6 +1664,12 @@ static int scan_movable_pages(unsigned long s= tart, unsigned long end, > >> */ > >> if (PageOffline(page) && page_count(page)) > >> return -EBUSY; > >> + /* > >> + * HWPoisoned dirty swapcache pages are definitely unmovable > >> + * because they are kept for killing owner processes. > >> + */ > >> + if (PageHWPoison(page) && PageSwapCache(page)) > >> + return -EBUSY; >=20 I'll drop this. Please resend something if you still believe that changes are desirable. =20