Will Fiveash wrote: > On Wed, Jun 10, 2009 at 10:09:32PM -0700, Glenn Barry wrote: > >> 6791302 RPCSEC_GSS svc should be able to handle a misbehaving client >> >> http://cr.opensolaris.org/~gtb/6791302/webrev-O/ >> >> These changes include >> >> * __svcrpcsec_gss()/rpcsec_gss_init() offloads RPCSEC_GSS_INIT calls to a >> taskq >> >> * __svcrpcsec_gss() has been refactored from one 500ln func for all proc >> types -- that was hard to grok -- to basically a switch(proctype) and each >> proc type has it own func now >> >> * svc_rpcsec_gss.c in the onnv gate is not cstyle clean but this one is >> cstyle clean >> > >
sorry, missed this one the other day ... > In svc.c: > 2697 oa_src = src->rm_call.cb_verf; > > - what is the point of this assignment (oa_src isn't accessed after). > gtb: good catch, not needed. > 2700 oa_dst.oa_base = kmem_alloc(MAX_AUTH_BYTES, KM_SLEEP); > > - Why the mem alloc here (why not just set oa_base NULL)? > gtb: Because the callers expect that to be alloced. I'll make that clear in the comments. > 2729 m = NULL; > > - Why? > gtb: yea, not necessary. > In svc_rpcsec_gss.c: > > 236 int rpcsec_gss_init_taskq_nthreads = 1; > > - Is this variable necessary (why not pass 1 to ddi_taskq_create)? > > gtb: adds a little flexibility as can be set on fly via mdb(1). > 689 do_init() > > - Nit: shouldn't this be called do_gss_accept()? > > gtb: Nico does like that name either, will change it. Less is more. Except when it is not. > rpcsec_gss_init( > struct svc_req *rqst, > struct rpc_msg *msg, > rpc_gss_creds creds, > bool_t *no_dispatch, > > and further down: > *no_dispatch = TRUE; > > - What does no_dispatch do? > > gtb: You've probably seen Nico's answer to this already. When dealing with this part of the RPC stack, it's def a key pt. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/kerberos-discuss/attachments/20090707/485fe7fb/attachment.html>
