From: Mike Kravetz <mike.kravetz@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Tony Luck <tony.luck@intel.com>
Cc: Liu Shixin <liushixin2@huawei.com>,
Naoya Horiguchi <naoya.horiguchi@nec.com>,
Miaohe Lin <linmiaohe@huawei.com>,
Muchun Song <muchun.song@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] mm: hwpoison: support recovery from HugePage copy-on-write faults
Date: Wed, 12 Apr 2023 16:37:19 -0700 [thread overview]
Message-ID: <20230412233719.GC4759@monkey> (raw)
In-Reply-To: <20230412155618.720e6b3aa5be6444f7889ea6@linux-foundation.org>
On 04/12/23 15:56, Andrew Morton wrote:
> On Wed, 12 Apr 2023 15:21:38 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> > > > Commit a873dfe1032a ("mm, hwpoison: try to recover from copy-on write
> > > > faults") introduced the routine copy_user_highpage_mc() to gracefully
> > > > handle copying of user pages with uncorrectable errors. Previously,
> > > > such copies would result in a kernel crash. hugetlb has separate code
> > > > paths for copy-on-write and does not benefit from the changes made in
> > > > commit a873dfe1032a.
> >
> > I was just going to suggest adding the line,
> >
> > Hence, copy-on-write of hugetlb user pages with uncorrectable errors
> > will result in a kernel crash as was the case with 'normal' pages before
> > commit a873dfe1032a.
> >
> > However, I'm guessing it might be more clear if we start with the
> > runtime effects. Something like:
> >
> > copy-on-write of hugetlb user pages with uncorrectable errors will result
> > in a kernel crash. This is because the copy is performed in kernel mode
> > and in general we can not handle accessing memory with such errors while
> > in kernel mode. Commit a873dfe1032a ("mm, hwpoison: try to recover from
> > copy-on write faults") introduced the routine copy_user_highpage_mc() to
> > gracefully handle copying of user pages with uncorrectable errors. However,
> > the separate hugetlb copy-on-write code paths were not modified as part
> > of commit a873dfe1032a.
>
> Sounds good. So I assume cc:stable is desirable.
I do not think cc:stable is necessary/desirable. Why?
a873dfe1032a was an enhancement to better handle copying pages with memory
errors in the kernel. IIUC, we never handled that situation in the past.
I would not call the fact that it did not take hugetlb into account a bug.
Although, some might argue that it should have addressed all callers of
copy_user_highpage which would have included hugetlb. IMO, There would be
little to gain by backporing to 6.1 as the issue of copying pages with
errors has existed forever. Perhaps Tony will comment as I was not involved
in a873dfe1032a.
> I can't actually get the patch to apply to anything. Can we please
> have a redo against current -linus?
--
Mike Kravetz
next prev parent reply other threads:[~2023-04-12 23:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 9:27 Liu Shixin
2023-04-12 0:26 ` Andrew Morton
2023-04-12 18:13 ` Mike Kravetz
2023-04-12 21:57 ` Andrew Morton
2023-04-12 22:21 ` Mike Kravetz
2023-04-12 22:56 ` Andrew Morton
2023-04-12 23:37 ` Mike Kravetz [this message]
2023-04-13 0:47 ` Luck, Tony
2023-04-13 1:55 ` Liu Shixin
2023-04-13 1:51 ` Liu Shixin
2023-04-13 1:49 ` Liu Shixin
2023-04-13 12:57 ` Jiaqi Yan
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=20230412233719.GC4759@monkey \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liushixin2@huawei.com \
--cc=muchun.song@linux.dev \
--cc=naoya.horiguchi@nec.com \
--cc=tony.luck@intel.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