On Mon, Mar 12, 2012 at 1:04 PM, Myklebust, Trond <Trond.Myklebust@xxxxxxxxxx> wrote: > 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 > Olga got my machine back online :-) GSS_KRB5_MAX_BLOCKSIZE is defined in include/linux/sunrpc/gss_krb5.h The value above is in bytes (16). K.C. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
