From: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: SeongJae Park <sj@kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Christoph Hellwig <hch@infradead.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Hugh Dickins <hughd@google.com>, Peter Xu <peterx@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
"Kim, Dongwon" <dongwon.kim@intel.com>,
"Chang, Junxiao" <junxiao.chang@intel.com>,
"Jason Gunthorpe" <jgg@nvidia.com>,
Christoph Hellwig <hch@lst.de>, Dave Airlie <airlied@redhat.com>
Subject: RE: [PATCH v16 3/9] mm/gup: Introduce memfd_pin_folios() for pinning memfd folios
Date: Sun, 14 Jul 2024 02:30:31 +0000 [thread overview]
Message-ID: <IA0PR11MB71854CD7A12F710BB8C44A9CF8A02@IA0PR11MB7185.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20240705155523.2f098948237715f8a0ffa56c@linux-foundation.org>
Hi Andrew,
>
> > Hi Andrew and SJ,
> >
> > >
> > > >
> > > > I didn't look deep into the patch, so unsure if that's a valid fix, though.
> > > > May I ask your thoughts?
> > >
> > > Perhaps we should propagate the errno which was returned by
> > > try_grab_folio()?
> > >
> > > I'll do it this way. Vivek, please check and let us know?
> > Yeah, memfd_pin_folios() doesn't need the fast version, so replacing with
> > the slow version (try_grab_folio) should be fine. And, as you suggest,
> > propagating the errno returned by try_grab_folio() would be the right thing
> > to do instead of explicitly setting errno to -EINVAL. Either way, this change is
> > Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
>
> Cool, thanks.
>
> We could do this to propagate the try_grab_folio() return value:
>
> --- a/mm/gup.c~mm-gup-introduce-memfd_pin_folios-for-pinning-memfd-
> folios-fix-fix
> +++ a/mm/gup.c
> @@ -3848,6 +3848,8 @@ long memfd_pin_folios(struct file *memfd
>
> next_idx = 0;
> for (i = 0; i < nr_found; i++) {
> + int ret2;
Is there any reason why you introduced a new variable instead of just reusing ret?
> +
> /*
> * As there can be multiple entries for a
> * given folio in the batch returned by
> @@ -3860,10 +3862,10 @@ long memfd_pin_folios(struct file *memfd
> continue;
>
> folio = page_folio(&fbatch.folios[i]->page);
> -
> - if (try_grab_folio(folio, 1, FOLL_PIN)) {
> + ret2 = try_grab_folio(folio, 1, FOLL_PIN);
> + if (ret2) {
> folio_batch_release(&fbatch);
> - ret = -EINVAL;
> + ret = ret2;
> goto err;
> }
>
>
> But try_grab_folio can return that weird -EREMOTEIO. The
> try_grab_folio() kerneldoc doesn't even mention that - it incorrectly
> claims that only -ENOMEM can be returned. (needs fixing!).
>
> And if memfd_pin_folios() returns -EREMOTEIO then I expect
> udmabuf_ioctl() will return -EREMOTEIO to userspace. And userspace
It is not clear to me if userspace needs to do anything in particular to handle
this specific error. At the moment, Qemu (userspace user of udmabuf_ioctl)
does not do anything special for any error codes, and just treats them all as
failures though.
> will wonder "what the hell is that". If there's a udmabuf_ioctl
> manpage then will that explain this errno? And similar concerns for
> future callers of memfd_pin_folios().
Sure, we can definitely add documentation explaining this situation once we
agree how the userspace needs to handle this specific error code.
Thanks,
Vivek
next prev parent reply other threads:[~2024-07-14 2:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 6:36 [PATCH v16 0/9] " Vivek Kasireddy
2024-06-24 6:36 ` [PATCH v16 1/9] mm/gup: Introduce unpin_folio/unpin_folios helpers Vivek Kasireddy
2024-06-24 6:36 ` [PATCH v16 2/9] mm/gup: Introduce check_and_migrate_movable_folios() Vivek Kasireddy
2024-06-24 6:36 ` [PATCH v16 3/9] mm/gup: Introduce memfd_pin_folios() for pinning memfd folios Vivek Kasireddy
2024-07-05 20:48 ` SeongJae Park
2024-07-05 21:23 ` Andrew Morton
2024-07-05 22:11 ` Kasireddy, Vivek
2024-07-05 22:55 ` Andrew Morton
2024-07-12 22:32 ` Andrew Morton
2024-07-14 2:30 ` Kasireddy, Vivek [this message]
2024-06-24 6:36 ` [PATCH v16 4/9] udmabuf: add CONFIG_MMU dependency Vivek Kasireddy
2024-06-24 6:36 ` [PATCH v16 5/9] udmabuf: Use vmf_insert_pfn and VM_PFNMAP for handling mmap Vivek Kasireddy
2024-06-24 6:36 ` [PATCH v16 6/9] udmabuf: Add back support for mapping hugetlb pages Vivek Kasireddy
2024-06-24 6:36 ` [PATCH v16 7/9] udmabuf: Convert udmabuf driver to use folios Vivek Kasireddy
2024-06-24 6:36 ` [PATCH v16 8/9] udmabuf: Pin the pages using memfd_pin_folios() API Vivek Kasireddy
2024-06-24 6:36 ` [PATCH v16 9/9] selftests/udmabuf: Add tests to verify data after page migration Vivek Kasireddy
2024-06-26 19:13 ` [PATCH v16 0/9] mm/gup: Introduce memfd_pin_folios() for pinning memfd folios Kasireddy, Vivek
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=IA0PR11MB71854CD7A12F710BB8C44A9CF8A02@IA0PR11MB7185.namprd11.prod.outlook.com \
--to=vivek.kasireddy@intel.com \
--cc=airlied@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=daniel.vetter@ffwll.ch \
--cc=david@redhat.com \
--cc=dongwon.kim@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=hughd@google.com \
--cc=jgg@nvidia.com \
--cc=junxiao.chang@intel.com \
--cc=kraxel@redhat.com \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=sj@kernel.org \
--cc=willy@infradead.org \
/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