Questions about __thread for NSS modules

Questions about __thread for NSS modules

[Thorsten Kukuk]

Hi,

currently there is still on problem left with NIS and threads:

If for exmaple two concurrent threads calls getpwent_r() and NIS
is used, than both threads will not see all NIS passwd entries.

The reason is, that I need some static data to loop through the
NIS map. I use locks while the process is inside of this functions,
but I cannot hold a lock over different function calls.

So, if the following happens:

thread1 -> getpwent_r()
thread2 -> getpwent_r()
thread1 -> getpwent_r()
thread2 -> getpwent_r()

thread1 will never see the users thread2 gets, and thread2 will
never see the users thread1 will get. The reason is, that you always
needs to send the last entry you got back to get a new one, but
thread2 will use the last entry thread1 got.

One idea I had is to use thread local variables instead with NPTL.

My question is: is this possible at all in NSS modules like libnss_nis.so?
Do I need to link against libpthread? My first try ends in a 
unresolved "__tls_get_addr" symbol when I try to link the module.

  Thorsten
-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Maxfeldstr. 5                 D-90409 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: Questions about __thread for NSS modules

[Roland McGrath]

> My question is: is this possible at all in NSS modules like libnss_nis.so?

Sure.  

> Do I need to link against libpthread? 

No.

> My first try ends in a unresolved "__tls_get_addr" symbol when I try to
> link the module.

I'll assume that's actually ___tls_get_addr if you're on x86.
This suggests your dynamic linker is not built with TLS support.
It defines that symbol.  

Re: Questions about __thread for NSS modules

[Thorsten Kukuk]

On Thu, Aug 26, Roland McGrath wrote:

> > My question is: is this possible at all in NSS modules like libnss_nis.so?
> 
> Sure.  
> 
> > Do I need to link against libpthread? 
> 
> No.
> 
> > My first try ends in a unresolved "__tls_get_addr" symbol when I try to
> > link the module.
> 
> I'll assume that's actually ___tls_get_addr if you're on x86.
> This suggests your dynamic linker is not built with TLS support.
> It defines that symbol.  

I know and it is there:

firun:/usr/src/packages/BUILD/glibc-2.3/cc-nptl# nm elf/ld.so |grep __tls_get_addr
0000f010 T ___tls_get_addr
0000f770 T __tls_get_addr
0000f010 t ___tls_get_addr_internal


But when linking the NSS modules, I get the following error:

