All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 01/22] gss_krb5: introduce encryption type framework
Date: Tue, 16 Mar 2010 17:47:54 -0400	[thread overview]
Message-ID: <4B9FFC8A.6070802@RedHat.com> (raw)
In-Reply-To: <1268774075.3098.56.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>

On 03/16/2010 05:14 PM, Trond Myklebust wrote:
> On Tue, 2010-03-16 at 16:49 -0400, Steve Dickson wrote: 
>>
>> On 03/15/2010 11:58 AM, Trond Myklebust wrote:
>>> On Mon, 2010-03-15 at 08:20 -0400, steved@redhat.com wrote: 
>>>> @@ -1317,15 +1317,21 @@ gss_wrap_req_priv(struct rpc_cred *cred, struct gss_cl_ctx *ctx,
>>>>  	inpages = snd_buf->pages + first;
>>>>  	snd_buf->pages = rqstp->rq_enc_pages;
>>>>  	snd_buf->page_base -= first << PAGE_CACHE_SHIFT;
>>>> -	/* Give the tail its own page, in case we need extra space in the
>>>> -	 * head when wrapping: */
>>>> +	/*
>>>> +	 * Give the tail its own page, in case we need extra space in the
>>>> +	 * head when wrapping:
>>>> +	 *
>>>> +	 * call_allocate() allocates twice the slack space required
>>>> +	 * by the authentication flavor to rq_callsize.
>>>> +	 * For GSS, slack is GSS_CRED_SLACK.
>>>> +	 */
>>>
>>> I'm all for improving the comments in the code, but could we please make
>>> that a separate patch.
>> Really? I'm curious... what is not clear about the above diff
> 
> The comments are unrelated to the functionality changes of the patch,
> and are distracting when you are just trying to figure out those
> changes.
> Splitting out the comments (except those directly related to code that
> is being changed) therefore helps readability.
I guess.. but at the end of the day it all ends up in the
same place... 

The comments will be broken into a separate patch... 

> 
>>>> +
>>>> +	GSS_KRB5_SLACK_CHECK;
>>>           ^^^^^^^^^^^^^^^^^^^^^
>>>               Why is this a macro?
>> To hide the ugliness of the BUILD_BUG_ON() macro which I think
>> is a good thing... I would rather see that one line verse the 10
>> or so lines it hiding... 
> 
> I wouldn't.
> 
> I can accept putting that _sum_ into a macro, but expanding the
> BUILD_BUG_ON.
> 
> IOW:
> 
> #define GSS_KRB5_MAX_SLACK_NEEDED \
> 	GSS_KRB5_TOK_HDR_LEN      /* gss token header */         \
> 	+ GSS_KRB5_MAX_CKSUM_LEN  /* gss token checksum */       \
> 	+ GSS_KRB5_MAX_BLOCKSIZE  /* confounder */               \
> 	.... \
> 	)
> 
> and then inserting the following line above
> 
> BUILD_BUG_ON(GSS_KRB5_MAX_SLACK_NEEDED > RPC_MAX_AUTH_SIZE);
> 
> That makes it obvious what is being checked and why.

The above BUILD_BUG_ON() will be added... 


steved.


  parent reply	other threads:[~2010-03-16 21:48 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15 12:20 [PATCH 00/22] Add new enctypes for gss_krb5 (Round 4) steved
2010-03-15 12:20 ` [PATCH 01/22] gss_krb5: introduce encryption type framework steved
2010-03-15 15:58   ` Trond Myklebust
     [not found]     ` <1268668733.2993.90.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-03-16 20:49       ` Steve Dickson
     [not found]         ` <4B9FEEE0.8040306-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-03-16 21:14           ` Trond Myklebust
     [not found]             ` <1268774075.3098.56.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-03-16 21:45               ` Kevin Coffman
2010-03-16 21:47               ` Steve Dickson [this message]
2010-03-15 12:20 ` [PATCH 02/22] Don't expect blocksize to always be 8 when calculating padding steved
2010-03-15 16:02   ` Trond Myklebust
     [not found]     ` <1268668930.2993.91.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-03-15 23:38       ` J. Bruce Fields
2010-03-17 11:55         ` Steve Dickson
2010-03-15 12:20 ` [PATCH 03/22] gss_krb5: gss_krb5: split up functions in preparation of adding new enctypes steved
2010-03-15 12:20 ` [PATCH 04/22] gss_krb5: prepare for new context format steved
2010-03-15 12:20 ` [PATCH 05/22] gss_krb5: introduce encryption type framework steved
2010-03-15 16:12   ` Trond Myklebust
2010-03-15 12:20 ` [PATCH 06/22] gss_krb5: add ability to have a keyed checksum (hmac) steved
2010-03-15 12:20 ` [PATCH 07/22] gss_krb5: import functionality to derive keys into the kernel steved
2010-03-15 12:20 ` [PATCH 08/22] gss_krb5: handle new context format from gssd steved
2010-03-15 12:20 ` [PATCH 09/22] gss_krb5: add support for triple-des encryption steved
2010-03-15 12:20 ` [PATCH 10/22] Add new pipefs file indicating which Kerberos enctypes the kernel supports steved
2010-03-15 16:28   ` Trond Myklebust
     [not found]     ` <1268670503.2993.103.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-03-15 16:36       ` Al Viro
2010-03-15 23:43   ` J. Bruce Fields
2010-03-15 12:20 ` [PATCH 11/22] Update " steved
2010-03-15 12:20 ` [PATCH 12/22] xdr: Add an export for the helper function write_bytes_to_xdr_buf() steved
2010-03-15 16:29   ` Trond Myklebust
2010-03-15 12:20 ` [PATCH 13/22] gss_krb5: add support for new token formats in rfc4121 steved
2010-03-15 16:34   ` Trond Myklebust
2010-03-15 12:20 ` [PATCH 14/22] gss_krb5: add remaining pieces to enable AES encryption support steved
2010-03-15 12:20 ` [PATCH 15/22] gss_krb5: Update pipefs file steved
2010-03-15 12:20 ` [PATCH 16/22] arcfour-hmac support steved
2010-03-15 12:20 ` [PATCH 17/22] Save the raw session key in the context steved
2010-03-15 12:20 ` [PATCH 18/22] More arcfour-hmac support steved
2010-03-15 16:41   ` Trond Myklebust
2010-03-15 12:20 ` [PATCH 19/22] Use confounder length in wrap code steved
2010-03-15 12:20 ` [PATCH 20/22] Add support for rc4-hmac encryption steved
2010-03-15 12:20 ` [PATCH 21/22] Update the pipefs file steved
2010-03-15 12:20 ` [PATCH 22/22] Fixed memory leak in gss_import_v1_context() steved
  -- strict thread matches above, loose matches on Subject: below --
2010-04-14 17:36 [PATCH 00/22] Add support for more RPCSEC_GSS/krb5 enctypes Trond Myklebust
2010-04-14 17:36 ` [PATCH 01/22] gss_krb5: Introduce encryption type framework Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B9FFC8A.6070802@RedHat.com \
    --to=steved@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.