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:   Mon, 27 Feb 2017 10:52:59 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Tahsin Erdogan <tahsin@...gle.com>
Cc:     Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Chris Wilson <chris@...is-wilson.co.uk>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Roman Pen <r.peniaev@...il.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        zijun_hu <zijun_hu@....com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] percpu: improve allocation success rate for
 non-GFP_KERNEL callers

On Sat 25-02-17 20:38:29, Tahsin Erdogan wrote:
> When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of
> a failure is higher than GFP_KERNEL case. This is mainly because
> pcpu_alloc() relies on previously allocated reserves and does not make
> an effort to add memory to its pools for non-GFP_KERNEL case.

Who is going to use a different mask?
 
> This issue is somewhat mitigated by kicking off a background work when
> a memory allocation failure occurs. But this doesn't really help the
> original victim of allocation failure.
> 
> This problem affects blkg_lookup_create() callers on machines with a
> lot of cpus.
> 
> This patch reduces failure cases by trying to expand the memory pools.
> It passes along gfp flag so it is safe to allocate memory this way.
> 
> To make this work, a gfp flag aware vmalloc_gfp() function is added.
> Also, locking around vmap_area_lock has been updated to save/restore
> irq flags. This was needed to avoid a lockdep problem between
> request_queue->queue_lock and vmap_area_lock.

We already have __vmalloc_gfp, why this cannot be used? Also note that
vmalloc dosn't really support arbitrary gfp flags. One have to be really
careful because there are some internal allocations which are hardcoded
GFP_KERNEL. Also this patch doesn't really add any new callers so it is
hard to tell whether what you do actually makes sense and is correct.
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists