On Mon, 2012-03-12 at 11:13 -0400, Kevin Coffman wrote:
> On Sun, Mar 11, 2012 at 7:02 PM, Dr James Bruce Fields
> <bfields@xxxxxxxxxxxx> wrote:
> > On Sun, Mar 11, 2012 at 10:14:44PM +0000, Myklebust, Trond wrote:
> >> Hi Kevin & Bruce,
> >>
> >> When running sparse on the sunrpc code, I'm seeing the following error
> >> message:
> >> "net/sunrpc/auth_gss/gss_krb5_crypto.c:603:52: error: bad constant
> >> expression"
> >>
> >> This boils down to the line:
> >> u8 data[crypto_blkcipher_blocksize(cipher) * 2];
> >
> > Oops.
> >
> >> which is using a GNU Cc-ism in order to do dynamic allocation on the
> >> stack. This is not acceptable in kernel code, and really needs to be
> >> changed. How should we move forward with this? Is there an upper limit
> >> on the value of crypto_blkcipher_blocksize(cipher) that we can use?
> >
> > I think it's always either 8 or 16.
> >
> > --b.
> >
>
> Yes, I think 16 is currently the upper blocksize limit. I was
> thinking there was a constant defined in a header for the
> maxblocksize, but I'm not able to get to my machine to grep for it
> right now.
I can't see an absolute maximum for the blocksize. The biggest blocksize
that I can find in the sources now is SHA512_BLOCK_SIZE, with the value
128. That looks a little large to be using in a stack variable.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
