This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 62969 - Can not share RPC client handle between threads
Can not share RPC client handle between threads
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.2
i386 Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-08 13:33 EDT by Need Real Name
Modified: 2016-11-24 10:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-23 20:06:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-04-08 13:33:55 EDT
Description of Problem:
If I call authnone_create() in one thread, and then try to use
it via AUTH_MARSHAL in another thread, the AUTH_MARSHAL call
fails because authnone_private is grabbed from that thread's
local state (where it's still null).  

Version-Release number of selected component (if applicable):
glibc-2.2.4-13

How Reproducible:
Always

Steps to Reproduce:
1. Create a multi threaded program that does RPCs with a shared client handle
2. 
3. 

Actual Results:
RPC fails with CANTENCODEARGS

Expected Results:
RPC_SUCCESS

Additional Information:
Looks like each thread needs to do an authnone_create() or something similiar 
to initialize this.  Shouldn't it just default?
Comment 1 Jakub Jelinek 2002-04-09 08:35:28 EDT
Why do you think it is a bug?
RPC is not shared between threads, each one has its own.
Comment 2 Need Real Name 2002-04-09 11:24:22 EDT
1.  The behavior was different in the glibc delivered with Red Hat 6.2.
2.  The RPC client handle is a global handle in a library that is shared among 
a single applications threads.  The first call into the library will cause the 
handle to be created.  Only this thread can use the handle.  If the other 
threads want to use the handle, they have to do an some form of authentication 
instead of picking up the default 'authnone' from the 'clnt_create'.  According 
to ONCRPC when a client handle is created with one of the clnt..._create() 
functions, the credential fields are NULL, signifying no credentials or 
verification to be performed at the server.  However, it appears that with 
glibc-2.2.4-13 this is not with the client but private to a thread which is 
good if you want to have different threads have different credentials.  
However, I still think that all threads should first get "a default" and then 
be able to change this default as needed.
Comment 3 Need Real Name 2002-05-08 12:22:34 EDT
We have been bitten by this bug as well.  The required workaround places a
serious bookkeeping burden on multi-threaded clients.

This excerpt from Sun's online documentation gives a good indication of the
correct semantics:

In a multithread client program, a thread can be created to issue each RPC
request. When multiple threads share the same client handle, only one thread at
a time will be able to make an RPC request. All other threads will wait until
the outstanding request is complete. On the other hand, when multiple threads
make RPC requests using different client handles, the requests are carried     
out concurrently. Figure 4-1 illustrates a possible timing of a multithreaded
client implementation consisting of two client threads using different client
handles.
------

Thanks - rk@spinnakernet.com
Comment 4 Mike McLean 2003-01-02 13:46:28 EST
This bug has been inappropriately marked MODIFIED. Please review the bug life
cycle information at 
http://bugzilla.redhat.com/bugzilla/bug_status.cgi

Changing bug status to ASSIGNED.
Comment 5 Ulrich Drepper 2003-04-23 20:06:42 EDT
This is how RPC in multi-threaded apps is designed to work now.  Before the
change (before RHL7.2) RPC better never was used in multi-threaded apps.  It
couldn't work reliable.  Now the RPC state is thread local which brings with it
its own set of limitations but it's better than nothing.
Comment 6 Mark Tsombakos 2004-05-13 11:35:47 EDT
Yet on 04-22, you said,

On Thu, 2002-04-11 at 15:12, Zack Weinberg wrote:
> sunrpc/auth_none.c contains static private data, which is initialized
> once per calling thread by authnone_create().  authnone_marshal
> accesses this data by the per-thread data pointer.

I've applied the patch now.  It indeed seems to be consistent with
Solaris does.  Thanks,

http://sources.redhat.com/ml/libc-alpha/2002-04/msg00167.html

I was also bitten by this bug, but applied the patch from RedHat 9,
and the problem is fixed.

Note You need to log in before you can comment on or make changes to this bug.