From: Barry Song <21cnbao@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: mst@redhat.com, xuanzhuo@linux.alibaba.com, eperezma@redhat.com,
maxime.coquelin@redhat.com, xieyongji@bytedance.com,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
penguin-kernel@i-love.sakura.ne.jp, linux-mm@kvack.org,
akpm@linux-foundation.org
Subject: Re: [PATCH] vduse: avoid using __GFP_NOFAIL
Date: Tue, 6 Aug 2024 14:30:18 +1200 [thread overview]
Message-ID: <CAGsJ_4yHU3hBZp2ub1qokf2rCvK7yM0fK9CXQUwxVLn5uaVpcQ@mail.gmail.com> (raw)
In-Reply-To: <20240805082106.65847-1-jasowang@redhat.com>
On Mon, Aug 5, 2024 at 8:21 PM Jason Wang <jasowang@redhat.com> wrote:
>
> Barry said [1]:
>
> """
> mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> __GFP_NOFAIL without direct reclamation may just result in a busy
> loop within non-sleepable contexts.
> ""“
the current code will result in returning a NULL pointer but
not a busy-loop.
static inline struct page *
__alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
struct alloc_context *ac)
{
...
/*
* Make sure that __GFP_NOFAIL request doesn't leak out and make sure
* we always retry
*/
if (gfp_mask & __GFP_NOFAIL) {
/*
* All existing users of the __GFP_NOFAIL are blockable, so warn
* of any new users that actually require GFP_NOWAIT
*/
if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask))
goto fail;
...
}
...
fail:
warn_alloc(gfp_mask, ac->nodemask,
"page allocation failure: order:%u", order);
got_pg:
return page;
}
We have two choices to address the issue:
1. busy-loop
2. BUG_ON
the below patch chose 2:
https://lore.kernel.org/linux-mm/20240731000155.109583-5-21cnbao@gmail.com/
>
> Unfortuantely, we do that under read lock. A possible way to fix that
> is to move the pages allocation out of the lock into the caller, but
> having to allocate a huge number of pages and auxiliary page array
> seems to be problematic as well per Tetsuon [2]:
>
> """
> You should implement proper error handling instead of using
> __GFP_NOFAIL if count can become large.
> """
>
> So I choose another way, which does not release kernel bounce pages
> when user tries to register usersapce bounce pages. Then we don't need
> to do allocation in the path which is not expected to be fail (e.g in
> the release). We pay this for more memory usage but further
> optimizations could be done on top.
>
> [1] https://lore.kernel.org/all/CACGkMEtcOJAA96SF9B8m-nZ1X04-XZr+nq8ZQ2saLnUdfOGOLg@mail.gmail.com/T/#m3caef86a66ea6318ef94f9976ddb3a0ccfe6fcf8
> [2] https://lore.kernel.org/all/CACGkMEtcOJAA96SF9B8m-nZ1X04-XZr+nq8ZQ2saLnUdfOGOLg@mail.gmail.com/T/#m7ad10eaba48ade5abf2d572f24e185d9fb146480
>
> Fixes: 6c77ed22880d ("vduse: Support using userspace pages as bounce buffer")
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vdpa/vdpa_user/iova_domain.c | 18 ++++++++++--------
> drivers/vdpa/vdpa_user/iova_domain.h | 1 +
> 2 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vdpa/vdpa_user/iova_domain.c b/drivers/vdpa/vdpa_user/iova_domain.c
> index 791d38d6284c..933d2f7cd49a 100644
> --- a/drivers/vdpa/vdpa_user/iova_domain.c
> +++ b/drivers/vdpa/vdpa_user/iova_domain.c
> @@ -162,6 +162,7 @@ static void vduse_domain_bounce(struct vduse_iova_domain *domain,
> enum dma_data_direction dir)
> {
> struct vduse_bounce_map *map;
> + struct page *page;
> unsigned int offset;
> void *addr;
> size_t sz;
> @@ -178,7 +179,10 @@ static void vduse_domain_bounce(struct vduse_iova_domain *domain,
> map->orig_phys == INVALID_PHYS_ADDR))
> return;
>
> - addr = kmap_local_page(map->bounce_page);
> + page = domain->user_bounce_pages ?
> + map->user_bounce_page : map->bounce_page;
> +
> + addr = kmap_local_page(page);
> do_bounce(map->orig_phys + offset, addr + offset, sz, dir);
> kunmap_local(addr);
> size -= sz;
> @@ -270,9 +274,8 @@ int vduse_domain_add_user_bounce_pages(struct vduse_iova_domain *domain,
> memcpy_to_page(pages[i], 0,
> page_address(map->bounce_page),
> PAGE_SIZE);
> - __free_page(map->bounce_page);
> }
> - map->bounce_page = pages[i];
> + map->user_bounce_page = pages[i];
> get_page(pages[i]);
> }
> domain->user_bounce_pages = true;
> @@ -297,17 +300,16 @@ void vduse_domain_remove_user_bounce_pages(struct vduse_iova_domain *domain)
> struct page *page = NULL;
>
> map = &domain->bounce_maps[i];
> - if (WARN_ON(!map->bounce_page))
> + if (WARN_ON(!map->user_bounce_page))
> continue;
>
> /* Copy user page to kernel page if it's in use */
> if (map->orig_phys != INVALID_PHYS_ADDR) {
> - page = alloc_page(GFP_ATOMIC | __GFP_NOFAIL);
> + page = map->bounce_page;
> memcpy_from_page(page_address(page),
> - map->bounce_page, 0, PAGE_SIZE);
> + map->user_bounce_page, 0, PAGE_SIZE);
> }
> - put_page(map->bounce_page);
> - map->bounce_page = page;
> + put_page(map->user_bounce_page);
> }
> domain->user_bounce_pages = false;
> out:
> diff --git a/drivers/vdpa/vdpa_user/iova_domain.h b/drivers/vdpa/vdpa_user/iova_domain.h
> index f92f22a7267d..7f3f0928ec78 100644
> --- a/drivers/vdpa/vdpa_user/iova_domain.h
> +++ b/drivers/vdpa/vdpa_user/iova_domain.h
> @@ -21,6 +21,7 @@
>
> struct vduse_bounce_map {
> struct page *bounce_page;
> + struct page *user_bounce_page;
> u64 orig_phys;
> };
>
> --
> 2.31.1
>
next prev parent reply other threads:[~2024-08-06 2:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-05 8:21 Jason Wang
2024-08-05 8:23 ` Jason Wang
2024-08-05 10:42 ` Yongji Xie
2024-08-06 2:28 ` Jason Wang
2024-08-06 3:10 ` Yongji Xie
[not found] ` <CACGkMEue9RU+MMgOC0t4Yuk5wRHfTdnJeZZs38g2h+gyZv+3VQ@mail.gmail.com>
[not found] ` <CACycT3sHT-izwAKzxAWPbqGFgyf82WxkHHOrp1SjWa+HE01mCg@mail.gmail.com>
[not found] ` <CACGkMEvsMQS-5Oy7rTyA5a2u1xYRf0beBHbZ16geHJCZTE0jLw@mail.gmail.com>
[not found] ` <CACycT3sfUhz1PjK3Q=pA7GEm7=fsL0XT16ccwCQ2m2LF+TTD7Q@mail.gmail.com>
[not found] ` <CACGkMEu+RrD2JdO=F9BySwhVY5uPr6kKWWdkcdG4XX6GN5b=Bg@mail.gmail.com>
[not found] ` <CACycT3u-v+XkWzSPq39Mk9sdQftuNZvZqZyzDvhTecH3uyuk8w@mail.gmail.com>
2024-08-12 6:59 ` Jason Wang
2024-08-05 8:25 ` Michael S. Tsirkin
2024-08-06 2:26 ` Jason Wang
2024-08-06 2:30 ` Barry Song [this message]
[not found] ` <CACycT3uM1jSdqFT0LGqy1zXZkWF8BNQN=8EMKYMoyP_wjRtsng@mail.gmail.com>
[not found] ` <CACGkMEtYE1OY+okxHAj=cVfW-Qz45an28oO=Wv15yOtpD6UqdQ@mail.gmail.com>
[not found] ` <CACycT3vAv1K0yBKgc_8GBLpEPwASTCCPZYAxMyUROQsyntQdOw@mail.gmail.com>
2024-08-12 7:00 ` Jason Wang
2024-08-12 7:21 ` Yongji Xie
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=CAGsJ_4yHU3hBZp2ub1qokf2rCvK7yM0fK9CXQUwxVLn5uaVpcQ@mail.gmail.com \
--to=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=virtualization@lists.linux.dev \
--cc=xieyongji@bytedance.com \
--cc=xuanzhuo@linux.alibaba.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