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 96428C52D7C for ; Fri, 23 Aug 2024 16:17:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 270B66B046F; Fri, 23 Aug 2024 12:17:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FA9C6B0470; Fri, 23 Aug 2024 12:17:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 073DD6B0471; Fri, 23 Aug 2024 12:17:13 -0400 (EDT) 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 D913A6B046F for ; Fri, 23 Aug 2024 12:17:12 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9F07780DD8 for ; Fri, 23 Aug 2024 16:17:12 +0000 (UTC) X-FDA: 82484014704.07.D948456 Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by imf19.hostedemail.com (Postfix) with ESMTP id D8FE71A0012 for ; Fri, 23 Aug 2024 16:17:10 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qMkg5UXF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.166.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724429764; a=rsa-sha256; cv=none; b=8OLB1j9/onKRSIwvsf8l/43Ea2eDohyUcRzCWxPvrl7E7N9LNFebUrFiTadIS3DG1AndtY BDd0f4c2uBkqnIT4me9IR+GgmQMRis8Z48W6QDucWiTEaJ2fqqXPoqvQWhwjcgi2xF1M0x q4KWOtKHcgN2rmK3dC0dhZ7Y3B9/hcE= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qMkg5UXF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.166.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724429764; 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=JRyBChkzDJ6EdBnp4HpZAO2Elm1XGepN3U0opL5ubIU=; b=TJSaCrvEZbzZqVCRiCXX6t/ecxTzkatdt3EGqiOZRMLvaCw6Xkuqn/l4E9PWNpNeWlL0ab NPnidLuPYi30seLPdSRLov2HCg8fpTITRa47RX9DyQFFH69Phm5mM172+gNvWiCBIPbHrb BBwW56gnpMApPJ/swqI3vRpxCo9TtsU= Received: by mail-il1-f169.google.com with SMTP id e9e14a558f8ab-39d2a107aebso199685ab.0 for ; Fri, 23 Aug 2024 09:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724429830; x=1725034630; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JRyBChkzDJ6EdBnp4HpZAO2Elm1XGepN3U0opL5ubIU=; b=qMkg5UXFV74fiIm9ktIm+ISJiAIAGwChYfojiy2nHQSdM8xlItQNNntvVG+Q81otfb kfJ83u+iFx7XgVc/CPaBajE1+g8ZJ+MklmA52PeXyLM7ezNCBo4PaDwGP8MfdtQMNum9 x7htem7edKdop0gW1+Z5lTP9s8Ip4lYKzK97ts193OxdAaXUsM89O2j4HbkDCicPsfNY ndWGGfpj31iDac52jlbsisDgxMk0pboPZWX1+5PizTnqsh/ECTDng8gOPsP1uzTTvrKy XVmbbd7nUYqUlYkdn489jolJ3bdDz59ZXjxJDR6PsHF9xNhXkf90aqUNnA/wQVzf7K7g aNWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724429830; x=1725034630; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JRyBChkzDJ6EdBnp4HpZAO2Elm1XGepN3U0opL5ubIU=; b=PRAEvzMOV3sr4+sFdc8bWJaEmJ/uSTTOQ63RniSoupAeXTVvWIwvcPn78BkgbQp+55 sBvh5p0Mfv1xQXxEFSOb5zVYYGbccHZ/uC3GYOn1C+eOkfPjF+/fjxtjqLTuxUW+5jan I+ztcbxyYB0cwJbRbfH4m0OQyUt8FKZrENctyiqjIVAAdu1bNCmfpyoMZB/8vmo6Xvdd CENilMw7sx/i2da2EEdEtdfY0gPe7UUmcxPVfYZjQOHlQMJwuZGlC5IrsiAnwcZBfM3j LwiaJtSQebqu2uT757ueG/OAES7mFPHAE2v6eNZSEb6zKWwIM3Cp4RvkhkotGkhaZxFL D12A== X-Forwarded-Encrypted: i=1; AJvYcCUwYxgTFpLtnBDgQ3p6ytLck+2n1hlGKSUaTHgVI8xx2jw0VJcfTfQIxjdI4MhQXTtcGLphu3SGGQ==@kvack.org X-Gm-Message-State: AOJu0Yyw384nROpCcRzSy041y0JbUS+J2clbCchvk7fVcjm/9HMfd/kJ JP9iRjkCbEFF4nSLg1eBdFX+HUjiTJMmfgzW6IBfpIzPgcuIaq9aZv98GY6YFXRh9/I8eq4C60o IGE84pQ+eAvWdmNzl7IIt8jMzWjyyKbkJYODB X-Google-Smtp-Source: AGHT+IH8wuwWOfarZTVY3YLjuN0ypve1B5twUBatzYsj4K93vqQwsdzwVWr8fUx2i+lMfTFoiVulVkZnnkD3rHMAzTc= X-Received: by 2002:a05:6e02:1649:b0:395:e031:6c1f with SMTP id e9e14a558f8ab-39e3c5250b6mr2841165ab.27.1724429829298; Fri, 23 Aug 2024 09:17:09 -0700 (PDT) MIME-Version: 1.0 References: <20240822025800.13380-1-hao.ge@linux.dev> <292d1141-4edf-ee60-a145-4ca06600076a@huawei.com> <50e74f28-5165-a45b-c152-1b18f32e61aa@linux.dev> In-Reply-To: <50e74f28-5165-a45b-c152-1b18f32e61aa@linux.dev> From: Suren Baghdasaryan Date: Fri, 23 Aug 2024 09:16:56 -0700 Message-ID: Subject: Re: [PATCH] codetag: debug: mark codetags for pages which transitioned from being poison to unpoison as empty To: Hao Ge Cc: Miaohe Lin , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D8FE71A0012 X-Stat-Signature: b9bsqa18osb33o3wk75uytmimueuwqpu X-Rspam-User: X-HE-Tag: 1724429830-730050 X-HE-Meta: U2FsdGVkX19E9NOTZDMSyINNNCIv9ej55PfO+AzRoZjyu+OVHCUPSiCAFhijW/2dM2yo+9h3sspANrl81/XXcp17RrXVbFGNMqZvA88YxHRwHo/jFXYVO3Y5oHJ1uMWkkv1bii4FusIh5stQ4Ii9Q36PjEsvE3aU9h39ddHMQKOOrIWmnX0WiL3tkNzBCoeLKUz/5Zg7fPRknwTCIkIhlLawZLqfjtmJ1zWE2/mPyjD3tcbk1fNbQ29UWq8TBjzsUkv52o7nswtmPyh1wJH08tXSNFQ1WwKu/atK/HeRcT0DeecP8nmGAwGlcXRpHyKOJEvGC95+jDSCHQ+z8bK9RbDzfI8QC/EDmcfgrmmpEKQnz4WIoLm2SZqhmxwK2VnDu4T4omQeOMxgWYJ4u+cP8Nw84+bYOQY6fb9SLogHWb+H1Lb/ZtGOqQ7RG6+9pf5y+zfqajbk7MJk5mF+1/qbLxB2SRI2QVs2csHakeA8ynzTUnnys5atdAC3IR8cYziKtA/MKmwmPPLMQF5gmjhO+GdqS4fMUJ3zRIfMxruQ3HA1pYhIAJSQuTGDPaBaZON9HG6AzBsgJf8YTv6zK3FrmEu/YBzqLD2vOpX9ZLbuzp+Ck1cpfqhDPSTJcaf60DGAh8fSEkDMLQejOD3FKCdNqSJ9p7ZtcWDWcJJVSd8tUoYRnIR6pXLmOQyzd1Kwg2aRcAhBP/aR12HNV7weX+itQAEHJuPGB6PhzA1X/Y3R2t+bKFQiOG+5XJhypzgjevMQr348hm78ueOMkDPvjphlGyoZduqSXY5d++HtWPBc0g8Xe7l2HrZbwgwl3nzj+wZTkEtVjIvGHMNl+mihTAHe62Hds9QN169kgcE6w7opvB3h8yktzMLtPtQcyqtTZiN6Pc1gbLgZyXlx1KY2mA5zeD8sidb4XmSHOb9xznvKl94CpPe7IFOxDRwOuyBIBDAAthpi8fBhaDun4NdXPi/ 0JGpupb0 tFW70KYHQK4uvhJQ7vPU3OycLjneTNO6hB/jNrHAOShriiQBGrmVlknIpomcjkxm92J6P02T3sZjRK7kwXPqM+u6tuaNtm1zNkHQU3lfyBn2L6+Bj/mzAOV+pKq8PRgeIl3ouYiW9D3xzDJMV15vHVz9FyqTWAh5cuR7Vv7JAxNhhWqDx7CXGRW61htffhws7FKOHrlP3lRI6J1cYvQbNTLxkdP+ZtBoQZxEbuEBzdWpCl4S49Y0gT0ZA7142T69SpnFvYl3R/7Wn12yV6ZZeAtlVQX0S76347nTLcsWZy45C+sFNrer+nrneuy2AFycYnueBY0xz+iZinzOs0zV8AYuUjdlMGz9YWIeN2dJGxd7Cen8= 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 Fri, Aug 23, 2024 at 1:10=E2=80=AFAM Hao Ge wrote: > > 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=E2=80=AFAM Hao Ge wr= ote: > >>>>> 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 i= t > >>>>>>> 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 fla= g 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 sen= d the patch.look this > >> > >> https://elixir.bootlin.com/linux/v6.11-rc4/source/mm/page_alloc.c#L105= 6 > >> > >> 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_pa= ge_tag_ref() > > whenever page_tag finished its work. Do you think below code is also ne= eded? > > Actually, this is not necessary,It follows the normal logic of > allocation and release. Yes, we don't need to clear_page_tag_ref() after every pgalloc_tag_sub(), only in this special situation. alloc_tag_sub() resets ref->ct to NULL at the end, so not clearing the tag allows us to catch if an extra alloc_tag_sub() is called on this page later. > > 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? Yeah, that looks good, just spelling in the comment needs fixing. I'll comment on that patch. Thanks, Suren. > > 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 pa= ge *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. > > .