linux-kernel - Re: Question about vmalloc(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] [day] [month] [year] [list]

Message-ID: <84510487-9a1e-4431-9443-3dae91d34048@virtuozzo.com>
Date: Tue, 19 Nov 2024 17:41:35 +0800
From: Pavel Tikhomirov <ptikhomirov@...tuozzo.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Linux Memory Management List <linux-mm@...ck.org>,
 lkml <linux-kernel@...r.kernel.org>,
 Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Question about vmalloc(GFP_NOFS)



On 11/19/24 16:29, Michal Hocko wrote:
> On Tue 19-11-24 15:24:03, Pavel Tikhomirov wrote:
> [...]
>> In commit 451769ebb7e79 ("mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc") we
>> add implicit memalloc_noXX_save/memalloc_noXX_restore at this code path:
>>
>>    +->kvmalloc
>>      +-> ...
>>        +-> __kvmalloc_node_noprof
>>          +-> __vmalloc_node_range_noprof
>>            +-> __vmalloc_area_node
>>
>> So kvmalloc should be safe now with GFP_NOIO.
> 
> Correct.
> 
>> Should we correct the documentation?
> 
> Yes, please. I think it would be useful to explicitly name the above
> commit because pre 5.17 kernels or those who haven't backported it are
> still in same position and that could get dangerous if they try to
> backport [k]vmalloc GFP_NOFS patches. Thanks!
> 

Done 
https://lore.kernel.org/lkml/20241119093922.567138-1-ptikhomirov@virtuozzo.com/. 
Thank you for confirming!

-- 
Best regards, Tikhomirov Pavel
Senior Software Developer, Virtuozzo.