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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72875C61D9B for ; Wed, 22 Nov 2023 11:45:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F05CE6B059F; Wed, 22 Nov 2023 06:45:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB64D6B05A3; Wed, 22 Nov 2023 06:45:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7E136B05A5; Wed, 22 Nov 2023 06:45:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C984B6B059F for ; Wed, 22 Nov 2023 06:45:02 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6F29B80B0E for ; Wed, 22 Nov 2023 11:45:02 +0000 (UTC) X-FDA: 81485408844.07.CAB96D1 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf19.hostedemail.com (Postfix) with ESMTP id E71F11A0018 for ; Wed, 22 Nov 2023 11:44:59 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=K270VxXh; spf=pass (imf19.hostedemail.com: domain of sumanthk@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=sumanthk@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700653500; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ILScWUFBohu5TA6QkuZBitynfNjUVrM4NkTm8HcUzIY=; b=qlYH7XMufjHSx2LRuvRyHIYYly1oqvnKrloRVM7FZMOR9oKxWIaKqwmiMZvyLwITN6yOYz nBNPQPi7l3tITnpDoIj7Oo5qxnvFmkdDseCHwIsfRYHCtPioOb4LrjyMRlX5eTXNFKSLxf wmNc/XXkgkbIIVoJ2RSiWE0QYLezsYI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700653500; a=rsa-sha256; cv=none; b=Ali2PIcNiXoYM015kLRdmgaQO51IWMM5St6drOpRCXp8m8Mxpp/jDxGACwgz+OA7xkTXXk cjeOC0iiHz8MefKLf5FaIlNS6Oo8AocfQ3iVkX4k3pNE74LjgMEhzsdK/coVXUENFJguN7 +DUThClbJHZDpqERL8ATghp+uBQan4s= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=K270VxXh; spf=pass (imf19.hostedemail.com: domain of sumanthk@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=sumanthk@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com Received: from pps.filterd (m0353728.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3AMBgjF1013336; Wed, 22 Nov 2023 11:44:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=ILScWUFBohu5TA6QkuZBitynfNjUVrM4NkTm8HcUzIY=; b=K270VxXhggxrNwe1Xlj+i61gca1bo3B7g6L6LM9KDJMgB0hCRb9ABQHf8hnD8jgZ+jUe rCSwKsAqE8xyTzNbOjHGW2idCOP5ZKepvUHb8L8c8Dx+RTugImWA+c5+EjXCSM+pdvlN G6cpZ1OSpcHMTGMO4W210ecWeoOPKNR2D+WwZ58PyX6S8o5RY3EcGFjtxLa/EeFGt9L/ Y5hDs1hEauzmPGLWrymsQxKs3+K+8DaO3LqyPU0HIfmSQ5s36RaQMxwkSKw3mXKGPgtL e09MYFPdUsO0L65b4hqCrO5a2JEIbiQxidRtZi1rC7+DouXO4UQeKsRoMHprAzYjNgUy 4Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3uhh0jr1y6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Nov 2023 11:44:55 +0000 Received: from m0353728.ppops.net (m0353728.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3AMBhWRX016509; Wed, 22 Nov 2023 11:44:54 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3uhh0jr1xn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Nov 2023 11:44:54 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3AMAJsSf028656; Wed, 22 Nov 2023 11:44:53 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3ufaa27171-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Nov 2023 11:44:53 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3AMBioDL22938334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Nov 2023 11:44:50 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8E5F20043; Wed, 22 Nov 2023 11:44:50 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 15A1E20040; Wed, 22 Nov 2023 11:44:50 +0000 (GMT) Received: from li-2b55cdcc-350b-11b2-a85c-a78bff51fc11.ibm.com (unknown [9.171.80.61]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS; Wed, 22 Nov 2023 11:44:50 +0000 (GMT) Date: Wed, 22 Nov 2023 12:44:48 +0100 From: Sumanth Korikkar To: David Hildenbrand Cc: Gerald Schaefer , linux-mm , Andrew Morton , Oscar Salvador , Michal Hocko , "Aneesh Kumar K.V" , Anshuman Khandual , Alexander Gordeev , Heiko Carstens , Vasily Gorbik , linux-s390 , LKML Subject: Re: [PATCH 0/8] implement "memmap on memory" feature on s390 Message-ID: References: <20231114180238.1522782-1-sumanthk@linux.ibm.com> <20231117140009.5d8a509c@thinkpad-T15> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-GUID: X1AqukaWBFoaIPtex_EZKGfcXk12FrMp X-Proofpoint-ORIG-GUID: C3uaEhlB_rODV9dILGnop85wr3xgbxtc X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-22_07,2023-11-22_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 phishscore=0 priorityscore=1501 mlxscore=0 impostorscore=0 bulkscore=0 adultscore=0 spamscore=0 suspectscore=0 malwarescore=0 clxscore=1015 mlxlogscore=654 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311220082 X-Rspamd-Queue-Id: E71F11A0018 X-Rspam-User: X-Stat-Signature: aqogxo8r1ai4kp97a3ohttb117us9rht X-Rspamd-Server: rspam03 X-HE-Tag: 1700653499-176029 X-HE-Meta: U2FsdGVkX1/N8dIGUZryEQEWuHUOKFoj2luD3TsJr+HoPxCH8pRqrUJoyVVKHbUR+SEd2GjBpynpNnfe+YqJGE1OHl/AYOu/moPsJISV01aSfylnuo32TxRMNpbqBAbstQnuiMd+jjOe/7x3xl/ufky9LnT5y0WwB9Z30fRqQeos1MIEZ1yYSv2Z0A5NnUr3ntYr1WX7WBMe+R8gMj8IJ/YLI2EIn/bjKwHkQ8BqaS7LwWDzUyRDr556zSrD6nOxf+cYJtX98zgD+yBlnA9Stvwy3ic0JdLf4zUmAUr1sZ4nEAKzk0u6/7iGxne5dNmK+RAB/HOxvrvqS2A49NEL0MeoiWtLdBiDmaiEYdyr+Ubb+3JJ5Qe206NBeEDziOF1p8aLUNUC1uIyu+nJ5MOzNDC5rjuDGbOeyrb7kPuSkXYq7CCLT6ggCLg7LjCzCQ4ShW6By71siDm/eS+5ZSVKGDPz7sWVCKlILn/Uu+npsDzae7W7g3+fDxfNyidgTRMBWCtXhmVQT3ahS4qn+jqmyUcQhH4k8z1xgY3rM5iom0/1R/GW+kVTUTDVpjlbtbOE3biFea7GoVECN5geER/LVok2BmraB4bzs2t+FIDZjjyvYVj8I4xe740xvGjtAf0Q9Fi1Q4zauYUUktfBpf2cG57gXnVstx8uy6gDBP9TJZt2bFT8UY2LEzs91nrOmbd+C8TvFZUibMMUheaUQMsU8CKypmshmxqAFZMOtqht6mDIICJt+kySo1amzxzWgAnPPH2RL/eFz520DEJi8YTU9CebLqeN7Z8nE0cpLeqmUoKSUlHy85QwVf7E1i+1dlFkewMETxwFGqSbGw/Uby5fjXxQ4w/jg5yeeYraIt5JQcX0fXc6jRSv9qcvbvOsYqMOmEfiSL3BK0Jl+SsKlE5tgsr+9OwnhHns3rMCRVMaexWmWpuKzc7YibVsLe160oaj+df59+qcKEJNRk3LzNb DotRSjmD 05Pl1XJL3nkkTBDcqGlddn7DAm1IFoKQ5y7zEltonh1W+6cUkNjy8afHbwQy6sct+VNOjts1ACmZVjSG7TkwB9oEvBuliJrBW1P0BtYZTGPO8OANfPr7gWsAgKKjDNxgtVbfoVxXw6h4im4+JN0TIXdIh2CZJgat5IFopajTkJwNr73K/Miitt96z98/kpm8kvg6G47CdWa49O9dmfC3u/C/o5oWTokadqy7P 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: List-Subscribe: List-Unsubscribe: On Tue, Nov 21, 2023 at 08:24:48PM +0100, David Hildenbrand wrote: > > diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h > > index 7d2076583494..5c70707e706f 100644 > > --- a/include/linux/memory_hotplug.h > > +++ b/include/linux/memory_hotplug.h > > @@ -106,6 +106,11 @@ typedef int __bitwise mhp_t; > > * implies the node id (nid). > > */ > > #define MHP_NID_IS_MGID ((__force mhp_t)BIT(2)) > > +/* > > + * Mark memmap on memory (struct pages array) as inaccessible during memory > > + * hotplug addition phase. > > + */ > > +#define MHP_ALTMAP_INACCESSIBLE ((__force mhp_t)BIT(3)) > > If we go that path, maybe rather MHP_OFFLINE_INACCESSIBLE and document how > this relates to/interacts with the memory notifier callbacks and the altmap. > > Then, we can logically abstract this from altmap handling. Simply, the > memory should not be read/written before the memory notifier was called. > > In the core, you can do the poisioning for the altmap in that case after > calling the notifier, probably in mhp_init_memmap_on_memory() as you do > below. ok, sure. Thanks. > > > /* > > * Extended parameters for memory hotplug: > > diff --git a/include/linux/memremap.h b/include/linux/memremap.h > > index 744c830f4b13..9837f3e6fb95 100644 > > --- a/include/linux/memremap.h > > +++ b/include/linux/memremap.h > > @@ -25,6 +25,7 @@ struct vmem_altmap { > > unsigned long free; > > unsigned long align; > > unsigned long alloc; > > + bool inaccessible; > > We should then likely remember that information for the memory block, not > the altmap. Tried using inaccessible field in memory_block and observed that the memory block is created following the success of arch_add_memory(). Hence, when conducting checks for inaccessible memory in sparse_add_section() (regarding page poisoning), there is still a reliance on mhp_flags conveyed through add_memory(). Subsequently, then memory_block inaccessible state is set in create_memory_block_devices(). I hope this approach is fine. On the other hand, relying on inaccessible flag in vmem_altmap could make checks in arch_add_memory() and other functions easier I suppose. > > [...] > > > > > > > Approach 2: > > =========== > > Shouldnt kasan zero shadow mapping performed first before > > accessing/initializing memmap via page_init_poisining()? If that is > > Likely the existing way. The first access to the poisoned memmap should be a > write, not a read. But I didn't look into the details. > > Can you try reproducing? > Executing page_init_poison() right before kasan_add_zero_shadow() in the context of altmap usage did not result in a crash when I attempted to reproduce it. However, altmap + page_init_poisoning() within sparse_add_section(), a crash occurs on our arch, as previously discussed in this thread. Thank you