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 DF765C52D7C for ; Fri, 23 Aug 2024 08:10:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 15D526B016C; Fri, 23 Aug 2024 04:10:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BDDD280001; Fri, 23 Aug 2024 04:10:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5452280002; Fri, 23 Aug 2024 04:10:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C4954280001 for ; Fri, 23 Aug 2024 04:10:15 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8809DA1B99 for ; Fri, 23 Aug 2024 08:10:15 +0000 (UTC) X-FDA: 82482787590.30.182B1F2 Received: from out-185.mta1.migadu.com (out-185.mta1.migadu.com [95.215.58.185]) by imf18.hostedemail.com (Postfix) with ESMTP id A99801C0010 for ; Fri, 23 Aug 2024 08:10:12 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=awlyk1I3; spf=pass (imf18.hostedemail.com: domain of hao.ge@linux.dev designates 95.215.58.185 as permitted sender) smtp.mailfrom=hao.ge@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724400530; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Bn5wnRQMXm7eArEe25VtPGx5Zc8qNdSU3gOpFjda3wg=; b=c/OP0KeHVK/lElP8W6N09cdL8z6LnkI7SZmiPWI/IOA1OdpX/ElvyG2zI3v3hJKdUQHkwt k3+k5WAfXuXH3IUd648zQgBk4AlX2105yiiXgMpFK/HGIYdl2ebtbYfYoQFpSBKlL2hTk3 4ObboX/cjJ9aOPAlA7wj6ejhp4eDZ1k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724400530; a=rsa-sha256; cv=none; b=VuH3emFFgWDhe9U0ulonwiclYrYV0mnzYUA7YXrTFzkHQu956ztPjQ9/ut5SvOjg2nxQoD psMnn9hMGHXexljC2ry3i1GSmU/eVzpkes3KDn01a62veV9ZJwFS03+kCh1m27h6gaf8qN kRXNlBrsFPV6VFFgPxqBa4me1QpIbG4= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=awlyk1I3; spf=pass (imf18.hostedemail.com: domain of hao.ge@linux.dev designates 95.215.58.185 as permitted sender) smtp.mailfrom=hao.ge@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: <50e74f28-5165-a45b-c152-1b18f32e61aa@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724400610; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bn5wnRQMXm7eArEe25VtPGx5Zc8qNdSU3gOpFjda3wg=; b=awlyk1I3N6cP7oTTHLeOQOg2RO5uKBvPfy/elRoHHXEXrJ3oQMVRYY7xC2hj7/c0N8diPE xNVhPx3SgwH0ypvV7gGO8id0bj0C/CoYV9qC3f/EFxbKHqz4w+FnQBNMYOzy8SGavcDh+Q YLkUwOhbdr4BpR5GUspF5V5P77H/kAo= Date: Fri, 23 Aug 2024 16:10:05 +0800 MIME-Version: 1.0 Subject: Re: [PATCH] codetag: debug: mark codetags for pages which transitioned from being poison to unpoison as empty To: Miaohe Lin , Suren Baghdasaryan Cc: kent.overstreet@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hao Ge , stable@vger.kernel.org, nao.horiguchi@gmail.com, akpm@linux-foundation.org, pasha.tatashin@soleen.com, david@redhat.com References: <20240822025800.13380-1-hao.ge@linux.dev> <292d1141-4edf-ee60-a145-4ca06600076a@huawei.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Hao Ge In-Reply-To: <292d1141-4edf-ee60-a145-4ca06600076a@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Stat-Signature: ucfq1jz9b4ofseff6au7pk7rtiwsi3kd X-Rspamd-Queue-Id: A99801C0010 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724400612-248079 X-HE-Meta: U2FsdGVkX1/QTcP28dmqP+o9rxFqQDvnEdl0NXgO1EaQt0S+CnNFGa7JhLW7b44N8A/lhLTvv8qgZADaLG7Mm+W6PwIE+1q9GunY5IXDcLR2biSlT1HJXRcjqpbAqdLM0HjW7volM+fULRDlyTfQArqPOGus8cIN8h7TR4Ot8KgfP5G0nDaTENQRmEBFo6lAoCXpDo/+AEsEON8yc8RE6MbvXLSbPlvVbeQ816ejo4maMcgFPNJL/ss7Pb7H0EDxg7tD6nXxJjsFpv9v84xJwN5PzI8uyFbDdsNch18y19uGffgxJu8RAqkNYPpEYz8gZCRrfbF+f5INccs0IIZeXg1/Rs+YQi6KN+2ycL1VCaUfoO+VntH6jzmwm84eRfBF/jJ6lh6T1n1u+oSedOLGuYl4eq+1sGHIFm6U0BtOPqR92E8FYrDibMJtNM1D6FADjXhYeIWi4TtE5GkFNaEA6ZC+VOnPYhldc9lzA+BAOK7T4LRJdM2X/MNsrbxxNk/+MpljxyANFQS0YKwjJ0OGBUDTh2EVYPk5fa/VhSYzGpbkRESnFtfQrl7mLVIeCqmcc+xKbUXBw6TFCB9H6mMPp4kuggOBrybp0bdqC6aOPF2dxFTGmWUaZ68Z6mY6xe07+XCzCCuYq6xd7V+UF9RZ2REyjYVdcinOzwphC/ydc4m2G9i65Fn+Nc4zbPFzC9eaBxiQDLzFDxzoGJD5JMPJIRAsLdcKCWREAqsJeoPlPR2eAs/2zzPtcZKQS6CbHvm22wHC0pjihMlbTk6lG7ncrJfYgTkMjWFi2MhytyCAuZXLM26ANtQR5YBaYt+hal0Y+lXfJOgcJlFHhBzGag+Z2Z0MxE4MhJPD1VLKWekaeYITKRMhOtf+6+SaXsMb0AVwRPwnkPJDnEeQJhkav8GLzvGw+sD2KZBb+8MqlLZJsTHu2cOTId5geRPgsIbEFZSPmuaoTX/HTG+69/D255B tapxg61K dLBKKDjkPvn0mRkpKxZ3ZOhN5lG+H7dS001LFIvlMDq+Wp1AxCXuQBq1tqQaX4+M5a/w2Eu9G/+Xp3clgewrzIg3s7pMBgDPhrGY+8PuPbfFoRjYjlyQW65lbsA8nrYGC2G6aI6lhJ72s2XykrcAjhLtPz8K6KU1Kkqi/Eo5VJ+kX79JRwo1E2ymcDPy+JLI/zjj3Ap+lJ+keYIQlsZGSNDa2b9HdbbrU2TrCx7TDm2B+zL7f8HnlW1tHaLHG7Q1gj4s8N63NiX7+AfKlEzeR+FtGohKzBLwlAG5TFl7gby/JsUoddAz1bovJKH3yrRMBT2Z6BxdDn7DJCvbdVJrNV9pOCw== 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: Hi Miaohe On 8/23/24 15:40, Miaohe Lin wrote: > On 2024/8/23 11:37, Hao Ge wrote: >> Hi Suren and Miaohe >> >> >> On 8/23/24 09:47, Hao Ge wrote: >>> Hi Suren and Miaohe >>> >>> >>> Thank you all for taking the time to discuss this issue. >>> >>> >>> On 8/23/24 06:50, Suren Baghdasaryan wrote: >>>> On Thu, Aug 22, 2024 at 2:46 AM Hao Ge wrote: >>>>> Hi Miaohe >>>>> >>>>> >>>>> Thank you for taking the time to review this patch. >>>>> >>>>> >>>>> On 8/22/24 16:04, Miaohe Lin wrote: >>>>>> On 2024/8/22 10:58, Hao Ge wrote: >>>>>>> From: Hao Ge >>>>>>> >>>>>> Thanks for your patch. >>>>>> >>>>>>> The PG_hwpoison page will be caught and isolated on the entrance to >>>>>>> the free buddy page pool. so,when we clear this flag and return it >>>>>>> to the buddy system,mark codetags for pages as empty. >>>>>>> >>>>>> Is below scene cause the problem? >>>>>> >>>>>> 1. Pages are allocated. pgalloc_tag_add() will be called when prep_new_page(). >>>>>> >>>>>> 2. Pages are hwpoisoned. memory_failure() will set PG_hwpoison flag and pgalloc_tag_sub() >>>>>> will be called when pages are caught and isolated on the entrance to buddy. >>>> Hi Folks, >>>> Thanks for reporting this! Could you please describe in more details >>>> how memory_failure() ends up calling pgalloc_tag_sub()? It's not >>>> obvious to me which path leads to pgalloc_tag_sub(), so I must be >>>> missing something. >>> >>> OK,Let me describe the scenario I encountered. >>> >>> In the Link [1] I mentioned,here is the logic behind it: >>> >>> It performed the following operations: >>> >>> madvise(ptrs[num_alloc], pagesize, MADV_SOFT_OFFLINE) >>> >>> and then the kernel's call stack looks like this: >>> >>> do_madvise >>> >>> soft_offline_page >>> >>> page_handle_poison >>> >>> __folio_put >>> >>> free_unref_page >>> >> I just reviewed it and I think I missed a stack. >> >> Actually, it's like this >> >> do_madvise >> >> soft_offline_page >> >> soft_offline_in_use_page >> >> page_handle_poison >> >> __folio_put >> >> free_unref_page >> >> >> And I've come up with a minimal solution. If everyone agrees, I'll send the patch.look this >> >> https://elixir.bootlin.com/linux/v6.11-rc4/source/mm/page_alloc.c#L1056 >> >> Let's directly call clear_page_tag_ref after pgalloc_tag_sub. > I tend to agree with you. It should be a good practice to call clear_page_tag_ref() > whenever page_tag finished its work. Do you think below code is also needed? Actually, this is not necessary,It follows the normal logic of allocation and release. The actual intention of the clear_page_tag_reffunction is to indicate to thealloc_tag  that the page is not being returned to the buddy system through normal allocation. Just like when the page first enters the buddy system, https://elixir.bootlin.com/linux/v6.11-rc4/source/mm/mm_init.c#L2464 So, can you help review this patch? https://lore.kernel.org/all/20240823062002.21165-1-hao.ge@linux.dev/ > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index de54c3567539..707710f03cf5 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1104,6 +1104,7 @@ __always_inline bool free_pages_prepare(struct page *page, > reset_page_owner(page, order); > page_table_check_free(page, order); > pgalloc_tag_sub(page, 1 << order); > + clear_page_tag_ref(page); > > if (!PageHighMem(page)) { > debug_check_no_locks_freed(page_address(page), > > Thanks. > .