Re: [PATCH v5] mm, slab: Check GFP_SLAB_BUG_MASK before alloc_pages in kmalloc_order

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jul 04, 2020 at 02:26:07AM +0000, Long Li wrote:
> kmalloc cannot allocate memory from HIGHMEM.  Allocating large amounts
> of memory currently bypasses the check and will simply leak the memory
> when page_address() returns NULL.  To fix this, factor the
> GFP_SLAB_BUG_MASK check out of slab & slub, and call it from
> kmalloc_order() as well. In order to make the code clear, the warning
> message is put in one place.
> 
> Reviewed-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
> Reviewed-by: Pekka Enberg <penberg@xxxxxxxxxx>
> Cc: Christoph Lameter <cl@xxxxxxxxx>
> Cc: David Rientjes <rientjes@xxxxxxxxxx>
> Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Long Li <lonuxli.64@xxxxxxxxx>
> ---
> 
> changes in v5:
> -Change the check function name to kmalloc_fix_flags(), This name
> may be more appropriate.
> 
> changes in V4:
> -Change the check function name to kmalloc_check_flags()
> -Put the flags check into the kmalloc_check_flags()

No.  As I said:

The point of not doing that was that this is unlikely().  With your
change there is now a function call to check something that's (extremely)
unlikely().





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux