Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <f6f7bca1-8ba2-b205-570b-8d614a4a8f11@oracle.com>
Date:   Mon, 21 Mar 2022 15:46:35 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: [PATCH v5] mm/hwpoison: fix race between hugetlb free/demotion
 and memory_failure_hugetlb()
Content-Language: en-US
To:     Naoya Horiguchi <naoya.horiguchi@linux.dev>, linux-mm@kvack.org
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Miaohe Lin <linmiaohe@huawei.com>,
        Yang Shi <shy828301@gmail.com>,
        Naoya Horiguchi <naoya.horiguchi@nec.com>,
        linux-kernel@vger.kernel.org
References: <20220318051612.271802-1-naoya.horiguchi@linux.dev>
From:   Mike Kravetz <mike.kravetz@oracle.com>
In-Reply-To: <20220318051612.271802-1-naoya.horiguchi@linux.dev>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N05haHVMb2Zoem9OMHF4WHd0NnBPZEx2WlhUNXFLbk9wL2Q0WWNmNXVQdSs4?=
 =?utf-8?B?REM4UGJGTlNIRWI5K1JXTTMwNnkyZmhaWm03eHFrMXFlRllEdXBMcXVrUys3?=
 =?utf-8?B?VkYvaFBsaWZ3dHY2VSszOGMxeGt2dVlSWk9xbDgrQTZmek9EcCtBcXpJQVcw?=
 =?utf-8?B?RTdvaDIvK01DSE9nNzZ0TmlYT1QzTW1NNHdDcTgva1BTUmlFekdwVjFXYW1D?=
 =?utf-8?B?bXd2QVNlZDFtbmtvSE43ZHhQT0EwTk9QY2t0ZXlnODhHMGxSa1FUQVBldklY?=
 =?utf-8?B?NmttbHJpeUlZNEhpQ3YvYWM5cUdEdjBUMFN5UXJ5SjJqVXNPSkU2VmgxYXdP?=
 =?utf-8?B?eWJ3QTZhMy9OWE4rUlRvbE82V2pZQ3c4dFhzS3BkQ1k1Z1lWc203RWtaVkV1?=
 =?utf-8?B?Q01KZkZCZjlPRy92ZFk1bnJyN2lFOFdnL2Fpd0JVTWQ3TDRuS1JmNnczaVpm?=
 =?utf-8?B?Qkd2aC9YZ2JFQ1k3ZG4wL2orV1BLenZXYnFpZm9ZWTZ1bHpzd1oxZ0tFK3hq?=
 =?utf-8?B?dmxXajBJZWdtVkJwTGdqUTgrYUkxNk81T24vcTZLdFBGUVAvV3B6eVQ3ajBI?=
 =?utf-8?B?L0RoVG9KK0xjRzdkMDltc1BzMnZQY0RCWkVYSGlsRXc4WFNhOHlUREVrZW16?=
 =?utf-8?B?MkpQa0JFMnZaMWVsNFU3eWRGYU1FcHFuaGVhd0pVc3Z1N3ptdHQzVXV0c1c0?=
 =?utf-8?B?aXFjbG1YVm9wWVlqQ2U3ck5ibXBCU1BHcFdFMzdEakNiNFhaMHFENWtpUzdV?=
 =?utf-8?B?R0ltelhsVnRFajlQK3A2VDZ6VlJ5SXAxUWFXUHhoRk5Xenk5NDhBYzgwT2w3?=
 =?utf-8?B?UDlYZXpIYnkzSzJLcHQ4REdaU1hUaGozV3V0UnRWNjlNa0pySmZ0TUlNazAv?=
 =?utf-8?B?WW8vK05oR0tYNFRIS0RPakJwakJ2bUszOEgycjNIaERKL2F5TFhId3dYbXpl?=
 =?utf-8?B?Wmd2SUJyM1pSYnQ1NzFIaDQ1SFFQMXAyS2hWRFZVUC9nV1d1eU5zR3NhT2dm?=
 =?utf-8?B?bDB4b2FiWHhNYnRWMVFzQ0J4REhBZFhjdEsrNHNMMXNmSHh0cHhUZGdrdHA1?=
 =?utf-8?B?TjVOSXJqUlg1a1hCbUV2NkRyY2IrYW4vOUVzL0Jzck1uYzBtSDdhK0hrcVdS?=
 =?utf-8?B?ZWlaMW91ZGRDc3RtdHJGVkY1L0F1Y2lCR09SR1p3dUhLbVQ5bEs4U2NpbHhK?=
 =?utf-8?B?NE1vTUJsUnlmSnlHcXpxKzVQUkRGdnYvTDFOejErTzU1T25kSmRZM3VSbk9Z?=
 =?utf-8?B?U2E0N1Vyc1E5Q3RPd2NscDUvTVpYM2pBVUJ5ckt1SkJTUWhlZGNBT3Y4a0ha?=
 =?utf-8?B?UjRWd2VmbHZ1aDhSSzA5TllsanRGV0dKbGMwSWYxNXE3OVRMNXVxd1JSTHk5?=
 =?utf-8?B?SjMvaFlrNG53UUwybW5DQlJpUG1YT3JXMnZuQlRjTDRyd2VuT0d0TTZNa3Rv?=
 =?utf-8?B?bFZoenpOYjNuV2hMMUhYTDQzSDdSTFJyc2NuNGFObmxMK1Jya3BteXM0U0Ji?=
 =?utf-8?B?NjNxK0QvUkFBNXpCbHRiYlNEOHNqYmxSclZIWmFOeTh2R1E5R08rRlpoZ0JE?=
 =?utf-8?B?Vlo4SUZoYU1pNnFacXlhNVZJK3VhRExxZUk4amZvc2Y5MUxBUHdjblI3V08x?=
 =?utf-8?B?d2ZjWlZVeDhuamtDejlsVTZlVU5vaTdKUmRQZDJHUnJ2K3hVT3ZFQWs5aVQx?=
 =?utf-8?B?amVVL2N5Vm9scURaQnovMUl4Z0doSUlIQm51aXgyUjdpcVczYlZwR2Y0UHhN?=
 =?utf-8?B?dkE4cDNpNnpoUnNPRVRyUTQ4S284QlovRElSWWVTREpzaVA5SHNKWk9Yd3gx?=
 =?utf-8?B?SmwrbnJCcXZzMitGL0tsUFB4Wklxem1POWJhS1o1K1RMZDIzMGRRVmp1MVJI?=
 =?utf-8?B?RWZXVWRER3VpaTVsUk5JUUUzbHlWUEZkWHdycFZUNzJvK3AzYklETzkxd0dh?=
 =?utf-8?B?SjhJRGJqTmU3dkkybUJGSzZiRk95ZWZsYWl6Y1FpSHRad2QyeXVlSGw4N3lC?=
 =?utf-8?B?dnNCUGhmVVN3PT0=?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6df8abeb-1046-40b4-86c1-08da0b8ca8cd
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2022 22:46:38.4995
 (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: S3QsJWEdWMmA6y8QT+cwQkdKPxI2A7DoE19dEkna9tLWj1e+3JH6I3aKAxY6aLm0G9Z+TNtmagD8bJcMBUl5tQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1428
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10293 signatures=694221
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0
 mlxlogscore=999 adultscore=0 suspectscore=0 malwarescore=0 spamscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2202240000 definitions=main-2203210142
X-Proofpoint-GUID: GewV-R6f4eMpzTL3mSwlHoq5kKvrJLVV
X-Proofpoint-ORIG-GUID: GewV-R6f4eMpzTL3mSwlHoq5kKvrJLVV
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 3/17/22 22:16, Naoya Horiguchi wrote:
> From: Naoya Horiguchi <naoya.horiguchi@nec.com>
> 
> There is a race condition between memory_failure_hugetlb() and hugetlb
> free/demotion, which causes setting PageHWPoison flag on the wrong page.
> The one simple result is that wrong processes can be killed, but another
> (more serious) one is that the actual error is left unhandled, so no one
> prevents later access to it, and that might lead to more serious results
> like consuming corrupted data.
> 
> Think about the below race window:
> 
>   CPU 1                                   CPU 2
>   memory_failure_hugetlb
>   struct page *head = compound_head(p);
>                                           hugetlb page might be freed to
>                                           buddy, or even changed to another
>                                           compound page.
> 
>   get_hwpoison_page -- page is not what we want now...
> 
> The compound_head is called outside hugetlb_lock, so the head is not
> reliable.
> 
> So set PageHWPoison flag after passing prechecks. And to detect
> potential violation, this patch also introduces a new action type
> MF_MSG_DIFFERENT_PAGE_SIZE.
> 
> Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
> Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> Cc: <stable@vger.kernel.org>
> ---
> ChangeLog v4 -> v5:
> - call TestSetPageHWPoison() when page_handle_poison() fails.
> - call TestSetPageHWPoison() for unhandlable cases (MF_MSG_UNKNOWN and
>   MF_MSG_DIFFERENT_PAGE_SIZE).
> - Set PageHWPoison on the head page only when the error page is surely
>   a hugepage, otherwise set the flag on the raw page.
> - rebased onto v5.17-rc8-mmotm-2022-03-16-17-42

Thanks for all the updates!

I can not find any issues with these changes.  However, this code is
very difficult to follow/understand.

Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
-- 
Mike Kravetz