On Tuesday May 1, [EMAIL PROTECTED] wrote:
> 
> Resending patch with a proper signed-off-by line. Also cc'ing Andrew:

Thanks, but it isn't much good to Andrew without a changelog entry,
though probably it should just go in as
  rpc--add-wrapper-for-svc_reserve-to-account-for-checksum-fix

Acked-by: NeilBrown <[EMAIL PROTECTED]>

(If it doesn't appear in the next -mm, I'll send it all nicely
formated and changeloged).

NeilBrown

> 
> Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
> 
> diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
> index 9114f11..ed7cbf1 100644
> --- a/include/linux/sunrpc/svc.h
> +++ b/include/linux/sunrpc/svc.h
> @@ -399,10 +399,9 @@ char *              svc_print_addr(struct svc_rqst *, 
> char *, size_t);
>  /*
>   * When we want to reduce the size of the reserved space in the response
>   * buffer, we need to take into account the size of any checksum data that
> - * may be at the end of the packet. For now, just use a hardcoded value
> - * for each possible authflavor. This will need to be updated when new
> - * encryption types or algorithms are added, or we'll have to come up with
> - * a way to reasonably calculate this on the fly (maybe via a new auth_op).
> + * may be at the end of the packet. This is difficult to determine exactly
> + * for all cases without actually generating the checksum, so we just use a
> + * static value.
>   */
>  static inline void 
>  svc_reserve_auth(struct svc_rqst *rqstp, int space)
> @@ -411,7 +410,7 @@ svc_reserve_auth(struct svc_rqst *rqstp, int space)
>  
>       switch(rqstp->rq_authop->flavour) {
>               case RPC_AUTH_GSS:
> -                     added_space = 56; /* determined empirically */
> +                     added_space = RPC_MAX_AUTH_SIZE;
>       }
>       return svc_reserve(rqstp, space + added_space);
>  }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to