From: Mike Kravetz <mike.kravetz@oracle.com>
To: Usama Arif <usama.arif@bytedance.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, muchun.song@linux.dev,
songmuchun@bytedance.com, fam.zheng@bytedance.com,
liangma@liangbit.com, punit.agrawal@bytedance.com,
Konrad Dybcio <konrad.dybcio@linaro.org>
Subject: Re: [External] Re: [PATCH] mm: hugetlb: Only prep and add allocated folios for non-gigantic pages
Date: Tue, 10 Oct 2023 14:30:19 -0700 [thread overview]
Message-ID: <20231010213019.GB279095@monkey> (raw)
In-Reply-To: <6b1d9860-3581-0b99-4fb7-4c1f5a2a05f3@bytedance.com>
On 10/10/23 18:01, Usama Arif wrote:
>
>
> On 10/10/2023 02:23, Mike Kravetz wrote:
> > On 10/09/23 15:56, Usama Arif wrote:
> > > Calling prep_and_add_allocated_folios when allocating gigantic pages
> > > at boot time causes the kernel to crash as folio_list is empty
> > > and iterating it causes a NULL pointer dereference. Call this only
> > > for non-gigantic pages when folio_list has entires.
> >
> > Thanks!
> >
> > However, are you sure the issue is the result of iterating through a
> > NULL list? For reference, the routine prep_and_add_allocated_folios is:
> >
>
> Yes, you are right, it wasnt an issue with the list, but the lock. If I do
> the below diff it boots.
Thanks!
I believe that may be that may be the root cause of boot issues with
this series. It is unfortunate that the failures were not consistent
and did not directly point at the root cause.
Hopefully, these changes will resolve the boot issues for Konrad as well.
I will create a new version of the "Batch hugetlb vmemmap modification
operations" series with these locking changes.
--
Mike Kravetz
next prev parent reply other threads:[~2023-10-10 21:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 14:56 [PATCH] mm: hugetlb: Only prep and add allocated folios for non-gigantic pages Usama Arif
2023-10-10 1:23 ` Mike Kravetz
2023-10-10 17:01 ` [External] " Usama Arif
2023-10-10 21:30 ` Mike Kravetz [this message]
2023-10-10 21:31 ` Konrad Dybcio
2023-10-12 0:03 ` Nathan Chancellor
2023-10-12 14:53 ` Mike Kravetz
2023-10-13 0:12 ` Mike Kravetz
2023-10-14 0:04 ` Mike Kravetz
2023-10-18 20:54 ` Nick Desaulniers
2023-10-18 22:20 ` Mike Kravetz
2023-10-19 4:33 ` Sergey Senozhatsky
2023-10-19 14:20 ` Nathan Chancellor
2023-10-19 2:38 ` Mike Kravetz
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=20231010213019.GB279095@monkey \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=fam.zheng@bytedance.com \
--cc=konrad.dybcio@linaro.org \
--cc=liangma@liangbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=punit.agrawal@bytedance.com \
--cc=songmuchun@bytedance.com \
--cc=usama.arif@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).