From: "Luck, Tony" <tony.luck@intel.com>
To: "chu, jane" <jane.chu@oracle.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>,
"nao.horiguchi@gmail.com" <nao.horiguchi@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
"David Hildenbrand" <david@redhat.com>,
Muchun Song <muchun.song@linux.dev>,
Benjamin LaHaise <bcrl@kvack.org>,
"jglisse@redhat.com" <jglisse@redhat.com>,
Zi Yan <ziy@nvidia.com>, Jiaqi Yan <jiaqiyan@google.com>,
Hugh Dickins <hughd@google.com>,
Vishal Moola <vishal.moola@gmail.com>,
Alistair Popple <apopple@nvidia.com>,
Oscar Salvador <osalvador@suse.de>
Subject: RE: [PATCH v3 4/5] fs: hugetlbfs: support poison recover from hugetlbfs_migrate_folio()
Date: Tue, 28 May 2024 22:10:09 +0000 [thread overview]
Message-ID: <SJ1PR11MB60835F7CEE66E388F244CA11FCF12@SJ1PR11MB6083.namprd11.prod.outlook.com> (raw)
In-Reply-To: <93259498-67dd-41e3-97c0-99e521b61960@oracle.com>
> It looks like memory_failure_queue() is only invoked when source user
> page has a poison, not if the poison
>
> is in source kernel page. Any idea why?
If it is a user page, Linux can unmap it from that process. Send
signal(SIGBUS) to the process if it was actively consuming the
poison (as opposed to poison found by patrol scrubber or by
speculative access).
Linux doesn't (yet) have a way to workaround poison in a source
kernel page. I think the only place it will ever get that is for pages
in the page cache. Action to somehow unmap them from the file?
-Tony
next prev parent reply other threads:[~2024-05-28 22:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 13:45 [PATCH v3 0/5] mm: migrate: support poison recover from migrate folio Kefeng Wang
2024-05-28 13:45 ` [PATCH v3 1/5] mm: add folio_mc_copy() Kefeng Wang
2024-05-28 14:17 ` Lance Yang
2024-05-29 2:16 ` Kefeng Wang
2024-05-28 20:13 ` Jane Chu
2024-05-29 2:16 ` Kefeng Wang
2024-05-28 13:45 ` [PATCH v3 2/5] mm: migrate: split folio_migrate_mapping() Kefeng Wang
2024-05-28 13:45 ` [PATCH v3 3/5] mm: migrate: support poisoned recover from migrate folio Kefeng Wang
2024-05-28 20:15 ` Jane Chu
2024-05-29 2:19 ` Kefeng Wang
2024-05-28 13:45 ` [PATCH v3 4/5] fs: hugetlbfs: support poison recover from hugetlbfs_migrate_folio() Kefeng Wang
2024-05-28 15:41 ` Luck, Tony
2024-05-28 20:19 ` Jane Chu
2024-05-28 20:30 ` Luck, Tony
2024-05-28 22:02 ` Jane Chu
2024-05-28 22:10 ` Luck, Tony [this message]
2024-05-29 2:48 ` Kefeng Wang
2024-05-28 13:45 ` [PATCH v3 5/5] mm: migrate: remove folio_migrate_copy() Kefeng Wang
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=SJ1PR11MB60835F7CEE66E388F244CA11FCF12@SJ1PR11MB6083.namprd11.prod.outlook.com \
--to=tony.luck@intel.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bcrl@kvack.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jane.chu@oracle.com \
--cc=jglisse@redhat.com \
--cc=jiaqiyan@google.com \
--cc=linmiaohe@huawei.com \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=vishal.moola@gmail.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.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