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 EC233EB64DC for ; Fri, 30 Jun 2023 20:59:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 054438E004A; Fri, 30 Jun 2023 16:59:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 004408E000F; Fri, 30 Jun 2023 16:59:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0E628E004A; Fri, 30 Jun 2023 16:59:37 -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 CD30F8E000F for ; Fri, 30 Jun 2023 16:59:37 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 87DC9C0115 for ; Fri, 30 Jun 2023 20:59:37 +0000 (UTC) X-FDA: 80960630394.07.6DBD3DA Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) by imf04.hostedemail.com (Postfix) with ESMTP id A3E2840014 for ; Fri, 30 Jun 2023 20:59:35 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=XOy89UpZ; spf=pass (imf04.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.128.179 as permitted sender) smtp.mailfrom=jiaqiyan@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688158775; 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=htaQAn0uld1gRzcRPOpYgkB/211lBPerbZN4rs35mJs=; b=i8hgl4z93uHQMfZjubRD45vUafrkfk4I6+8gmNHM4gqyeSy/ebdwDNp0Dc+8Gh09x+Tsjl i/iejfylF7e450PjTeIm+viG9Qz1mfFGsnv44LlczDaa2OnqCkrZkF6mFTDop96BhxA2++ xfXXdyBcdnzWGbM8gqiqlef8TXPcYxk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688158775; a=rsa-sha256; cv=none; b=PYWaMq/tnJ3ZOEUHf6ia28Uqx9PexIrNd2W0oUNUneerR+AFIdQlfHPKKsYxHtO2O/vmvr MSmMvVvt0n24Fcy/y+771hQWy/5viwtbm148O6zpyjWTc3MyfLKpJN8yRcfLLosIG9UyRP 9rsG9X0uywgJXx8cMJqAyRFD+PCofKQ= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=XOy89UpZ; spf=pass (imf04.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.128.179 as permitted sender) smtp.mailfrom=jiaqiyan@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-57725e1c24bso25623087b3.1 for ; Fri, 30 Jun 2023 13:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688158774; x=1690750774; 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=htaQAn0uld1gRzcRPOpYgkB/211lBPerbZN4rs35mJs=; b=XOy89UpZ3ktzJ2RHAFbO3jk29h41leDaxvLHRKDZhDZhGgq2bhSqHwliKtytlzcap1 qk5qFq8MLFn+Kw948uWoIXHEY/VDGiiuLCM6At60qTx3FfskH+ZrUwV0ioM51zt6Q50L xUTZ42BEj9NjEgfaWDYqRexX7MlWix9NwNPX5kVrCy/RFCd7ZYzGRROj+iqgklQH2dcp 8huGga/08rIoSSbjxMnSe5T+2PJo4c05o+IwfypFmUeEm5CJqcO71E69KrFoGX4OfCKF CrOXK7YV7aI5k8097KP27RbfrKEQfcm3lvqVqQFLa5ADz2PkLv4zjrdclleJpN817C4a GnrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688158774; x=1690750774; 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=htaQAn0uld1gRzcRPOpYgkB/211lBPerbZN4rs35mJs=; b=btm+84cjiGZkRNhEQjKfW5C8hqBolYa8Gub7PQVhxsQ8+wB3lSS7x6uiLCsTSC98Y8 vaIJiHkVZdpv42hkRYcNuEMPuWomRbqQ8z97MSi+BbHuCA3+rPgG692gLgGm1schzoCs ukPG52USWyAxei7ztCt2n4DgOETmqJw+napci070YzpRFcHgRAtSyry35GKHBDj/Ovll 01axDwq/u5f1dPttTUsooT3vi6s5fYjt6VPruL+w3/chJ9zMeswcPX+79X1KxuUxM+qG r/byO+UdxiuPKDa7PO04mdrhtcO7ReK181+S9+NxNVcjlfv7+sVr2YFhgf8uGXDmJ/5r eNwg== X-Gm-Message-State: ABy/qLYPvgJGnwS9km6ktR4GapzqeJyYjBSl5/66Bs/WMifSviLQx1Ox JeZB1Ac77Gy1kzoFK2Fi9SZDrVGELJPwZMNj8JkjOQ== X-Google-Smtp-Source: APBJJlGWvQImsRpqU9abwLuPZ+Fv4ioP36u/BXqVT4sig4o5DeHL/HagtPVLJyENRM1nAyQEZg8Xk+jECQVTLh4Luoc= X-Received: by 2002:a81:a149:0:b0:570:6654:68c8 with SMTP id y70-20020a81a149000000b00570665468c8mr3837105ywg.1.1688158774568; Fri, 30 Jun 2023 13:59:34 -0700 (PDT) MIME-Version: 1.0 References: <20230623164015.3431990-1-jiaqiyan@google.com> <20230623164015.3431990-2-jiaqiyan@google.com> <20230630145217.GA2213127@ik1-406-35019.vs.sakura.ne.jp> In-Reply-To: <20230630145217.GA2213127@ik1-406-35019.vs.sakura.ne.jp> From: Jiaqi Yan Date: Fri, 30 Jun 2023 13:59:23 -0700 Message-ID: Subject: Re: [PATCH v2 1/4] mm/hwpoison: delete all entries before traversal in __folio_free_raw_hwp To: Naoya Horiguchi Cc: mike.kravetz@oracle.com, naoya.horiguchi@nec.com, songmuchun@bytedance.com, shy828301@gmail.com, linmiaohe@huawei.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, duenwen@google.com, axelrasmussen@google.com, jthoughton@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: kmrdzutxz6cirnzsrkopzba4d9zb5t4o X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A3E2840014 X-Rspam-User: X-HE-Tag: 1688158775-473120 X-HE-Meta: U2FsdGVkX19d4FAYuODbHpZREtWPQuqOocN8+Qx5OiTweWGrV1b2YU+2xCf7S63kW0Z5EV2sXncVyBc6OPxijKKwV/e6VdkmUw3AKr9RLzzj+DlG5efzTuY/RoI6ZgJqZPAfMGHnFw48+1TtDuP0c8agZfKWPyIPEdwbEiGfLr+jj4eMiUFXPdW2ONZmxfWkBUU3JNy+jKgqlENAplKViVgWKvcXsH/SzEiiLg3O2S9YcmHMCaX1Kx+OfbWTBRp8RT4uw2EtklQviVOfbUDYiDwC1u28eYvCgca/9PRNfkdw3pojOvusos7dATU+R36Wc82fqLz6alk9JtBs5SgZPaLryErXp1AZfe76knQfPkly1sLQg5GtJq0B3+E1c/TKMWUd40i4/8hOVUID5rRJAC8/5Orw8pDFF1Rhx6cgiwTALk93RsonZuhgngO1T6gUOnCYiUTQa+7zDCZx5cZy50ezibKEH8bx2O1ruJ7Q1B4EQ2+Z+adn8acDAHD6aAsEowZkzz61R1Wp/gNRQA0Z3nPhrAnOPJMm/IPIBkAulHe72oSJYZeT4RDmm9LNF10rOTXpAI511vCQmnlL+H3FMb6rZkz0/r9vRjAGB0h2h/XEPA1ozBrwvE2FjnWWR9aH52kBkPZE62RHbD2TkvjUl8xllAg2oYdum7pZOpSF0HcQ7MVOjQg8SMbjkMAz14KHCdY7kpLcDgAC3q0/BgyMGGjNh5E7RBO2jM1TleI83TKDf+m462oTDIGg8pfKgUWcLh2hhHdStjUW75Fo6WX/YcnDu42jClH9Pnk8tDRhpw4huL0F8M3/67P5LeXppsSfBZazHE4d8fC2/BKomhnChlb+3VJZf9cUVofTvc7tmw9UbKjYDq9VBcqBDkZK5RsgApTOrJdex1zsEJvRTEF8eZz7skLf8Hv/mFsbeN7wIK2iNYrnk/grX3uUQYtdjt5H2hjZpAwKR8sgYgFnYYz E9RZsZcM Tb9uOUhiVjljui/jqa+RPqjin2CC0coSLtRU9TG6H8rj8mY18InKJDR0dHuK/rXQ5joZ2jevHMaH09psrQIU2ADDmFanZ+chJ4FvM1I4uMT8PEZjmleaAykG8uSB/2ot+4sRmFqzRe3CdiohvEyE1DPcPRoBPCpBJK4bDPgp6zuu8mOJPYImGo0PFzqbDFSWm/rlYxvEs99kpJlF6jNczG6469eGbGDia2q65C+3KHmHjNha0085wbpUHKqusfubPOLNiGkAiRXd42jzcuUy/OoRaMCQxe4+wwJLloLBb2aUHN5hB3t4KLn+rK/zp63WD+CSKqHTNHpUD6a+3bUE4DVJeLUV/vJLNqoLLgZvt4olcx117pGd9O3Tfq6p1xjKdfAw5 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 Fri, Jun 30, 2023 at 7:52=E2=80=AFAM Naoya Horiguchi wrote: > > On Fri, Jun 23, 2023 at 04:40:12PM +0000, Jiaqi Yan wrote: > > Traversal on llist (e.g. llist_for_each_safe) is only safe AFTER entrie= s > > are deleted from the llist. > > > > llist_del_all are lock free with itself. folio_clear_hugetlb_hwpoison()= s > > from __update_and_free_hugetlb_folio and memory_failure won't need > > explicit locking when freeing the raw_hwp_list. > > > > Signed-off-by: Jiaqi Yan > > (Sorry if stupid question...) folio_set_hugetlb_hwpoison() also calls > llist_for_each_safe() but it still traverses the list without calling > llist_del_all(). This convention applies only when removing item(s)? I think in our previous discussion, Mike and I agree as of today's code in hugetlb.c and memory-failure.c, concurrent adding, deleting, traversing are fine with each other and with themselves [1], but new code need to be careful wrt ops on raw_hwp_list. This patch is a low-hanging fruit to ensure any caller of __folio_free_raw_hwp won't introduce any problem by correcting one thing in __folio_free_raw_hwp: since it wants to delete raw_hwp_page entries in the list, it should do it by first llist_del_all, and then kfree with a llist_for_each_safe. As for folio_set_hugetlb_hwpoison, I am not very comfortable fixing it. I imagine a way to fix it is llist_del_all() =3D> llist_for_each_safe{...} =3D> llist_add_batch(), or llist_add() within llist_for_each_safe{...}. I haven't really thought through if this is a correct fix. [1] https://lore.kernel.org/lkml/CACw3F51o1ZFSYZa+XLnk4Wwjy2w_q=3DKn+aOQs0= =3DqpfG-ZYDFKg@mail.gmail.com/#t > > Thanks, > Naoya Horiguchi > > > --- > > mm/memory-failure.c | 8 +++----- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > > index 004a02f44271..c415c3c462a3 100644 > > --- a/mm/memory-failure.c > > +++ b/mm/memory-failure.c > > @@ -1825,12 +1825,11 @@ static inline struct llist_head *raw_hwp_list_h= ead(struct folio *folio) > > > > static unsigned long __folio_free_raw_hwp(struct folio *folio, bool mo= ve_flag) > > { > > - struct llist_head *head; > > - struct llist_node *t, *tnode; > > + struct llist_node *t, *tnode, *head; > > unsigned long count =3D 0; > > > > - head =3D raw_hwp_list_head(folio); > > - llist_for_each_safe(tnode, t, head->first) { > > + head =3D llist_del_all(raw_hwp_list_head(folio)); > > + llist_for_each_safe(tnode, t, head) { > > struct raw_hwp_page *p =3D container_of(tnode, struct raw= _hwp_page, node); > > > > if (move_flag) > > @@ -1840,7 +1839,6 @@ static unsigned long __folio_free_raw_hwp(struct = folio *folio, bool move_flag) > > kfree(p); > > count++; > > } > > - llist_del_all(head); > > return count; > > } > > > > -- > > 2.41.0.162.gfafddb0af9-goog > > > > > >