linux-kernel - Re: [PATCH] Allow __vmalloc with 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]

Date:	Sat, 28 Apr 2007 14:13:56 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Giridhar Pemmasani <pgiri@...oo.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Allow __vmalloc with GFP_ATOMIC

Giridhar Pemmasani wrote:
> Until 2.6.19, __vmalloc with GFP_ATOMIC was possible, but __get_vm_area_node
> would allocate the node itself with GFP_KERNEL, causing a warning. In 2.6.19,
> this was "fixed" by using the same flags that were passed to __vmalloc also
> in __get_vm_area_node. However, __get_vm_area_node does
> BUG_ON(in_interrupt()) now, since vmlist_lock is obtained without disabling
> bottom-half's. The patch below uses bh disabled lock for vmlist_lock, so that
> __vmalloc can be used in interrupt context.
> 
> In 2.6.21, __vmalloc with GFP_ATOMIC is used by arch/um/kernel/process.c;
> __vmalloc is also used in ntfs, xfs, but it is not clear to me if they use it
> with GFP_ATOMIC or GFP_KERNEL.
> 
> Thanks,
> Giri

Hi Giri,

I'm sure I've read the reason for this one before, but when you do patches
like these, can you include that reason in the changelog please?

Thanks,
Nick

-- 
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/