All of lore.kernel.org
 help / color / mirror / Atom feed
From: Naoya Horiguchi <naoya.horiguchi@linux.dev>
To: Jiaqi Yan <jiaqiyan@google.com>
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
Subject: Re: [PATCH v2 1/4] mm/hwpoison: delete all entries before traversal in __folio_free_raw_hwp
Date: Mon, 3 Jul 2023 08:50:34 +0900	[thread overview]
Message-ID: <20230702235034.GA2906304@ik1-406-35019.vs.sakura.ne.jp> (raw)
In-Reply-To: <CACw3F52R8oUNP50dfy35m1KED82NKgKcHKk3ev4O+4nqhFVdzg@mail.gmail.com>

On Fri, Jun 30, 2023 at 01:59:23PM -0700, Jiaqi Yan wrote:
> On Fri, Jun 30, 2023 at 7:52 AM Naoya Horiguchi
> <naoya.horiguchi@linux.dev> 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 entries
> > > 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 <jiaqiyan@google.com>
> >
> > (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.

Thanks for the explanation, this is worth adding to the patch description
for future developers to understand the background.

> 
> As for folio_set_hugetlb_hwpoison, I am not very comfortable fixing
> it. I imagine a way to fix it is llist_del_all() =>
> llist_for_each_safe{...} => llist_add_batch(), or llist_add() within
> llist_for_each_safe{...}. I haven't really thought through if this is
> a correct fix.

I see. Changing folio_set_hugetlb_hwpoison() like this is a little too complex
considering that this fix is for precaution.
So no change on this for now is fine to me.

Anyway this patch looks fine to me.

Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>

> 
> [1] https://lore.kernel.org/lkml/CACw3F51o1ZFSYZa+XLnk4Wwjy2w_q=Kn+aOQs0=qpfG-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_head(struct folio *folio)
> > >
> > >  static unsigned long __folio_free_raw_hwp(struct folio *folio, bool move_flag)
> > >  {
> > > -     struct llist_head *head;
> > > -     struct llist_node *t, *tnode;
> > > +     struct llist_node *t, *tnode, *head;
> > >       unsigned long count = 0;
> > >
> > > -     head = raw_hwp_list_head(folio);
> > > -     llist_for_each_safe(tnode, t, head->first) {
> > > +     head = llist_del_all(raw_hwp_list_head(folio));
> > > +     llist_for_each_safe(tnode, t, head) {
> > >               struct raw_hwp_page *p = 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
> > >
> > >
> > >

  reply	other threads:[~2023-07-02 23:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-23 16:40 [PATCH v2 0/4] Improve hugetlbfs read on HWPOISON hugepages Jiaqi Yan
2023-06-23 16:40 ` [PATCH v2 1/4] mm/hwpoison: delete all entries before traversal in __folio_free_raw_hwp Jiaqi Yan
2023-06-30 14:52   ` Naoya Horiguchi
2023-06-30 20:59     ` Jiaqi Yan
2023-07-02 23:50       ` Naoya Horiguchi [this message]
2023-07-05 23:35   ` Mike Kravetz
2023-07-06 18:11     ` Jiaqi Yan
2023-06-23 16:40 ` [PATCH v2 2/4] mm/hwpoison: check if a subpage of a hugetlb folio is raw HWPOISON Jiaqi Yan
2023-07-05 23:57   ` Mike Kravetz
2023-07-06 18:25     ` Jiaqi Yan
2023-07-06 22:06       ` Mike Kravetz
2023-07-07  1:27         ` Jiaqi Yan
2023-07-07  1:06   ` Naoya Horiguchi
2023-06-23 16:40 ` [PATCH v2 3/4] hugetlbfs: improve read HWPOISON hugepage Jiaqi Yan
2023-07-06 22:09   ` Mike Kravetz
2023-07-07  0:28   ` Naoya Horiguchi
2023-06-23 16:40 ` [PATCH v2 4/4] selftests/mm: add tests for HWPOISON hugetlbfs read Jiaqi Yan
2023-07-06 23:22   ` Mike Kravetz
2023-07-07  0:51   ` Naoya Horiguchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230702235034.GA2906304@ik1-406-35019.vs.sakura.ne.jp \
    --to=naoya.horiguchi@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=duenwen@google.com \
    --cc=jiaqiyan@google.com \
    --cc=jthoughton@google.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=shy828301@gmail.com \
    --cc=songmuchun@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.