linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>, zijun_hu <zijun_hu@htc.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
	angus@angusclark.org
Subject: Re: [PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
Date: Thu, 27 Apr 2017 19:12:19 +0100	[thread overview]
Message-ID: <B6E4E34C-2478-47C1-A2C7-3EFFA59341B8@linaro.org> (raw)
In-Reply-To: <53d960d0-e44c-3a8d-17fd-a3895ecee858@gmail.com>



> On 27 Apr 2017, at 19:09, Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
>> On 04/27/2017 11:07 AM, Ard Biesheuvel wrote:
>> 
>>> On 27 Apr 2017, at 18:39, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> 
>>> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
>>> module space fails, because the module is too big, and then the module
>>> allocation is attempted from vmalloc space. Silence the first allocation
>>> failure in that case by setting __GFP_NOWARN.
>>> 
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>> ---
>>> arch/arm64/kernel/module.c | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
>>> index 7f316982ce00..58bd5cfdd544 100644
>>> --- a/arch/arm64/kernel/module.c
>>> +++ b/arch/arm64/kernel/module.c
>>> @@ -32,11 +32,16 @@
>>> 
>>> void *module_alloc(unsigned long size)
>>> {
>>> +    gfp_t gfp_mask = GFP_KERNEL;
>>>   void *p;
>>> 
>>> +#if IS_ENABLED(CONFIG_ARM64_MODULE_PLTS)
>>> +    /* Silence the initial allocation */
>>> +    gfp_mask |= __GFP_NOWARN;
>>> +#endif
>> 
>> Please use IS_ENABLED() instead here
> 
> How do you mean?
> 
> if (IS_ENABLED()) vs. #if IS_ENABLED()?
> 

Apologies, I didn't read carefully.

Use the C if not the preprocessor if

>> 
>>>   p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>>>               module_alloc_base + MODULES_VSIZE,
>>> -                GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
>>> +                gfp_mask, PAGE_KERNEL_EXEC, 0,
>>>               NUMA_NO_NODE, __builtin_return_address(0));
>>> 
>>>   if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>>> -- 
>>> 2.9.3
>>> 
>> 
>> Other than that, and with Michal's nit addressed:
>> 
>> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> 
> 
> 
> -- 
> Florian

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2017-04-27 18:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 17:38 [PATCH 0/3 v2] ARM/ARM64: silence large module first time allocation Florian Fainelli
2017-04-27 17:38 ` [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags Florian Fainelli
2017-04-27 17:56   ` Michal Hocko
2017-04-27 18:03     ` Florian Fainelli
2017-04-27 18:20       ` Michal Hocko
2017-04-27 18:21         ` Florian Fainelli
2017-04-27 17:38 ` [PATCH v2 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y Florian Fainelli
2017-04-27 17:39 ` [PATCH v2 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y Florian Fainelli
2017-04-27 18:07   ` Ard Biesheuvel
2017-04-27 18:09     ` Florian Fainelli
2017-04-27 18:12       ` Ard Biesheuvel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B6E4E34C-2478-47C1-A2C7-3EFFA59341B8@linaro.org \
    --to=ard.biesheuvel@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=angus@angusclark.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=catalin.marinas@arm.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=f.fainelli@gmail.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=mhocko@suse.com \
    --cc=will.deacon@arm.com \
    --cc=zijun_hu@htc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox