[pnfs] [Fwd: [PATCH] update exchange id reply to draft 9]
Marc Eshel
eshel at almaden.ibm.com
Mon Mar 5 01:22:12 EST 2007
"J. Bruce Fields" <bfields at fieldses.org> wrote on 03/04/2007 10:07:47 PM:
> On Sun, Mar 04, 2007 at 07:36:46PM -0800, Marc Eshel wrote:
> > From: Marc Eshel <eshel at almaden.ibm.com>
> >
> > Had to reduce NFS4_OPAQUE_LIMIT from 1024 to 256 since few structs the
> > include it are defined on the stack. I am note sure why it needs to be
> > 1024 but if it must we will have to malloc those structs to avoid
stack
> > overflow.
>
> The NFS4_OPAQUE_LIMIT is defined as 1024 by the rfc, and it's the
> maximum length of client identifiers and stateowners. So in the
> (probably unlikely) event that a client sent us e.g. a client identifier
> of length more then 256 but less than 1024 and we rejected it for being
> too long, we'd fail to interoperate and it'd be our fault.
yes, I know we will need to support 1024 if the rfc can not changed. Even
if we solve the stack issue I wouln't want to support 1024 long names.
Some of the struct have 4 of them and and we have those stuct for each MDS
and DS.
> In any case, objects on the stack of size 256 bytes are still pushing
> it, so the solution is definitely to get those off the stack. What are
> those structs exactly?
>
static int nfs4_proc_exchange_id(struct nfs4_client *clp)
{
nfs4_verifier verifier;
struct nfs41_exchange_id_args args;
struct nfs41_exchange_id_res res = {
struct nfs_impl_id4 {
u32 domain_len;
char domain[NFS4_OPAQUE_LIMIT];
u32 name_len;
char name[NFS4_OPAQUE_LIMIT];
struct nfstime4 date;
};
struct nfs41_exchange_id_args {
nfs4_verifier * verifier;
unsigned int id_len;
char id[NFS4_OPAQUE_LIMIT];
u32 flags;
struct nfs_impl_id4 impl_id;
clientid4 clientid;
u32 seqid;
};
More information about the pNFS
mailing list