On Tue, 2012-05-22 at 11:29 -0400, J. Bruce Fields wrote: > On Tue, May 22, 2012 at 11:15:22AM -0400, Simo Sorce wrote: > > On Tue, 2012-05-22 at 11:02 -0400, J. Bruce Fields wrote: > > > This seems > > > likely to break in subtle ways if we ever change one of those constants > > > to not be a multiple of a large enough power of 2. And makes the memory > > > handling a little more obscure. I'd rather just allocate those > > > separately if that's the choice. > > > > I do not see why it would break, the only limit we have is the total > > size of the kmembuf. > > Oh, just because the svc_cred at the end wouldn't be aligned nicely any > more. Doesn't that bother some architectures? Ah yeah I see, indeed some architecture require memory to be aligned. I will change that code back to kmallocs, which is what I always preferred anyway. > > > Whatever, I don't really care how the various xdr_netobj->data's are > > > allocated, honestly there's no crusade to eliminate kmalloc()'s, I'll > > > only object in a case (like the struct svc_cred field above) where it > > > seems obviously unnecessary. > > > > Ok, so what should I do ? > > I can remove the static allocation and let the code allocate the data > > with kmalloc, in the xdr unmarshalling code. > > Whatever you like best. > > Just embed the svc_cred: > > > > - struct svc_cred *creds; > > > + struct svc_cred creds; Can't do, it needs to be allocated, because we steal it in scvauth_gss.c > and handle the rest whichever way seems cleanest to you. Ok. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
