linux-kernel - Re: [PATCH] vduse: avoid using __GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACGkMEvsagVFdqkZvoRWRC2sSSNkjSA=eFjnZU=yT_F=GvQNdg@mail.gmail.com>
Date: Tue, 6 Aug 2024 10:26:01 +0800
From: Jason Wang <jasowang@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: xuanzhuo@...ux.alibaba.com, eperezma@...hat.com, 
	maxime.coquelin@...hat.com, xieyongji@...edance.com, 
	virtualization@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	21cnbao@...il.com, penguin-kernel@...ove.sakura.ne.jp, linux-mm@...ck.org, 
	akpm@...ux-foundation.org
Subject: Re: [PATCH] vduse: avoid using __GFP_NOFAIL

On Mon, Aug 5, 2024 at 4:26 PM Michael S. Tsirkin <mst@...hat.com> wrote:
>
> On Mon, Aug 05, 2024 at 04:21:06PM +0800, Jason Wang 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.
> > ""“
> >
> > 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
>
> userspace
>
> > 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
>
> what does "we pay this for more memory usage" mean?
> Do you mean "we pay for this by using more memory"?

Yes.

> How much more?

Depends on the workload, but basically, it's just the maximum size of
bounce buffer:

Default size 64M

#define VDUSE_BOUNCE_SIZE (64 * 1024 * 1024)

Maximum 1G:

#define VDUSE_MAX_BOUNCE_SIZE (1024 * 1024 * 1024)

Thanks