Hi J.,
After merging the nfsd tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
RPCGSS authentication"). gss_mech_get_by_OID() made static to
net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
tree that you did not merge).
I don't know how to fix this, so I have used the nfsd tree from
next-20130426 for today.
--
Cheers,
Stephen Rothwell [email protected]
On Apr 28, 2013, at 9:24 PM, Stephen Rothwell <[email protected]> wrote:
> Hi J.,
>
> After merging the nfsd tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
> net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
>
> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
> RPCGSS authentication"). gss_mech_get_by_OID() made static to
> net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
> Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
> tree that you did not merge).
>
> I don't know how to fix this, so I have used the nfsd tree from
> next-20130426 for today.
Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
>
> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell <[email protected]> wrote:
>
> > Hi J.,
> >
> > After merging the nfsd tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
> > net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
> >
> > Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
> > RPCGSS authentication"). gss_mech_get_by_OID() made static to
> > net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
> > Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
> > tree that you did not merge).
> >
> > I don't know how to fix this, so I have used the nfsd tree from
> > next-20130426 for today.
>
> Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed.
I'm happy to take those patches whenever you consider them ready. Would
that fix the problem?
Also: it looks like 030d794bf498 "SUNRPC: Introduce
rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
nfs-for-next. I'm not sure what that means--is it safe to rebase on top
of *that*?
I was hoping I could consider the gss-proxy work committed at this point
and pile any fixes on top, but... whatever works for you guys, I guess.
--b.
On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields" <[email protected]> wrote:
> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
>>
>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell <[email protected]> wrote:
>>
>>> Hi J.,
>>>
>>> After merging the nfsd tree, today's linux-next build (powerpc
>>> ppc64_defconfig) failed like this:
>>>
>>> net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
>>> net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
>>>
>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
>>> RPCGSS authentication"). gss_mech_get_by_OID() made static to
>>> net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
>>> Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
>>> tree that you did not merge).
>>>
>>> I don't know how to fix this, so I have used the nfsd tree from
>>> next-20130426 for today.
>>
>> Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed.
>
> I'm happy to take those patches whenever you consider them ready. Would
> that fix the problem?
Someone would need to modify the gssproxy patches to use the new interfaces.
> Also: it looks like 030d794bf498 "SUNRPC: Introduce
> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> nfs-for-next. I'm not sure what that means--is it safe to rebase on top
> of *that*?
That doesn't seem right to me.
> I was hoping I could consider the gss-proxy work committed at this point
> and pile any fixes on top, but... whatever works for you guys, I guess.
>
> --b.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields" <[email protected]> wrote:
>
> > On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
> >>
> >> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell <[email protected]> wrote:
> >>
> >>> Hi J.,
> >>>
> >>> After merging the nfsd tree, today's linux-next build (powerpc
> >>> ppc64_defconfig) failed like this:
> >>>
> >>> net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
> >>> net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
> >>>
> >>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
> >>> RPCGSS authentication"). gss_mech_get_by_OID() made static to
> >>> net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
> >>> Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
> >>> tree that you did not merge).
> >>>
> >>> I don't know how to fix this, so I have used the nfsd tree from
> >>> next-20130426 for today.
> >>
> >> Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed.
> >
> > I'm happy to take those patches whenever you consider them ready. Would
> > that fix the problem?
>
> Someone would need to modify the gssproxy patches to use the new interfaces.
>
> > Also: it looks like 030d794bf498 "SUNRPC: Introduce
> > rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> > nfs-for-next. I'm not sure what that means--is it safe to rebase on top
> > of *that*?
>
> That doesn't seem right to me.
GSS-Proxy patches are 1 year old and we've been delayed once already to
accomodate the containers work, maybe it's time for your patches to be
rebased on gssproxy ones ? :-)
Simo.
--
Simo Sorce * Red Hat, Inc * New York
On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields" <[email protected]> wrote:
>
> > On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
> >>
> >> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell <[email protected]> wrote:
> >>
> >>> Hi J.,
> >>>
> >>> After merging the nfsd tree, today's linux-next build (powerpc
> >>> ppc64_defconfig) failed like this:
> >>>
> >>> net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
> >>> net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
> >>>
> >>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
> >>> RPCGSS authentication"). gss_mech_get_by_OID() made static to
> >>> net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
> >>> Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
> >>> tree that you did not merge).
> >>>
> >>> I don't know how to fix this, so I have used the nfsd tree from
> >>> next-20130426 for today.
> >>
> >> Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed.
> >
> > I'm happy to take those patches whenever you consider them ready. Would
> > that fix the problem?
>
> Someone would need to modify the gssproxy patches to use the new interfaces.
>
> > Also: it looks like 030d794bf498 "SUNRPC: Introduce
> > rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> > nfs-for-next. I'm not sure what that means--is it safe to rebase on top
> > of *that*?
>
> That doesn't seem right to me.
I've now pulled the rpcsec_gss changes into the nfs-for-next. The main
reason why they were not pulled in earlier was due to uncertainty what
to do about the increase in "AUTH_GSS upcall timed out." syslog
warnings.
On Apr 29, 2013, at 12:29 PM, Simo Sorce <[email protected]> wrote:
> On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
>> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields" <[email protected]> wrote:
>>
>>> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
>>>>
>>>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell <[email protected]> wrote:
>>>>
>>>>> Hi J.,
>>>>>
>>>>> After merging the nfsd tree, today's linux-next build (powerpc
>>>>> ppc64_defconfig) failed like this:
>>>>>
>>>>> net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
>>>>> net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
>>>>>
>>>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
>>>>> RPCGSS authentication"). gss_mech_get_by_OID() made static to
>>>>> net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
>>>>> Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
>>>>> tree that you did not merge).
>>>>>
>>>>> I don't know how to fix this, so I have used the nfsd tree from
>>>>> next-20130426 for today.
>>>>
>>>> Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed.
>>>
>>> I'm happy to take those patches whenever you consider them ready. Would
>>> that fix the problem?
>>
>> Someone would need to modify the gssproxy patches to use the new interfaces.
>>
>>> Also: it looks like 030d794bf498 "SUNRPC: Introduce
>>> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
>>> nfs-for-next. I'm not sure what that means--is it safe to rebase on top
>>> of *that*?
>>
>> That doesn't seem right to me.
>
> GSS-Proxy patches are 1 year old and we've been delayed once already to
> accomodate the containers work, maybe it's time for your patches to be
> rebased on gssproxy ones ? :-)
Don't sweat it. IMO this is a simple merge problem, unlike the containers work.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Mon, 2013-04-29 at 12:37 -0400, Chuck Lever wrote:
> On Apr 29, 2013, at 12:29 PM, Simo Sorce <[email protected]> wrote:
>
> > On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
> >> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields" <[email protected]> wrote:
> >>
> >>> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
> >>>>
> >>>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell <[email protected]> wrote:
> >>>>
> >>>>> Hi J.,
> >>>>>
> >>>>> After merging the nfsd tree, today's linux-next build (powerpc
> >>>>> ppc64_defconfig) failed like this:
> >>>>>
> >>>>> net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
> >>>>> net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
> >>>>>
> >>>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
> >>>>> RPCGSS authentication"). gss_mech_get_by_OID() made static to
> >>>>> net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
> >>>>> Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
> >>>>> tree that you did not merge).
> >>>>>
> >>>>> I don't know how to fix this, so I have used the nfsd tree from
> >>>>> next-20130426 for today.
> >>>>
> >>>> Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed.
> >>>
> >>> I'm happy to take those patches whenever you consider them ready. Would
> >>> that fix the problem?
> >>
> >> Someone would need to modify the gssproxy patches to use the new interfaces.
> >>
> >>> Also: it looks like 030d794bf498 "SUNRPC: Introduce
> >>> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> >>> nfs-for-next. I'm not sure what that means--is it safe to rebase on top
> >>> of *that*?
> >>
> >> That doesn't seem right to me.
> >
> > GSS-Proxy patches are 1 year old and we've been delayed once already to
> > accomodate the containers work, maybe it's time for your patches to be
> > rebased on gssproxy ones ? :-)
>
> Don't sweat it. IMO this is a simple merge problem, unlike the containers work.
Glad to hear that.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
On Apr 29, 2013, at 12:21 PM, Trond Myklebust <[email protected]> wrote:
> On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
>> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields" <[email protected]> wrote:
>>
>>> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
>>>>
>>>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell <[email protected]> wrote:
>>>>
>>>>> Hi J.,
>>>>>
>>>>> After merging the nfsd tree, today's linux-next build (powerpc
>>>>> ppc64_defconfig) failed like this:
>>>>>
>>>>> net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
>>>>> net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
>>>>>
>>>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
>>>>> RPCGSS authentication"). gss_mech_get_by_OID() made static to
>>>>> net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
>>>>> Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
>>>>> tree that you did not merge).
>>>>>
>>>>> I don't know how to fix this, so I have used the nfsd tree from
>>>>> next-20130426 for today.
>>>>
>>>> Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed.
>>>
>>> I'm happy to take those patches whenever you consider them ready. Would
>>> that fix the problem?
>>
>> Someone would need to modify the gssproxy patches to use the new interfaces.
>>
>>> Also: it looks like 030d794bf498 "SUNRPC: Introduce
>>> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
>>> nfs-for-next. I'm not sure what that means--is it safe to rebase on top
>>> of *that*?
>>
>> That doesn't seem right to me.
>
> I've now pulled the rpcsec_gss changes into the nfs-for-next. The main
> reason why they were not pulled in earlier was due to uncertainty what
> to do about the increase in "AUTH_GSS upcall timed out." syslog
> warnings.
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.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Mon, 2013-04-29 at 13:04 -0400, Chuck Lever wrote:
> On Apr 29, 2013, at 12:21 PM, Trond Myklebust <[email protected]> wrote:
>
> > On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
> >> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields" <[email protected]> wrote:
> >>
> >>> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
> >>>>
> >>>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell <[email protected]> wrote:
> >>>>
> >>>>> Hi J.,
> >>>>>
> >>>>> After merging the nfsd tree, today's linux-next build (powerpc
> >>>>> ppc64_defconfig) failed like this:
> >>>>>
> >>>>> net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
> >>>>> net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration]
> >>>>>
> >>>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for server
> >>>>> RPCGSS authentication"). gss_mech_get_by_OID() made static to
> >>>>> net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d ("SUNRPC:
> >>>>> Introduce rpcauth_get_pseudoflavor()") in the nfs tree (part of the nfs
> >>>>> tree that you did not merge).
> >>>>>
> >>>>> I don't know how to fix this, so I have used the nfsd tree from
> >>>>> next-20130426 for today.
> >>>>
> >>>> Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed.
> >>>
> >>> I'm happy to take those patches whenever you consider them ready. Would
> >>> that fix the problem?
> >>
> >> Someone would need to modify the gssproxy patches to use the new interfaces.
> >>
> >>> Also: it looks like 030d794bf498 "SUNRPC: Introduce
> >>> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> >>> nfs-for-next. I'm not sure what that means--is it safe to rebase on top
> >>> of *that*?
> >>
> >> That doesn't seem right to me.
> >
> > I've now pulled the rpcsec_gss changes into the nfs-for-next. The main
> > reason why they were not pulled in earlier was due to uncertainty what
> > to do about the increase in "AUTH_GSS upcall timed out." syslog
> > warnings.
>
> 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.
The simplest way would be to make it not static again.
In my code we are using gss_mech_get_by_OID() instead of
gss_mech_get_by_name() because we have a OID passed down from gssproxy.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote:
>
> On Apr 29, 2013, at 12:21 PM, Trond Myklebust
> <[email protected]> wrote:
>
> > On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
> >> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields"
> >> <[email protected]> wrote:
> >>
> >>> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
> >>>>
> >>>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell
> >>>> <[email protected]> wrote:
> >>>>
> >>>>> Hi J.,
> >>>>>
> >>>>> After merging the nfsd tree, today's linux-next build (powerpc
> >>>>> ppc64_defconfig) failed like this:
> >>>>>
> >>>>> net/sunrpc/auth_gss/svcauth_gss.c: In function
> >>>>> 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3:
> >>>>> error: implicit declaration of function 'gss_mech_get_by_OID'
> >>>>> [-Werror=implicit-function-declaration]
> >>>>>
> >>>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for
> >>>>> server RPCGSS authentication"). gss_mech_get_by_OID() made
> >>>>> static to net/sunrpc/auth_gss/gss_mech_switch.c by commit
> >>>>> 9568c5e9a61d ("SUNRPC: Introduce rpcauth_get_pseudoflavor()") in
> >>>>> the nfs tree (part of the nfs tree that you did not merge).
> >>>>>
> >>>>> I don't know how to fix this, so I have used the nfsd tree from
> >>>>> next-20130426 for today.
> >>>>
> >>>> Bruce, it might make sense for me to submit the three server-side
> >>>> RPC GSS patches, and then you can rebase the gssproxy work on top
> >>>> of those. Let me know how you would like to proceed.
> >>>
> >>> I'm happy to take those patches whenever you consider them ready.
> >>> Would that fix the problem?
> >>
> >> Someone would need to modify the gssproxy patches to use the new
> >> interfaces.
> >>
> >>> Also: it looks like 030d794bf498 "SUNRPC: Introduce
> >>> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> >>> nfs-for-next. I'm not sure what that means--is it safe to rebase
> >>> on top of *that*?
> >>
> >> That doesn't seem right to me.
> >
> > I've now pulled the rpcsec_gss changes into the nfs-for-next. The
> > main reason why they were not pulled in earlier was due to
> > uncertainty what to do about the increase in "AUTH_GSS upcall timed
> > out." syslog warnings.
>
> 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().
--b.
On Apr 29, 2013, at 1:38 PM, "J. Bruce Fields" <[email protected]> wrote:
> On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote:
>>
>> On Apr 29, 2013, at 12:21 PM, Trond Myklebust
>> <[email protected]> wrote:
>>
>>> On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
>>>> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields"
>>>> <[email protected]> wrote:
>>>>
>>>>> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
>>>>>>
>>>>>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell
>>>>>> <[email protected]> wrote:
>>>>>>
>>>>>>> Hi J.,
>>>>>>>
>>>>>>> After merging the nfsd tree, today's linux-next build (powerpc
>>>>>>> ppc64_defconfig) failed like this:
>>>>>>>
>>>>>>> net/sunrpc/auth_gss/svcauth_gss.c: In function
>>>>>>> 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3:
>>>>>>> error: implicit declaration of function 'gss_mech_get_by_OID'
>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>
>>>>>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for
>>>>>>> server RPCGSS authentication"). gss_mech_get_by_OID() made
>>>>>>> static to net/sunrpc/auth_gss/gss_mech_switch.c by commit
>>>>>>> 9568c5e9a61d ("SUNRPC: Introduce rpcauth_get_pseudoflavor()") in
>>>>>>> the nfs tree (part of the nfs tree that you did not merge).
>>>>>>>
>>>>>>> I don't know how to fix this, so I have used the nfsd tree from
>>>>>>> next-20130426 for today.
>>>>>>
>>>>>> Bruce, it might make sense for me to submit the three server-side
>>>>>> RPC GSS patches, and then you can rebase the gssproxy work on top
>>>>>> of those. Let me know how you would like to proceed.
>>>>>
>>>>> I'm happy to take those patches whenever you consider them ready.
>>>>> Would that fix the problem?
>>>>
>>>> Someone would need to modify the gssproxy patches to use the new
>>>> interfaces.
>>>>
>>>>> Also: it looks like 030d794bf498 "SUNRPC: Introduce
>>>>> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
>>>>> nfs-for-next. I'm not sure what that means--is it safe to rebase
>>>>> on top of *that*?
>>>>
>>>> That doesn't seem right to me.
>>>
>>> I've now pulled the rpcsec_gss changes into the nfs-for-next. The
>>> main reason why they were not pulled in earlier was due to
>>> uncertainty what to do about the increase in "AUTH_GSS upcall timed
>>> out." syslog warnings.
>>
>> 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?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Mon, 2013-04-29 at 13:47 -0400, Chuck Lever wrote:
> On Apr 29, 2013, at 1:38 PM, "J. Bruce Fields" <[email protected]> wrote:
>
> > On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote:
> >>
> >> On Apr 29, 2013, at 12:21 PM, Trond Myklebust
> >> <[email protected]> wrote:
> >>
> >>> On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
> >>>> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields"
> >>>> <[email protected]> wrote:
> >>>>
> >>>>> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
> >>>>>>
> >>>>>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell
> >>>>>> <[email protected]> wrote:
> >>>>>>
> >>>>>>> Hi J.,
> >>>>>>>
> >>>>>>> After merging the nfsd tree, today's linux-next build (powerpc
> >>>>>>> ppc64_defconfig) failed like this:
> >>>>>>>
> >>>>>>> net/sunrpc/auth_gss/svcauth_gss.c: In function
> >>>>>>> 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3:
> >>>>>>> error: implicit declaration of function 'gss_mech_get_by_OID'
> >>>>>>> [-Werror=implicit-function-declaration]
> >>>>>>>
> >>>>>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for
> >>>>>>> server RPCGSS authentication"). gss_mech_get_by_OID() made
> >>>>>>> static to net/sunrpc/auth_gss/gss_mech_switch.c by commit
> >>>>>>> 9568c5e9a61d ("SUNRPC: Introduce rpcauth_get_pseudoflavor()") in
> >>>>>>> the nfs tree (part of the nfs tree that you did not merge).
> >>>>>>>
> >>>>>>> I don't know how to fix this, so I have used the nfsd tree from
> >>>>>>> next-20130426 for today.
> >>>>>>
> >>>>>> Bruce, it might make sense for me to submit the three server-side
> >>>>>> RPC GSS patches, and then you can rebase the gssproxy work on top
> >>>>>> of those. Let me know how you would like to proceed.
> >>>>>
> >>>>> I'm happy to take those patches whenever you consider them ready.
> >>>>> Would that fix the problem?
> >>>>
> >>>> Someone would need to modify the gssproxy patches to use the new
> >>>> interfaces.
> >>>>
> >>>>> Also: it looks like 030d794bf498 "SUNRPC: Introduce
> >>>>> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> >>>>> nfs-for-next. I'm not sure what that means--is it safe to rebase
> >>>>> on top of *that*?
> >>>>
> >>>> That doesn't seem right to me.
> >>>
> >>> I've now pulled the rpcsec_gss changes into the nfs-for-next. The
> >>> main reason why they were not pulled in earlier was due to
> >>> uncertainty what to do about the increase in "AUTH_GSS upcall timed
> >>> out." syslog warnings.
> >>
> >> 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?
>
Does gss_mech_get_by_name() do the loading ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
On Mon, Apr 29, 2013 at 01:47:16PM -0400, Chuck Lever wrote:
>
> On Apr 29, 2013, at 1:38 PM, "J. Bruce Fields" <[email protected]> wrote:
>
> > On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote:
> >>
> >> On Apr 29, 2013, at 12:21 PM, Trond Myklebust
> >> <[email protected]> wrote:
> >>
> >>> On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
> >>>> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields"
> >>>> <[email protected]> wrote:
> >>>>
> >>>>> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
> >>>>>>
> >>>>>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell
> >>>>>> <[email protected]> wrote:
> >>>>>>
> >>>>>>> Hi J.,
> >>>>>>>
> >>>>>>> After merging the nfsd tree, today's linux-next build (powerpc
> >>>>>>> ppc64_defconfig) failed like this:
> >>>>>>>
> >>>>>>> net/sunrpc/auth_gss/svcauth_gss.c: In function
> >>>>>>> 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3:
> >>>>>>> error: implicit declaration of function 'gss_mech_get_by_OID'
> >>>>>>> [-Werror=implicit-function-declaration]
> >>>>>>>
> >>>>>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for
> >>>>>>> server RPCGSS authentication"). gss_mech_get_by_OID() made
> >>>>>>> static to net/sunrpc/auth_gss/gss_mech_switch.c by commit
> >>>>>>> 9568c5e9a61d ("SUNRPC: Introduce rpcauth_get_pseudoflavor()") in
> >>>>>>> the nfs tree (part of the nfs tree that you did not merge).
> >>>>>>>
> >>>>>>> I don't know how to fix this, so I have used the nfsd tree from
> >>>>>>> next-20130426 for today.
> >>>>>>
> >>>>>> Bruce, it might make sense for me to submit the three server-side
> >>>>>> RPC GSS patches, and then you can rebase the gssproxy work on top
> >>>>>> of those. Let me know how you would like to proceed.
> >>>>>
> >>>>> I'm happy to take those patches whenever you consider them ready.
> >>>>> Would that fix the problem?
> >>>>
> >>>> Someone would need to modify the gssproxy patches to use the new
> >>>> interfaces.
> >>>>
> >>>>> Also: it looks like 030d794bf498 "SUNRPC: Introduce
> >>>>> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> >>>>> nfs-for-next. I'm not sure what that means--is it safe to rebase
> >>>>> on top of *that*?
> >>>>
> >>>> That doesn't seem right to me.
> >>>
> >>> I've now pulled the rpcsec_gss changes into the nfs-for-next. The
> >>> main reason why they were not pulled in earlier was due to
> >>> uncertainty what to do about the increase in "AUTH_GSS upcall timed
> >>> out." syslog warnings.
> >>
> >> 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?
--b.
On Apr 29, 2013, at 1:59 PM, "J. Bruce Fields" <[email protected]> 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" <[email protected]> wrote:
>>
>>> On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote:
>>>>
>>>> On Apr 29, 2013, at 12:21 PM, Trond Myklebust
>>>> <[email protected]> wrote:
>>>>
>>>>> On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
>>>>>> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields"
>>>>>> <[email protected]> wrote:
>>>>>>
>>>>>>> On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote:
>>>>>>>>
>>>>>>>> On Apr 28, 2013, at 9:24 PM, Stephen Rothwell
>>>>>>>> <[email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi J.,
>>>>>>>>>
>>>>>>>>> After merging the nfsd tree, today's linux-next build (powerpc
>>>>>>>>> ppc64_defconfig) failed like this:
>>>>>>>>>
>>>>>>>>> net/sunrpc/auth_gss/svcauth_gss.c: In function
>>>>>>>>> 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3:
>>>>>>>>> error: implicit declaration of function 'gss_mech_get_by_OID'
>>>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>>>
>>>>>>>>> Caused byc ommit 030d794bf498 ("SUNRPC: Use gssproxy upcall for
>>>>>>>>> server RPCGSS authentication"). gss_mech_get_by_OID() made
>>>>>>>>> static to net/sunrpc/auth_gss/gss_mech_switch.c by commit
>>>>>>>>> 9568c5e9a61d ("SUNRPC: Introduce rpcauth_get_pseudoflavor()") in
>>>>>>>>> the nfs tree (part of the nfs tree that you did not merge).
>>>>>>>>>
>>>>>>>>> I don't know how to fix this, so I have used the nfsd tree from
>>>>>>>>> next-20130426 for today.
>>>>>>>>
>>>>>>>> Bruce, it might make sense for me to submit the three server-side
>>>>>>>> RPC GSS patches, and then you can rebase the gssproxy work on top
>>>>>>>> of those. Let me know how you would like to proceed.
>>>>>>>
>>>>>>> I'm happy to take those patches whenever you consider them ready.
>>>>>>> Would that fix the problem?
>>>>>>
>>>>>> Someone would need to modify the gssproxy patches to use the new
>>>>>> interfaces.
>>>>>>
>>>>>>> Also: it looks like 030d794bf498 "SUNRPC: Introduce
>>>>>>> rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
>>>>>>> nfs-for-next. I'm not sure what that means--is it safe to rebase
>>>>>>> on top of *that*?
>>>>>>
>>>>>> That doesn't seem right to me.
>>>>>
>>>>> I've now pulled the rpcsec_gss changes into the nfs-for-next. The
>>>>> main reason why they were not pulled in earlier was due to
>>>>> uncertainty what to do about the increase in "AUTH_GSS upcall timed
>>>>> out." syslog warnings.
>>>>
>>>> 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.
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.
Do you have gssproxy patches published in a git tree somewhere I could review?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Mon, Apr 29, 2013 at 02:30:33PM -0400, Chuck Lever wrote:
>
> On Apr 29, 2013, at 1:59 PM, "J. Bruce Fields" <[email protected]>
> 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"
> >> <[email protected]> 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.
On Apr 29, 2013, at 2:57 PM, J. Bruce Fields <[email protected]> wrote:
> On Mon, Apr 29, 2013 at 02:30:33PM -0400, Chuck Lever wrote:
>>
>> On Apr 29, 2013, at 1:59 PM, "J. Bruce Fields" <[email protected]>
>> 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"
>>>> <[email protected]> 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.
RPC server GSS support didn't need the gss_mech_get_by_OID() interface before gssproxy, so I'm trying to understand why it is needed now.
But it sounds like you do need it now, so go ahead and make gss_mech_get_by_OID() global within the AUTH_GSS module.
>
>> 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.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com