Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752937AbaAZTUn (ORCPT ); Sun, 26 Jan 2014 14:20:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43736 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752397AbaAZTUl (ORCPT ); Sun, 26 Jan 2014 14:20:41 -0500 Message-ID: <52E55FB1.4060404@redhat.com> Date: Sun, 26 Jan 2014 14:19:13 -0500 From: Prarit Bhargava User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110419 Red Hat/3.1.10-1.el6_0 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ingo Molnar CC: Yinghai Lu , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH -v2] x86: allocate cpumask during check irq vectors References: <1390611565-18709-1-git-send-email-yinghai@kernel.org> <20140125080232.GA20935@gmail.com> <52E4FE02.2020004@redhat.com> <20140126133203.GA1370@gmail.com> In-Reply-To: <20140126133203.GA1370@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/26/2014 08:32 AM, Ingo Molnar wrote: > > * Prarit Bhargava wrote: > >> On 01/25/2014 03:02 AM, Ingo Molnar wrote: >>> >>> * Yinghai Lu wrote: >>> >>>> Fix warning: >>>> arch/x86/kernel/irq.c: In function check_irq_vectors_for_cpu_disable: >>>> arch/x86/kernel/irq.c:337:1: warning: the frame size of 2052 bytes is larger than 2048 bytes >>>> >>>> when NR_CPUS=8192 >>>> >>>> We should use zalloc_cpumask_var() instead. >>>> >>>> -v2: update to GFP_ATOMIC instead and free the allocated cpumask at last. >>>> >>>> Signed-off-by: Yinghai Lu >>>> Cc: Prarit Bhargava >>>> >>>> --- >>>> arch/x86/kernel/irq.c | 24 +++++++++++++++++------- >>>> 1 file changed, 17 insertions(+), 7 deletions(-) >>>> >>>> Index: linux-2.6/arch/x86/kernel/irq.c >>>> =================================================================== >>>> --- linux-2.6.orig/arch/x86/kernel/irq.c >>>> +++ linux-2.6/arch/x86/kernel/irq.c >>>> @@ -277,11 +277,18 @@ int check_irq_vectors_for_cpu_disable(vo >>>> unsigned int this_cpu, vector, this_count, count; >>>> struct irq_desc *desc; >>>> struct irq_data *data; >>>> - struct cpumask affinity_new, online_new; >>>> + cpumask_var_t affinity_new, online_new; >>>> + >>>> + if (!alloc_cpumask_var(&affinity_new, GFP_ATOMIC)) >>>> + return -ENOMEM; >>>> + if (!alloc_cpumask_var(&online_new, GFP_ATOMIC)) { >>>> + free_cpumask_var(affinity_new); >>>> + return -ENOMEM; >>>> + } >>> >>> Atomic allocations can fail easily if the system is under duress. >> >> Then the hotplug attempt will fail which IMO is okay. [...] > > Which is not OK at all for reliable operation, if the system has > otherwise gobs of RAM, which just don't happen to be atomic > allocatable! Ingo, I'm really not sure what other option there is here. Care to suggest one? P. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/