Re: linux-next: build failure after merge of the nfsd tree

[J. Bruce Fields]

On Mon, Apr 29, 2013 at 02:30:33PM -0400, Chuck Lever wrote:
> 
> On Apr 29, 2013, at 1:59 PM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>
> wrote:
> 
> > On Mon, Apr 29, 2013 at 01:47:16PM -0400, Chuck Lever wrote:
> >> 
> >> On Apr 29, 2013, at 1:38 PM, "J. Bruce Fields"
> >> <bfields@xxxxxxxxxxxx> wrote:
> >> 
> >>> On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote:
> >>>> Trond's nfs-for-next now has the new rpcauth_get_gssinfo() and
> >>>> rpcauth_get_pseudoflavor() APIs, which are replacements for
> >>>> direct calls into the GSS mech switch.  These APIs are a little
> >>>> more generic, and more robust in the face of unloaded GSS kernel
> >>>> modules.
> >>>> 
> >>>> Instead of gss_mech_get_by_OID(), I suspect you want
> >>>> rpcauth_get_pseudoflavor(), but I haven't looked at the gssproxy
> >>>> code.
> >>> 
> >>> It's doing
> >>> 
> >>> 		status = -EOPNOTSUPP; gm =
> >>> 		gss_mech_get_by_OID(&ud->mech_oid); if (!gm) goto out;
> >>> 		status = -EINVAL; status =
> >>> 		gss_import_sec_context(ud->out_handle.data,
> >>> 		ud->out_handle.len, gm, &rsci.mechctx, &expiry,
> >>> 		GFP_KERNEL); if (status) goto out;
> >>> 
> >>> So we need a way to get from an OID and some mechanism-specific
> >>> data to a context.
> >>> 
> >>> Looks to me like we just want to re-export gss_mech_get_by_OID().
> >> 
> >> The reason for the new wrappers is to load the kernel modules
> >> properly before trying to discover the OID -> mechanism mapping.
> >> 
> >> Where are you calling it from?  If it's from outside of the GSS
> >> module, how do you guarantee the rpc_gss_auth module is loaded?
> >> What if the GSS mechanism for that OID isn't loaded?
> > 
> > Sorry, I should have said just "remove static from", not
> > "re-export"--it's in the same module.  So there should be no problem
> > here, right?
> 
> OK, gotcha.  Architecturally outside of the mech switch I'd like to
> see OIDs passed around embedded in GSS tuples rather than by
> themselves.

I'm not sure what you mean.  When I accept a gss context I don't yet
know what service or qop it's going to be used with, I only know the
mechanism OID.

> An alternative would be to use gss_mech_get_by_name(), which is
> already visible, loads GSS mechanism modules automatically, and
> returns struct gss_api_mech *.  For NFS, we should already have a
> clean mapping of mechanism name to pseudoflavor to GSS tuple.  Looks
> like rsc_parse() already uses this API.

We don't have a name here, only an OID.

> Do you have gssproxy patches published in a git tree somewhere I could
> review?

It's in my for-3.10 branch.

Which is more or less what I plan to submit for 3.10, so I'd prefer not
to rebase it at this point.

It looks like just removing "static" would resolve the immediate
conflict, is that right?  And then I'd happily help deal with cleaning
up the API as followup work.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/