Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v3] kmemleaak: survive in a low-memory situation
To:     Christopher Lameter <cl@linux.com>
Cc:     akpm@linux-foundation.org, catalin.marinas@arm.com,
        mhocko@kernel.org, penberg@kernel.org, rientjes@google.com,
        iamjoonsoo.kim@lge.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
References: <20190326154338.20594-1-cai@lca.pw>
 <01000169babb99b8-b583bf57-5104-45b7-a4d6-e7677c64ece2-000000@email.amazonses.com>
From:   Qian Cai <cai@lca.pw>
Message-ID: <20540be2-5961-ea86-1ad8-50fbb4d15c6e@lca.pw>
Date:   Tue, 26 Mar 2019 12:28:14 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0)
 Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <01000169babb99b8-b583bf57-5104-45b7-a4d6-e7677c64ece2-000000@email.amazonses.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 3/26/19 12:00 PM, Christopher Lameter wrote:
>> +		 */
>> +		gfp = (in_atomic() || irqs_disabled()) ? GFP_ATOMIC :
>> +		       gfp_kmemleak_mask(gfp) | __GFP_DIRECT_RECLAIM;
>> +		object = kmem_cache_alloc(object_cache, gfp);
>> +	}
>> +
>>  	if (!object) {
> 
> If the alloc must succeed then this check is no longer necessary.

Well, GFP_ATOMIC could still fail. It looks like the only thing that will never
fail is (__GFP_DIRECT_RECLAIM | __GFP_NOFAIL) as it keeps retrying in
__alloc_pages_slowpath().