From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754526Ab3FKAzJ (ORCPT ); Mon, 10 Jun 2013 20:55:09 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:39556 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754380Ab3FKAzH (ORCPT ); Mon, 10 Jun 2013 20:55:07 -0400 Message-ID: <51B67553.6020205@oracle.com> Date: Mon, 10 Jun 2013 20:54:43 -0400 From: Sasha Levin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Christoph Lameter CC: Pekka Enberg , "linux-mm@kvack.org" , Andrew Morton , LKML Subject: Re: [PATCH] slab: prevent warnings when allocating with __GFP_NOWARN References: <1370891880-2644-1-git-send-email-sasha.levin@oracle.com> <51B62F6B.8040308@oracle.com> <0000013f3075f90d-735942a8-b4b8-413f-a09e-57d1de0c4974-000000@email.amazonses.com> In-Reply-To: <0000013f3075f90d-735942a8-b4b8-413f-a09e-57d1de0c4974-000000@email.amazonses.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/10/2013 07:40 PM, Christoph Lameter wrote: > On Mon, 10 Jun 2013, Sasha Levin wrote: > >> [ 1691.807621] Call Trace: >> [ 1691.809473] [] dump_stack+0x4e/0x82 >> [ 1691.812783] [] warn_slowpath_common+0x82/0xb0 >> [ 1691.817011] [] warn_slowpath_null+0x15/0x20 >> [ 1691.819936] [] kmalloc_slab+0x2f/0xb0 >> [ 1691.824942] [] __kmalloc+0x24/0x4b0 >> [ 1691.827285] [] ? security_capable+0x13/0x20 >> [ 1691.829405] [] ? pipe_fcntl+0x107/0x210 >> [ 1691.831827] [] pipe_fcntl+0x107/0x210 >> [ 1691.833651] [] ? fget_raw_light+0x130/0x3f0 >> [ 1691.835343] [] SyS_fcntl+0x60b/0x6a0 >> [ 1691.837008] [] tracesys+0xe1/0xe6 >> >> The caller specifically sets __GFP_NOWARN presumably to avoid this warning on >> slub but I'm not sure if there's any other reason. > > There must be another reason. Lets fix this. My, I feel silly now. I was the one who added __GFP_NOFAIL in the first place in 2ccd4f4d ("pipe: fail cleanly when root tries F_SETPIPE_SZ with big size"). What happens is that root can go ahead and specify any size it wants to be used as buffer size - and the kernel will attempt to comply by allocation that buffer. Which fails if the size is too big. Either way, even if we do end up doing something different, shouldn't we prevent slab from spewing a warning if __GFP_NOWARN is passed? Thanks, Sasha