From: "J. Bruce Fields" <bfields@fieldses.org>
To: Simo Sorce <simo@redhat.com>
Cc: bfields@redhat.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 3/4] SUNRPC: Add RPC based upcall mechanism for RPCGSS auth
Date: Tue, 22 May 2012 11:02:21 -0400 [thread overview]
Message-ID: <20120522150221.GD891@fieldses.org> (raw)
In-Reply-To: <1337087550-9821-4-git-send-email-simo@redhat.com>
On Tue, May 15, 2012 at 09:12:29AM -0400, Simo Sorce wrote:
> +/* numbers somewhat arbitrary but large enough for current needs */
> +#define GSSX_MAX_OUT_HANDLE 128
> +#define GSSX_MAX_MECH_OID 16
> +#define GSSX_MAX_SRC_PRINC 256
> +#define GSSX_KMEMBUF (GSSX_max_output_handle_sz + \
> + GSSX_max_oid_sz + \
> + GSSX_max_princ_sz + \
> + sizeof(struct svc_cred))
> +
...
> + data->kmembuf = kmalloc(GSSX_KMEMBUF, GFP_KERNEL);
...
> + rctxh.exported_context_token.data = data->kmembuf;
...
> + rctxh.mech.data = data->kmembuf + GSSX_max_output_handle_sz;
...
> + rctxh.src_name.display_name.data = data->kmembuf +
> + GSSX_max_output_handle_sz +
> + GSSX_max_oid_sz;
...
> + data->creds = data->kmembuf +
> + GSSX_max_output_handle_sz +
> + GSSX_max_oid_sz +
> + GSSX_max_princ_sz;
Sorry, is this did I complaining about too many kmalloc()'s? 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.
But why not just include this in gssp_upcall_data?:
struct gssp_upcall_data {
- void *kmembuf;
struct xdr_netobj in_handle;
struct gssp_in_token in_token;
struct xdr_netobj out_handle;
+ char out_handle_data[GSSX_MAX_OUT_HANDLE];
struct xdr_netobj out_token;
struct xdr_netobj mech_oid;
+ char mech_oid_data[GSSX_MAX_MECH_OID];
struct xdr_netobj client_name;
+ char client_name_data[GSSX_MAX_SRC_PRINC];
- struct svc_cred *creds;
+ struct svc_cred creds;
int major_status;
int minor_status;
};
As long as that still comes to under 4k that should be OK.
Oh, I see, and you'd have to alloc/free this in svcauth_gss_proxy_init
instead of here, to avoid putting it on the stack there.
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.
--b.
next prev parent reply other threads:[~2012-05-22 15:02 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 13:12 [PATCH 0/4] Add support for new upcall mechanism for nfsd Simo Sorce
2012-05-15 13:12 ` [PATCH 1/4] SUNRPC: conditionally return endtime from import_sec_context Simo Sorce
2012-05-21 21:52 ` J. Bruce Fields
2012-05-15 13:12 ` [PATCH 2/4] SUNRPC: Document a bit RPCGSS handling in the NFS Server Simo Sorce
2012-05-21 21:55 ` J. Bruce Fields
2012-05-22 0:37 ` Simo Sorce
2012-05-15 13:12 ` [PATCH 3/4] SUNRPC: Add RPC based upcall mechanism for RPCGSS auth Simo Sorce
2012-05-22 12:47 ` J. Bruce Fields
2012-05-22 13:00 ` Simo Sorce
2012-05-22 13:17 ` Stanislav Kinsbursky
2012-05-22 13:22 ` Simo Sorce
2012-05-22 13:32 ` Stanislav Kinsbursky
2012-05-22 14:20 ` J. Bruce Fields
2012-05-22 14:44 ` Stanislav Kinsbursky
2012-05-22 15:07 ` J. Bruce Fields
2012-05-22 15:16 ` Simo Sorce
2012-05-22 15:31 ` J. Bruce Fields
2012-05-22 15:44 ` Simo Sorce
2012-05-22 15:19 ` Stanislav Kinsbursky
2012-05-22 18:11 ` J. Bruce Fields
2012-05-22 18:41 ` Stanislav Kinsbursky
2012-05-22 14:58 ` Simo Sorce
2012-05-22 15:10 ` Stanislav Kinsbursky
2012-05-22 15:18 ` Simo Sorce
2012-05-22 15:23 ` Stanislav Kinsbursky
2012-05-22 13:00 ` Stanislav Kinsbursky
2012-05-22 15:02 ` J. Bruce Fields [this message]
2012-05-22 15:15 ` Simo Sorce
2012-05-22 15:29 ` J. Bruce Fields
2012-05-22 15:40 ` Simo Sorce
2012-05-22 22:49 ` J. Bruce Fields
2012-05-22 22:52 ` Simo Sorce
2012-05-22 15:03 ` J. Bruce Fields
2012-05-22 15:12 ` Simo Sorce
2012-05-22 15:24 ` J. Bruce Fields
2012-05-22 15:36 ` Simo Sorce
2012-05-15 13:12 ` [PATCH 4/4] SUNRPC: Use gssproxy upcall for nfsd's RPCGSS authentication Simo Sorce
2012-05-22 22:48 ` J. Bruce Fields
2012-05-24 4:31 ` Simo Sorce
2012-05-24 11:08 ` J. Bruce Fields
2012-05-24 13:19 ` Simo Sorce
2012-05-25 14:05 ` J. Bruce Fields
2012-05-25 15:37 ` Simo Sorce
-- strict thread matches above, loose matches on Subject: below --
2012-05-25 22:09 [PATCH 0/4] Add support for new RPCSEC_GSS upcall mechanism for nfsd Simo Sorce
2012-05-25 22:09 ` [PATCH 3/4] SUNRPC: Add RPC based upcall mechanism for RPCGSS auth Simo Sorce
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=20120522150221.GD891@fieldses.org \
--to=bfields@fieldses.org \
--cc=bfields@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=simo@redhat.com \
/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.