From: David Hildenbrand <david@redhat.com>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: Hyesoo Yu <hyesoo.yu@samsung.com>,
jaewon31.kim@samsung.com, John Hubbard <jhubbard@nvidia.com>,
"zhaoyang.huang@unisoc.com" <zhaoyang.huang@unisoc.com>,
"surenb@google.com" <surenb@google.com>,
"Steve.Kang@unisoc.com" <Steve.Kang@unisoc.com>,
Jaewon Kim <jaewon31.kim@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Jang-Hyuck Kim <janghyuck.kim@samsung.com>
Subject: Re: reply: [RFC] pin_user_pages_fast failure count increased
Date: Wed, 4 Jun 2025 11:48:54 +0200 [thread overview]
Message-ID: <060a72dd-5928-4e7b-bafd-534cbd95b748@redhat.com> (raw)
In-Reply-To: <CAGWkznFu-YcErBqQgsg0cUJ6JWE7LsebxHEfqvBNNP8d-9bYzg@mail.gmail.com>
>>>>>
>>>> So, what's the status of that? We should fix it upstream (*not* caring
>>>> about controversial out-of-tree pkvm issues).
>>> Leaving aside the pkvm issue, we should also care about the CMA pages
>>> mapping to VM by special driver which are intended to be long term
>>> pinned (actually they are fetched by cma_alloc and then mapped to VM
>>> instead of alloc_pages during normal page fault).
>>
>> Is there any such "special driver" in the tree?
> Not that I know of. However, pin_user_pages is exported symbol which
> could be used for ko, should we make it be capable of dealing with
> this scenario?
We have the tendency to not go above and beyond of adding features that
we cannot even test without OOT drivers.
Note that we export symbols so other in-tree drivers that are built as a
module can make use of them.
>>
>>> Could we distinguish
>>> them by the patch below based on 1aaf8c122, that is, this kind of
>>> pages is not on page cache and have equaled refcnt to mapcount
>>
>> No, not like that. We'd need some proper indication that this page was
>> allocated by the CMA area owner, and that owner agrees that the folio
>> can be long-term pinned (maybe that agreement is by mapping it into user
>> space, tbd).
> I think the key point is to distinguish the cma pages which are
> allocated from fallback of GFP_MOVABLE during common page faults from
> the ones which got from cma_alloc within the special driver's
> vm_ops->fault.
Yes. Using typed pages in the future might work. For now, this is not
possible yet because the page type overlays page->mapcount.
Hm.
>>
>> Will you send the fix or should I do it? Discussing about broken use
>> cases that do no apply upstream is not particularly helpful when we're
>> dealing with a real upstream bug.
> I would like to ask for your help on this since I have no further ideas. Thanks
Okay, let me send a fix for the original commit.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-06-04 9:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAJrd-UtDD50iN=Yxz4=6kNkAcNAtRFkxhKAbEYiRyyDT-bYPHg@mail.gmail.com>
2025-05-22 10:18 ` 黄朝阳 (Zhaoyang Huang)
2025-05-22 12:22 ` David Hildenbrand
[not found] ` <CGME20250522130101epcas1p435244c12cfc9bb7895008b8ea98af064@epcms1p3>
2025-05-22 13:09 ` Jaewon Kim
2025-05-22 14:06 ` David Hildenbrand
[not found] ` <CGME20250522130101epcas1p435244c12cfc9bb7895008b8ea98af064@epcms1p2>
2025-05-22 14:44 ` 김재원
2025-05-22 15:07 ` David Hildenbrand
2025-05-23 2:48 ` John Hubbard
2025-05-23 2:37 ` 김재원
2025-05-23 2:52 ` John Hubbard
2025-05-26 7:48 ` Hyesoo Yu
2025-05-26 8:05 ` Zhaoyang Huang
2025-05-26 9:33 ` Hyesoo Yu
2025-05-26 9:38 ` David Hildenbrand
[not found] ` <CGME20250522130101epcas1p435244c12cfc9bb7895008b8ea98af064@epcms1p8>
2025-05-26 11:17 ` Jaewon Kim
2025-05-26 11:49 ` Zhaoyang Huang
2025-05-28 1:23 ` Hyesoo Yu
2025-05-28 2:49 ` Zhaoyang Huang
2025-05-28 3:36 ` Hyesoo Yu
2025-05-28 7:55 ` David Hildenbrand
2025-05-28 10:59 ` Zhaoyang Huang
2025-05-28 12:57 ` David Hildenbrand
2025-06-03 13:12 ` David Hildenbrand
2025-06-04 1:04 ` Zhaoyang Huang
2025-06-04 9:12 ` David Hildenbrand
2025-06-04 9:41 ` Zhaoyang Huang
2025-06-04 9:48 ` David Hildenbrand [this message]
[not found] ` <CGME20250604095542epcas2p3f3d2d6fc17115547981a7173215a09d1@epcas2p3.samsung.com>
2025-06-04 9:53 ` Hyesoo Yu
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=060a72dd-5928-4e7b-bafd-534cbd95b748@redhat.com \
--to=david@redhat.com \
--cc=Steve.Kang@unisoc.com \
--cc=huangzhaoyang@gmail.com \
--cc=hyesoo.yu@samsung.com \
--cc=jaewon31.kim@gmail.com \
--cc=jaewon31.kim@samsung.com \
--cc=janghyuck.kim@samsung.com \
--cc=jhubbard@nvidia.com \
--cc=linux-mm@kvack.org \
--cc=surenb@google.com \
--cc=zhaoyang.huang@unisoc.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