Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934481AbeAHQKO (ORCPT + 1 other); Mon, 8 Jan 2018 11:10:14 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:60086 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934444AbeAHQKM (ORCPT ); Mon, 8 Jan 2018 11:10:12 -0500 Date: Mon, 8 Jan 2018 17:10:01 +0100 From: Peter Zijlstra To: Nick Desaulniers Cc: Juergen Gross , ghackmann@google.com, mka@google.com, kees@google.com, srhines@google.com, Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] x86: xen: remove the use of VLAIS Message-ID: <20180108161001.GM32035@hirez.programming.kicks-ass.net> References: <1515274788-24548-1-git-send-email-nick.desaulniers@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1515274788-24548-1-git-send-email-nick.desaulniers@gmail.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Sat, Jan 06, 2018 at 01:39:48PM -0800, Nick Desaulniers wrote: > Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and > frowned upon by others. > > https://lkml.org/lkml/2013/9/23/500 > > Here, the VLAIS was used because the size of the bitmap returned from > xen_mc_entry() depended on possibly (based on kernel configuration) > runtime sized data. Rather than declaring args as a VLAIS then calling > sizeof on *args, we calculate the appropriate sizeof args manually. > Further, we can get rid of the #ifdef's and rely on num_possible_cpus() > (thanks to a helpful checkpatch warning from an earlier version of this > patch). > > Suggested-by: Juergen Gross > Signed-off-by: Nick Desaulniers > --- > Changes in v2: > * Change mask to us DECLARE_BITMAP instead of pointer, as suggested. > * Update commit message to remove mention of pointer. > * Update sizeof calculation to work with array rather than pointer. > > arch/x86/xen/mmu_pv.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c > index 4d62c07..d850762 100644 > --- a/arch/x86/xen/mmu_pv.c > +++ b/arch/x86/xen/mmu_pv.c > @@ -1325,20 +1325,18 @@ static void xen_flush_tlb_others(const struct cpumask *cpus, > { > struct { > struct mmuext_op op; > -#ifdef CONFIG_SMP > - DECLARE_BITMAP(mask, num_processors); > -#else > DECLARE_BITMAP(mask, NR_CPUS); > -#endif > } *args; Why is it OK for Xen to place this bitmap on-stack in the first place? That NR_CPUS thing can be fairly huge.