From: Hyesoo Yu <hyesoo.yu@samsung.com>
To: David Hildenbrand <david@redhat.com>
Cc: Zhaoyang Huang <huangzhaoyang@gmail.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 18:53:54 +0900 [thread overview]
Message-ID: <20250604095354.GA4051972@tiffany> (raw)
In-Reply-To: <060a72dd-5928-4e7b-bafd-534cbd95b748@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]
On Wed, Jun 04, 2025 at 11:48:54AM +0200, David Hildenbrand wrote:
> > > > > >
> > > > > 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.
>
I have prepared a patch and just sent it out.
I'd appreciate it if you could take a look and share your feedback.
Thanks,
Regards.
> --
> Cheers,
>
> David / dhildenb
>
>
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
prev parent reply other threads:[~2025-06-04 9:55 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
[not found] ` <CGME20250604095542epcas2p3f3d2d6fc17115547981a7173215a09d1@epcas2p3.samsung.com>
2025-06-04 9:53 ` Hyesoo Yu [this message]
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=20250604095354.GA4051972@tiffany \
--to=hyesoo.yu@samsung.com \
--cc=Steve.Kang@unisoc.com \
--cc=david@redhat.com \
--cc=huangzhaoyang@gmail.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