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 01A94C25B06 for ; Thu, 4 Aug 2022 16:56:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEA6E6B0071; Thu, 4 Aug 2022 12:56:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E98FA6B0072; Thu, 4 Aug 2022 12:56:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC38E8E0001; Thu, 4 Aug 2022 12:56:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B69956B0071 for ; Thu, 4 Aug 2022 12:56:48 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 83B6FAC0DE for ; Thu, 4 Aug 2022 16:56:48 +0000 (UTC) X-FDA: 79762514496.02.7C4FAB9 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf24.hostedemail.com (Postfix) with ESMTP id E7E09180136 for ; Thu, 4 Aug 2022 16:56:47 +0000 (UTC) Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 274Gi6i2009818; Thu, 4 Aug 2022 16:56:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=corp-2022-7-12; bh=3zD1ekOY4O5TLbyIwWsB6q7FmaWoIQDfy598ME4+ub4=; b=Kujaxd298pIPC8xfaDGc5ys2qvHFp9iRLnt+BlHfOqLWySSIemju9lIdg7rX9LFgyaF8 i1SpWA5diAwysCDeZNP1EqZN5LYz2iB10vtEpGfsA+skOf886WrGuKOxijqzRtRvaNLW TWlxcfZrwtGTddSlu8GKFhDbhobu6U/hvt0dVey9UUjSlOzsGOCvJKtE2ILr0Fm/mhvN rTYhwmWSHL3RQLQ+2LiSI+mtcjZMdwSJPIOrDMi4AJVJUvvbMKLoF5m465DNo+90QCE1 CGcI/YqdmUb7UD++DxST3tYv/1ucavlrynfxucJ/kH0Y093Nn3ylBFikiXnOLBF+aXx6 vA== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3hmw6tnhka-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Aug 2022 16:56:45 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 274Ell7N002941; Thu, 4 Aug 2022 16:56:43 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3hmu34gmhn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Aug 2022 16:56:43 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WXv7dQ7UqvMH80nv3EEeF0kS6/9/mT6zVQPhPZKx764oS0RY5VgJa2X5JIfMabevOiJrp99EXrEZnOSA7ekgTSkO2pI2nztBunnPC53/ilwGwkEyr1Vi94D/Hf1Kb/XOzK+1GwiVhM/RhgwsfHchDNNoV4AbwQhbSYfGn/LdUI9y8fjxjbY7af5a62pkEMbVEMorAx5y6h5DeE8SMk2JCHmFMPeR7u7Ecp8vm7UehhheB0DSumArB5VxFbmIedeSUWkJ5zaUpm0zom07DFHUJCB6mqbchmGQbOr5HcAbxFKmexc5B4oZ4tzVtkdksrtrJ1bNvwFAHHwOh45Oj4HpNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3zD1ekOY4O5TLbyIwWsB6q7FmaWoIQDfy598ME4+ub4=; b=f1zg+kELeW9doO/vDFDFZD6FOXtY8zh65Gs2yWle+Gv5+f3Q8MDchuXopYH9fCCy6wvLuJiFxJURdHsDNvcvOAPaTVcFnj0uTZHMzRE9XceGDFK3Pfe+NxZ6EYHOUgCmEydmC1caUCr5n8a4dvSfDo6IpNtTB7I/kweb1iY3oYkiXdCfABSVnmNNAxnH6c+ynoaIysoYf8dhBFb069ZRoZPhodiw3cA2sEckLfGIvm0MMI6oa1nEoiHI2uSV4lU+HGfYhKi0gyaYiob4oQvyywW491WS9+MrihKd1/GS78NxfW1ouEcndmAqy3S6k9LTqVf7lyCeB03gcsUhKs8GQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3zD1ekOY4O5TLbyIwWsB6q7FmaWoIQDfy598ME4+ub4=; b=0MXI4vPslgY1qSR0HZbRWzgQBqlvq01zFClszf3V3Drk7rykV4mm8rjamMCZZEpzHxBW1RPRF6a9ZmAaLra3+h8xezMhbkCa3VdmXBKvloAIGhKaQ+yWCHnwWioCwKMz+BPaV+1BwjKmm+AcSIYS+G9QcWs2eThkX74S7pP5QNw= Received: from BY5PR10MB4196.namprd10.prod.outlook.com (2603:10b6:a03:20d::23) by MN2PR10MB4157.namprd10.prod.outlook.com (2603:10b6:208:1dc::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.14; Thu, 4 Aug 2022 16:56:41 +0000 Received: from BY5PR10MB4196.namprd10.prod.outlook.com ([fe80::c1ba:c197:f81f:ec0]) by BY5PR10MB4196.namprd10.prod.outlook.com ([fe80::c1ba:c197:f81f:ec0%6]) with mapi id 15.20.5482.016; Thu, 4 Aug 2022 16:56:41 +0000 Date: Thu, 4 Aug 2022 09:56:39 -0700 From: Mike Kravetz To: Muchun Song Cc: Joao Martins , linux-mm@kvack.org, Naoya Horiguchi , Andrew Morton Subject: Re: [PATCH v1] mm/hugetlb_vmemmap: remap head page to newly allocated page Message-ID: References: <20220802180309.19340-1-joao.m.martins@oracle.com> <0b085bb1-b5f7-dfc2-588a-880de0d77ea2@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: SJ0PR13CA0190.namprd13.prod.outlook.com (2603:10b6:a03:2c3::15) To BY5PR10MB4196.namprd10.prod.outlook.com (2603:10b6:a03:20d::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 54476ab8-37bb-4de0-bf8a-08da763a4de0 X-MS-TrafficTypeDiagnostic: MN2PR10MB4157:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7VypTCSaKMs8n4xOE7/6+SpO6f41T7ULIqxGPdvSo1pmC5xkdFHwgucAoJV0VZaxNcdDs8gLsDK0ZxkVfCcWvEl1rwmmr26ZvIi+r6BXHXAdcCehTZPe7JlKjA5gvgl8L4Xm29xkmDUdDHOBEZUT7JtkmHpvlKclLI32Q8o8vzkSfHEhjdUXe28+89X5UtYazGUX3KUfd+wEVreUsoK0BqVSYA3B1VbSTz5aGeCkpFbxWUq/qkKekDvVbAK9iskilW+dzpLL96msAhysvc5bVQ0eMQbUf7CESg491t2zSW4iedSRvmmpQwhxjSSb8L02CG8hzc2VCk2WHTjxFKb9K3RgWtCtTRizqYMmAoZfQrgUKnM1fx7O2/t73vcA3b6d44KXcJq0uTmzzChmeQ8X5bkwdJ8JorpMRHwwdhA630wNUhAOefVuTQUDc0CnlVp3OexAE/Kxaw5KSTK40hr2VG03IdXw5AQCNJLhxaP4E4LISOE06e5KrGud/u0bR+B7B3OcUUyTM+S82LkdsNyGitPZkW9KvYMhrv/Ymv/tjwl0J1XMjR6HJ3DxMz7qTvGcdcfG1iXDrGLtm9fvwHZZxk7Cpvl0nWqeBtwIYRR/t9TEXv7gE5CEdaDQ/im6IAY0mfIWO3gQRYmvlWnXMFOCJelJDFpSoBm+PSFw69q433VH29rMVKZtsrmPpUsElN6Gl2ZBnpGCYZoFUM18TYFGQKk8p6CMJIXhAwqKxhgMSJRZAK2trbRofgcbhLPfDRlYXxLfMIUiit3EfNQXwh8EN+kgIiwsD4NK5wUxcnWI41KtKhPGaw/4PzhIPVfKZVh1/x3fXCS6bI9tQJM5rnFc9e6w9O2iljVz59ea7dxVluA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR10MB4196.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230016)(7916004)(376002)(39860400002)(396003)(346002)(366004)(136003)(2906002)(44832011)(33716001)(41300700001)(5660300002)(186003)(53546011)(6506007)(9686003)(6512007)(26005)(38100700002)(316002)(478600001)(83380400001)(966005)(6486002)(86362001)(8936002)(66946007)(66476007)(4326008)(8676002)(66556008)(6916009)(54906003)(67856001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?WhUrHbxA9uQYei+CY1DXXBCXhWESd9lG+AD7L9M4ml/Fpv5ENZ7fpGKizYcP?= =?us-ascii?Q?nL3R2yeZnu4JC9OJR5OgtU8BD0WEaVrWgPnTyD3JSlWyt8utUYZtxoudAj6v?= =?us-ascii?Q?B5x2qotyALKDLf2+Y26jwPHUsKR0b9BS3O7NQh1490an/OOE9wepSAYVU3pt?= =?us-ascii?Q?MXr9H9CSnSfZ2oiuFPo+26RoIJRXq1DcaWf4bfF009agMvs7RDYL2oOr5WHZ?= =?us-ascii?Q?G9XbkkMlVksb7/tY5MVjtGEC6vIHh5xH/wrSzrSy1sHIeUFrF+RILhQfNVbV?= =?us-ascii?Q?41njq2jP3xfwbUZEcwtP8u18TpOIITh3nRIZeh5mSBqvk51+IyNpc+0PIJjt?= =?us-ascii?Q?CWapdmP2d7znw9s8XYeztioW6LbY+hHRHL3qiXfxzOGTs5/QybLuPPVJK3jU?= =?us-ascii?Q?Pl/5KIawN452PqhRU7Xz68ccnUChyou6SP4N6B9TsVxFq+fWgfccWxqymAnB?= =?us-ascii?Q?QuuZfZKs76Lq0t7ZiuG7Yc/O1+pkNdWI0Ux2wWTSO65F7sikQkIiW/aCtQ6p?= =?us-ascii?Q?v4WYlSEnZLh+A8R+10QfomxvEWKxX6moVEQ2FIcum7LfQj3kcHm4XHY3lYAU?= =?us-ascii?Q?gLPtHVMfHgZ7vHt7sHNHVtJklrXt8z57rx7WO/ZK27DBZfxsnWLVXw4V3gKo?= =?us-ascii?Q?5ky4eazSYibtcU7mEQ5kX8CKHnB1sKt54+E6RfawX5PdGNmS2pf1mbynr9rU?= =?us-ascii?Q?GQ5ztWqZmiIWXMgxytulhJcl2yVCWRDUP4qwuM6RC0jmHPCNm1liegoDGCqn?= =?us-ascii?Q?oeKMjcSuucy0THq6Btq46MJLiUZa3qzKF0HxodntxtFhMMOsWLXf+yrLHUmd?= =?us-ascii?Q?e7w7QYq4H0umXPiKElOZI30RZicNSbRKxhKauko35zzPD7D4kZ2isClCrWP7?= =?us-ascii?Q?0e4Qb/LB8/v+ySbJh90ptUp9mk5ZeDuSFBcQnXIXT7HXtsVrn6OBl+t0wPjB?= =?us-ascii?Q?ZeE1eSPamn52rb5aScZRloCFDXsIGJWZ9E2uqOrPwthw3CvxoJyulY5OTayX?= =?us-ascii?Q?bTPAeWOYnvoGwNhJTbPgDc0cdggJDH7N+eYa5egB62uGTraYlhWMuhZoN2vn?= =?us-ascii?Q?39mAsFpRHnE6TMi3/u55fh62DlKvKCC37GuGlvutjqB/7OhdUVc44FJZGIsb?= =?us-ascii?Q?U7xbioGEtbJl4Py6D4jJg+EsOREJFrx2HV9UbS961FtUOOMYWvI5yNXFlFsR?= =?us-ascii?Q?u7SaXxxY/GO80bOE9b7vEbD4SpQt4bYQKFQKPqq6AnDdBmT7d9YCw3XdPj5v?= =?us-ascii?Q?r76QDHIUQj9OEo7vyk+YgT/QM7Vg0CLwjqpnulsupycX/842bT+e9fIUKFQB?= =?us-ascii?Q?kK96EGSyimuJgJ6XOMLTxlhcjQFXDGeNrZ2/JDIjfePRYMGNUTbj3+JHOttQ?= =?us-ascii?Q?CtKZ6odSFdHXdghrb0s/Uqar0/kxTdmWUUrz7KD7uDZQUXKDoVaJEKwYbdAH?= =?us-ascii?Q?EOYS1Ajrni+tMw4Dz4Dh1UGZEzQl10CsPJzAi+2oB4lnEYIxFjbhXWWGUQML?= =?us-ascii?Q?G+zewQY9FjAxLapQ9hWOCHAZhUA/p5PqCPvyLkEwofSxKbqHVyaAGql/0j/+?= =?us-ascii?Q?Nen/DHeaxYXfdu4LAR5inVkgu02hCtW+OVLnSqkMnC3V4ye5lgqlRKhkVqjn?= =?us-ascii?Q?Fg=3D=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54476ab8-37bb-4de0-bf8a-08da763a4de0 X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2022 16:56:41.4507 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: RSfbmvV6DCfpE6w2QGfvUdiSQUyIO5Dn1cgbkmW7+mM3RE7GBDvvfu7rT5aTeg5B91ltoEdz55IDblAPxZwA/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR10MB4157 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-04_03,2022-08-04_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 phishscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208040073 X-Proofpoint-GUID: sEag7KTQhbAGpLpQ7EvBMCbC0mQuyjrK X-Proofpoint-ORIG-GUID: sEag7KTQhbAGpLpQ7EvBMCbC0mQuyjrK ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1659632208; a=rsa-sha256; cv=pass; b=uPvF0tTzdMM/uMk+phobrfwr2jZpqMDA7o1tArnvweYyeCM0m/vx7Z0BTcKufprfNSBjzJ QrZBXwoUJTvwe3RjWav9HQeQ565mSEQ9JdUgEcDglHlibZ5WKlbdCbFbCP4LHDucFTOCMA wJI+xkuNhfJWsPLe7Zlc+/DPA5ytB24= ARC-Authentication-Results: i=2; imf24.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2022-7-12 header.b=Kujaxd29; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=0MXI4vPs; dmarc=pass (policy=none) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=temperror (imf24.hostedemail.com: error in processing during lookup of mike.kravetz@oracle.com: DNS error) smtp.mailfrom=mike.kravetz@oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659632208; 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=3zD1ekOY4O5TLbyIwWsB6q7FmaWoIQDfy598ME4+ub4=; b=e4/h0oaE++RY0av6bf38ExW+vXK6qYJeJp4vrftM+5uSrZ4m2CK3GiacX0KNqsqGy1hoXL O65Sf6jU3jaOqrI7zKX16LJj7UDFcJ0/Py3d77lGSpUHJm3bM2m7P+iN+nUp5MMJAuquTb aNaHb32KH/ff5FpzABGyxC8O3D/XY7E= X-Stat-Signature: caw1mfwuz5nxpj6xxwk8zgio9pd4zter X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E7E09180136 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2022-7-12 header.b=Kujaxd29; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=0MXI4vPs; dmarc=pass (policy=none) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=temperror (imf24.hostedemail.com: error in processing during lookup of mike.kravetz@oracle.com: DNS error) smtp.mailfrom=mike.kravetz@oracle.com X-Rspam-User: X-HE-Tag: 1659632207-807016 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 08/04/22 16:05, Muchun Song wrote: > On Wed, Aug 03, 2022 at 03:42:15PM -0700, Mike Kravetz wrote: > > On 08/03/22 18:44, Muchun Song wrote: > > > On Wed, Aug 03, 2022 at 10:52:13AM +0100, Joao Martins wrote: > > > > On 8/3/22 05:11, Muchun Song wrote: > > > > > On Tue, Aug 02, 2022 at 07:03:09PM +0100, Joao Martins wrote: > > > I am not sure we are on the same page (it seems that we are not after I saw your > > > below patch). So let me make it become more clarified. > > > > Thanks Muchun! > > I told Joao that you would be the expert in this area and was correct. > > > > Thanks for your trust. > > > > > > > CPU0: CPU1: > > > > > > vmemmap_remap_free(start, end, reuse) > > > // alloc a new page used to be the head vmemmap page > > > page = alloc_pages_node(); > > > > > > memcpy(page_address(page), reuse, PAGE_SIZE); > > > // Now the @reuse address is mapped to the original > > > // page frame. So the change will be reflected on the > > > // original page frame. > > > get_page(reuse); > > > > Here is a thought. > > > > This code gets called early after allocating a new hugetlb page. This new > > compound page has a ref count of 1 on the head page and 0 on all the tail > > pages. If the ref count was 0 on the head page, get_page() would not succeed. > > > > I can not think of a reason why we NEED to have a ref count of 1 on the > > head page. It does make it more convenient to simply call put_page() on > > the newly initialized hugetlb page and have the page be added to the huegtlb > > free lists, but this could easily be modified. > > > > Matthew Willcox recently pointed me at this: > > https://lore.kernel.org/linux-mm/20220531150611.1303156-1-willy@infradead.org/T/#m98fb9f9bd476155b4951339da51a0887b2377476 > > > > That would only work for hugetlb pages allocated from buddy. For gigantic > > pages, we manually 'freeze' (zero ref count) of tail pages and check for > > an unexpected increased ref count. We could do the same with the head page. > > > > Would having zero ref count on the head page eliminate this race? > > I think most races which try to grab an extra refcount could be avoided > in this case. > > However, I can figure out a race related to memory failure, that is to poison > a page in memory_failure(), which set PageHWPoison without checking if the > refcount is zero. If we can fix this easily, I think this patch is a good > direction. Adding Naoya. Yes, I recall that discussion in the thread, https://lore.kernel.org/linux-mm/3c542543-0965-ef60-4627-1a4116077a5b@huawei.com/ I don't have any ideas about how to avoid that issue. Naoya notes in that thread, the issue is poisioning a generic compound page that may turn into a hugetlb page. There may be a way to work around this. However, IMO we may be trying too hard to cover ALL memory error handling races with hugetlb. We know that memory errors can happen at ANY time, and a page could be marked poision at any time. I suspect there are many paths where bad things could happen if a memory error happens at 'just the right time'. For example, I believe a page could be poisioned at the very end of the page allocation path and returned to the caller requesting the page. Certainly, not every caller of page allocation checks for and handles a poisioned page. In general, we know that memory error handling will not be 100% perfect and can not be handled in ALL code paths. In some cases if a memory error happens at 'just the right time', bad things will happen. It would be almost impossible to handle a memory error at any time in all code paths. Someone please correct me if this is not accepted/known situation. It seems there has been much effort lately to try and catch all hugetlb races with memory error handling. That is OK, but I think we need to accept that there may be races with code paths that are not worth the effort to try and cover. Just my opinion of course. For this specific proposal by Joao, I think we can handle most of the races if all sub-pages of the hugetlb (including head) have a ref count of zero. I actually like moving in this direction as it means we could remove some existing hugetlb code checking for increased ref counts. I can start working on code to move in this direction. We will need to wait for the alloc_frozen_pages() interface and will need to make changes to other allocators for gigantic pages. Until then we can manually zero the ref counts before calling the vmemmap freeing routines. With this in place, I would say that we do something like Joao proposes to free more contiguous vmemmap. Thoughts? In any case, I am going to move forward with setting ref count to zero of all 'hugetlb pages' before they officially become hugetlb pages. As mentioned, this should allow for removal of some code checking for inflated ref counts. -- Mike Kravetz