linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: kirill@shutemov.name
To: Jiaqi Yan <jiaqiyan@google.com>
Cc: Alexander Potapenko <glider@google.com>,
	elver@google.com, dvyukov@google.com,
	kirill.shutemov@linux.intel.com, shy828301@gmail.com,
	tongtiangen@huawei.com, tony.luck@intel.com,
	akpm@linux-foundation.org, wangkefeng.wang@huawei.com,
	naoya.horiguchi@nec.com, linmiaohe@huawei.com,
	linux-mm@kvack.org, osalvador@suse.de
Subject: Re: [PATCH v9 1/2] mm/khugepaged: recover from poisoned anonymous memory
Date: Tue, 28 Feb 2023 16:40:09 +0300	[thread overview]
Message-ID: <20230228134009.5h5qhpopkhpp23bt@box.shutemov.name> (raw)
In-Reply-To: <CACw3F504uMnMUziGWWH_m5TNGCiWOOuD9U+1=QQc9Me3RwKOow@mail.gmail.com>

On Wed, Feb 08, 2023 at 03:00:59PM -0800, Jiaqi Yan wrote:
> On Wed, Feb 8, 2023 at 3:45 AM Alexander Potapenko <glider@google.com> wrote:
> >
> > On Tue, Feb 7, 2023 at 7:20 PM Jiaqi Yan <jiaqiyan@google.com> wrote:
> > >
> > > Pinging KMSAN experts, for the general guidance of
> > > kmsan_copy_page_meta vs kmsan_unpoison_memory
> >
> > Oh, sorry, I've missed the previous email.
> 
> NP, thanks for jumping in :)
> 
> >
> > copy_mc_user_highpage() is expected to copy data from the user page,
> > for which no metadata is ever allocated.
> > Therefore we just initialize the destination shadow with zeros instead
> > of copying anything.
> >
> > kmsan_copy_page_meta() is used when the metadata is copied between two
> > kernel pages, therefore it handles the cases when page->kmsan_shadow
> > is NULL for the source and destination pages.
> >
> > It might be a good idea to use kmsan_copy_page_meta() in both cases,
> > but to do that I want to better understand what happens when
> > kmap_local_page(from) is called in copy_mc_user_highpage().
> > Where does the corresponding struct page come from?
> 
> Kirill can correct me, but I think khugepaged always copies user pages
> because it is trying to convert raw pages to THP for better userspace
> application performance. Therefore khugepaged should only need
> copy_mc_user_highpage(), for both file-backed and anonymous memory
> pages.
> 
> However, copy_mc_user_highpage() needs both vaddr and vma, so it is a
> little bit hard to use it in collapse_file (i.e. in the file-backed
> case):
> 1. vma is not carried over to collapse_file from khugepaged_scan_mm_slot
> 2. collapse_file is not directly iterating with vaddrs of pages to be copied
> 
> (Although both vaddr and vma are unused auguments in
> copy_mc_user_highpage, I think for cleanness, the caller e.g.
> khugepaged should feed valid values).

It is not unused for !copy_mc_to_kernel case (basically everything but x86
and power). And it is used to flush caches. The fact that you don't have
it in your implementation *may* indicate a problem.

> So my patchset uses copy_mc_page(and kmsan_copy_page_meta) for both
> file-backed and anon memory pages. I guess as long as
> kmsan_copy_page_meta doesn't do anything unexpected for user pages (at
> least from my reading), we are good?
> 

-- 
  Kiryl Shutsemau / Kirill A. Shutemov


  parent reply	other threads:[~2023-02-28 13:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 23:40 [PATCH v9 0/2] Memory poison recovery in khugepaged collapsing Jiaqi Yan
2022-12-05 23:40 ` [PATCH v9 1/2] mm/khugepaged: recover from poisoned anonymous memory Jiaqi Yan
2023-01-19 15:02   ` kirill.shutemov
2023-01-20 15:56     ` Jiaqi Yan
2023-01-24  0:33       ` kirill.shutemov
2023-02-01  5:16         ` Jiaqi Yan
2023-02-02  0:01           ` kirill.shutemov
2023-02-02  0:30             ` kirill
2023-02-07 18:19               ` Jiaqi Yan
2023-02-08 11:44                 ` Alexander Potapenko
2023-02-08 23:00                   ` Jiaqi Yan
2023-02-17 19:49                     ` Jiaqi Yan
2023-02-28 13:40                     ` kirill [this message]
2023-03-03 17:15                       ` Jiaqi Yan
2022-12-05 23:40 ` [PATCH v9 2/2] mm/khugepaged: recover from poisoned file-backed memory Jiaqi Yan
2023-01-19 15:10   ` kirill.shutemov
2023-01-19 21:24     ` Jiaqi Yan
2023-01-18 23:29 ` [PATCH v9 0/2] Memory poison recovery in khugepaged collapsing Andrew Morton

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=20230228134009.5h5qhpopkhpp23bt@box.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=akpm@linux-foundation.org \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=jiaqiyan@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=osalvador@suse.de \
    --cc=shy828301@gmail.com \
    --cc=tongtiangen@huawei.com \
    --cc=tony.luck@intel.com \
    --cc=wangkefeng.wang@huawei.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