| 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
| ||
|
Message-ID: <0b0a6adf-348e-425d-b375-23da3d6668d0@fastmail.fm> Date: Wed, 2 Apr 2025 11:10:52 +0200 From: Bernd Schubert <bernd.schubert@...tmail.fm> To: Jaco Kroon <jaco@....co.za>, Miklos Szeredi <miklos@...redi.hu> Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, christophe.jaillet@...adoo.fr, joannelkoong@...il.com, rdunlap@...radead.org, trapexit@...wn.link, david.laight.linux@...il.com Subject: Re: [PATCH 2/2] fuse: Adjust readdir() buffer to requesting buffer size. On 4/2/25 10:52, Jaco Kroon wrote: > Hi, > > On 2025/04/02 10:18, Miklos Szeredi wrote: >> On Wed, 2 Apr 2025 at 09:55, Jaco Kroon <jaco@....co.za> wrote: >>> Hi, >>> >>> I can definitely build on that, thank you. >>> >>> What's the advantage of kvmalloc over folio's here, why should it be >>> preferred? >> It offers the best of both worlds: first tries plain malloc (which >> just does a folio alloc internally for size > PAGE_SIZE) and if that >> fails, falls back to vmalloc, which should always succeed since it >> uses order 0 pages. > > So basically assigns the space, but doesn't commit physical pages for > the allocation, meaning first access will cause a page fault, and single > page allocation at that point in time? Or is it merely the fact that > vmalloc may return a virtual contiguous block that's not physically > contiguous? Yes vmalloc return buffers might not be physically contiguous - not suitable for hardware DMA. And AFAIK it is also a blocking allocation. Bernd
Powered by blists - more mailing lists