From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B8AB721CC4F for ; Sun, 21 Dec 2025 08:49:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766306974; cv=none; b=NkXZ19/vw6u5NzQdb6AcMQa5g6+lq57wAMzC8oDboRS2oOVfFKvcg0nyQ2kAC3OaG2T4ncsMDfMCCSKePzfgK674wQOd4IFHVBW/JWf30rC1ZU6gCwo1k3mxAIugen4rU5+sk1ECfV6exUkhe74dWNLucWO05KhMEjxPk4Jy/Xo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766306974; c=relaxed/simple; bh=dTdOmrxX3GbIoyyhepzZvaLNQrFrNZvGnXmKqjQ1kRM=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=Hj0EUWrqdqJfQ2hPN54LCCE93KnsSxeExtXzGB08esSMMS8bRHAiP7OoG8aE6jJor8rWZVrvL5CDEZFamGTIlXBtIjq/B2nYV5OmXsMyjf9g6hfks/tdlsDD7MPf2BMMIKe3Ban4D0L38QDMbWaNZCafG1/W9BrM6yQlu70DeVE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lGbri52D; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lGbri52D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D00A3C4CEFB; Sun, 21 Dec 2025 08:49:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766306974; bh=dTdOmrxX3GbIoyyhepzZvaLNQrFrNZvGnXmKqjQ1kRM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=lGbri52DpK790+FW93/VGnkQTq9SDWFYa+JzRn3mxKi/GVQX8MFhL7kV7qYz5/1KG 0k34oPK83TMAYySonVlotv3Fw4xvEYmdHFeACMo6lXhgOkyNRhGIDWBm6jqQgF+pnv rhvTM5WAL+35FSECT79LEa5D4LRal2EewobmK8i0k0JAlanSNF/Q+95uGxR5BmiakB viTTatlNijFz+yF6YZVLouiVramFw5XXRPiNydEHcpTrQzI+ZIfWA5oU0CMI9z4bQ5 XD7cJ/IuiMHs32exlF+RxfbBaOx/uOWWkLWm2ec0jgjvhZ+xDlxGhpYlxXpWYS+qSP K+f9CpB2S31pQ== Message-ID: <8b8dd99e-78b8-4786-a175-6131eb6b7c3e@kernel.org> Date: Sun, 21 Dec 2025 09:49:28 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/memory-failure: teach kill_accessing_process to accept hugetlb tail page pfn To: Jane Chu , muchun.song@linux.dev, osalvador@suse.de, linmiaohe@huawei.com, jiaqiyan@google.com, william.roche@oracle.com, rientjes@google.com, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, Liam.Howlett@Oracle.com, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20251219062819.2499399-1-jane.chu@oracle.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251219062819.2499399-1-jane.chu@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/19/25 07:28, Jane Chu wrote: > When a hugetlb folio is being poisoned again, try_memory_failure_hugetlb() > passed head pfn to kill_accessing_process(), that is not right. > The precise pfn of the poisoned page should be used in order to > determine the precise vaddr as the SIGBUS payload. I don't think so? IIRC, for hugetlb folios we always reported the head PFN. And user space must assume that the whole thing is poisoned and will go away. I recall that older QEMU even depended on that behavior, for example. -- Cheers David