gcc   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux.so.2  -B/usr/src/packages/BUILD/glibc-2.3/cc-nptl/csu/  -Wl,--version-script=/usr/src/packages/BUILD/glibc-2.3/cc-nptl/libnss
_nis.map -Wl,-soname=libnss_nis.so.2 -Wl,-z,combreloc -Wl,-z,relro  -L/usr/src/packages/BUILD/glibc-2.3/cc-nptl -L/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math -L/usr/src/packages/BUILD/glibc-2.3/cc-nptl/elf 
-L/usr/src/packages/BUILD/glibc-2.3/cc-nptl/dlfcn -L/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nss -L/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nis -L/usr/src/packages/BUILD/glibc-2.3/cc-nptl/rt -L/usr/src/packa
ges/BUILD/glibc-2.3/cc-nptl/resolv -L/usr/src/packages/BUILD/glibc-2.3/cc-nptl/crypt -L/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nptl -Wl,-rpath-link=/usr/src/packages/BUILD/glibc-2.3/cc-nptl:/usr/src/packages
/BUILD/glibc-2.3/cc-nptl/math:/usr/src/packages/BUILD/glibc-2.3/cc-nptl/elf:/usr/src/packages/BUILD/glibc-2.3/cc-nptl/dlfcn:/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nss:/usr/src/packages/BUILD/glibc-2.3/cc-np
tl/nis:/usr/src/packages/BUILD/glibc-2.3/cc-nptl/rt:/usr/src/packages/BUILD/glibc-2.3/cc-nptl/resolv:/usr/src/packages/BUILD/glibc-2.3/cc-nptl/crypt:/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nptl -o /usr/src/p
ackages/BUILD/glibc-2.3/cc-nptl/nis/libnss_nis.so -T /usr/src/packages/BUILD/glibc-2.3/cc-nptl/shlib.lds /usr/src/packages/BUILD/glibc-2.3/cc-nptl/csu/abi-note.o /usr/src/packages/BUILD/glibc-2.3/cc-nptl/csu/s
use-note.o -Wl,--whole-archive /usr/src/packages/BUILD/glibc-2.3/cc-nptl/nis/libnss_nis_pic.a -Wl,--no-whole-archive /usr/src/packages/BUILD/glibc-2.3/cc-nptl/elf/interp.os /usr/src/packages/BUILD/glibc-2.3/cc
-nptl/nis/libnsl.so.1 /usr/src/packages/BUILD/glibc-2.3/cc-nptl/nss/libnss_files.so /usr/src/packages/BUILD/glibc-2.3/cc-nptl/libc.so /usr/src/packages/BUILD/glibc-2.3/cc-nptl/libc_nonshared.a 
/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nis/libnss_nis_pic.a(nis-proto.os)(.text+0x1a): In function `internal_nis_endprotoent':
nss_nis/nis-proto.c:76: undefined reference to `___tls_get_addr'
/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nis/libnss_nis_pic.a(nis-proto.os)(.text+0x93): In function `_nss_nis_endprotoent':
nss_nis/nis-proto.c:123: undefined reference to `___tls_get_addr'
/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nis/libnss_nis_pic.a(nis-proto.os)(.text+0x417): In function `internal_nis_setprotoent':
nss_nis/nis-proto.c:98: undefined reference to `___tls_get_addr'
/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nis/libnss_nis_pic.a(nis-proto.os)(.text+0x470): In function `_nss_nis_getprotoent_r':
nss_nis/nis-proto.c:137: undefined reference to `___tls_get_addr'
/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nis/libnss_nis_pic.a(nis-proto.os)(.text+0x63e): In function `saveit':
nss_nis/nis-proto.c:60: undefined reference to `___tls_get_addr'
/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nis/libnss_nis_pic.a(nis-proto.os)(.text+0x65c):nss_nis/nis-proto.c:64: more undefined references to `___tls_get_addr' follow
collect2: ld returned 1 exit status
make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/nis/libnss_nis.so] Error 1


-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Maxfeldstr. 5                 D-90409 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: Questions about __thread for NSS modules

[Roland McGrath]

Perhaps it is linking against the wrong ld.so somehow?
The -rpath-link parameter needs to include the build/elf directory.

Re: Questions about __thread for NSS modules

[Thorsten Kukuk]

On Thu, Aug 26, Roland McGrath wrote:

> > My question is: is this possible at all in NSS modules like libnss_nis.so?
> 
> Sure.  

Ok, I managed now to build a libnss_nis.so.2 module, which uses
thread local storage instead of static variables and locking.

Now my next problem: SuSE and RH have the libc/libpthread with TLS
and NPTL support in /lib/tls and a version without in /lib. But the
path to the libnss_* modules is hardcoded to /lib/libnss_*. So I cannot
copy the libnss_nis module with TLS support into /lib/tls/.

Any ideas how to solve this?

 Thanks,
    Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Maxfeldstr. 5                 D-90409 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: Questions about __thread for NSS modules

[Roland McGrath]

> But the path to the libnss_* modules is hardcoded to /lib/libnss_*. 

Where do you get that idea?

Re: Questions about __thread for NSS modules

[Thorsten Kukuk]

On Wed, Sep 08, Roland McGrath wrote:

> > But the path to the libnss_* modules is hardcoded to /lib/libnss_*. 
> 
> Where do you get that idea?

Forgot to run ldconfig :(

Sorry for the noise, now it really works ;)

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Maxfeldstr. 5                 D-90409 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B