From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Li Subject: Suggestion for fixing the variable length array used in the kernel. Date: Wed, 6 Mar 2013 20:46:35 -0800 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from mail-oa0-f46.google.com ([209.85.219.46]:63538 "EHLO mail-oa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754718Ab3CGEqg (ORCPT ); Wed, 6 Mar 2013 23:46:36 -0500 Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: linux-kernel Cc: Linux-Sparse , Linus Torvalds Hi, I am looking at the current sparse warning on the kernel source. One category of those warning are produce by the variable length array. We all know that the kernel stack has a limit so we don't want to allocate too much stack to the variable size array. Is there a recommended way to fix those warnings? Is it worth while to fix it at all? I am looking forward to some kind of guideline how to handle this. Some of them has estimated size limited, like the one fournd in decode_rs.c /* Err+Eras Locator poly and syndrome poly The maximum value * of nroots is 8. So the necessary stack size will be about * 220 bytes max. */ uint16_t lambda[nroots + 1], syn[nroots]; uint16_t b[nroots + 1], t[nroots + 1], omega[nroots + 1]; uint16_t root[nroots], reg[nroots + 1], loc[nroots]; Some of them did not said the size estimation but you kind of know they are not likely to blow up the stack: In xen_flush_tlb_others struct { struct mmuext_op op; #ifdef CONFIG_SMP DECLARE_BITMAP(mask, num_processors); #else DECLARE_BITMAP(mask, NR_CPUS); #endif } *args; And also some of them are harder to tell from the context if there will be a size limit: int snd_pcm_hw_refine(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { unsigned int k; struct snd_pcm_hardware *hw; struct snd_interval *i = NULL; struct snd_mask *m = NULL; struct snd_pcm_hw_constraints *constrs = &substream->runtime->hw_constraints; unsigned int rstamps[constrs->rules_num]; <--------------------------------- Chris