All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Christopher Li <sparse@chrisli.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Linux-Sparse <linux-sparse@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Suggestion for fixing the variable length array used in the kernel.
Date: Sun, 10 Mar 2013 14:38:42 +0300	[thread overview]
Message-ID: <20130310113842.GA9138@mwanda> (raw)
In-Reply-To: <CANeU7Qk2axG8wUFt9JgHt3UpJZTiF50Ug9Udt3BAv99cBR9HPw@mail.gmail.com>

On Sat, Mar 09, 2013 at 03:00:54PM -0800, Christopher Li wrote:
> On Sat, Mar 9, 2013 at 2:34 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > The problems is if we go over the 8k stack.  So big arrays are bad.
> > Also if the dynamically sized array is inside a loop then normally
> > GCC frees it after each iteration, but on some arches it didn't free
> > it until after the last iteration.
> 
> So it seems that you agree those variable array usage should be
> better change to use kmalloc or some thing.
> 
> > Btw, I've Smatch has cross function analysis, and I'd like to use
> > it here to figure out if the max size for dynamically sized arrays.
> > I ran into a problem:
> >
> > The code looks like this:
> >         char buf[a];
> > The size expression should be an EXPR_SYMBOL, but smatch gets:
> >         char buf[*a];
> 
> Sparse currently does not deal with the dynamic array size right now.
> It only want to get constant value from the array size.
> 
> The part that evaluate the array size is actually correct. Remember
> the EXPR_SYMBOL
> actually contain the *address* of symbol "a". So the proper
> sizeof(buf) is actually
> the content of "*a". That part is fine.

It's evaluating it correctly, but Smatch normally expects
expressions which haven't been evaluated yet.

I can probably hack my own Sparse tree for what I need.  It's not a
big deal.

regards,
dan carpenter

      reply	other threads:[~2013-03-10 11:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-07  4:46 Suggestion for fixing the variable length array used in the kernel Christopher Li
2013-03-09  0:29 ` Andrew Morton
2013-03-09  5:39   ` Dan Carpenter
2013-03-09 18:10     ` Christopher Li
2013-03-09 22:34       ` Dan Carpenter
2013-03-09 23:00         ` Christopher Li
2013-03-10 11:38           ` Dan Carpenter [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=20130310113842.GA9138@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=sparse@chrisli.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.