linux-kernel - RE: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree

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: <9f81478864bc422c9a59cddbaa723052@EXCHCS32.ornl.gov>
Date:	Fri, 1 May 2015 20:36:05 +0000
From:	"Simmons, James A." <simmonsja@...l.gov>
To:	'Dan Carpenter' <dan.carpenter@...cle.com>
CC:	'Julia Lawall' <Julia.Lawall@...6.fr>,
	Oleg Drokin <oleg.drokin@...el.com>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"HPDD-discuss@...ts.01.org" <HPDD-discuss@...1.01.org>
Subject: RE: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and
 kfree

>We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though.
>
>It's simple enough to write a function:
>
>void *obd_zalloc(size_t size)
>{
>	if (size > 4 * PAGE_CACHE_SIZE)
>		return vzalloc(size);
>	else
>		return kmalloc(size, GFP_NOFS);
>}
>
>Except, huh?  Shouldn't we be using GFP_NOFS for the vzalloc() side?
>There was some discussion of that GFP_NOFS was a bit buggy back in 2010
>(http://marc.info/?l=linux-mm&m=128942194520631&w=4) but the current
>lustre code doesn't try to pass GFP_NOFS.

The version in the upstream client is out of date. The current macro in the Intel master
Branch is:

#define __OBD_VMALLOC_VERBOSE(ptr, cptab, cpt, size)                          \
do {                                                                          \
        (ptr) = cptab == NULL ?                                               \
                __vmalloc(size, GFP_NOFS | __GFP_HIGHMEM | __GFP_ZERO,        \
                          PAGE_KERNEL) :                                      \
                cfs_cpt_vzalloc(cptab, cpt, size);                            \
        if (unlikely((ptr) == NULL)) {                                        \
                CERROR("vmalloc of '" #ptr "' (%d bytes) failed\n",           \
                       (int)(size));                                          \
                CERROR(LPU64" total bytes allocated by Lustre, %d by LNET\n", \
                       obd_memory_sum(), atomic_read(&libcfs_kmemory));       \
        } else {                                                              \
                OBD_ALLOC_POST(ptr, size, "vmalloced");                       \
        }                                                                     \
} while(0)
 
>Then it's simple enough to change OBD_FREE_LARGE() to kvfree().
>
>Also it's weird that only the lustre people have thought of this trick
>to allocate big chunks of RAM and no one else has.  What would happen if
>we just change vmalloc() so it worked this way for everyone?

Do we really want to encourage vmalloc usages?
--
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/