[Bug libc/23978] New: dlmopen(): increasing the number of name spaces

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug libc/23978] New: dlmopen(): increasing the number of name spaces

fche at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23978

            Bug ID: 23978
           Summary: dlmopen(): increasing the number of name spaces
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: ahori at riken dot jp
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Is there any chance to increase the number of name spaces created by calling
dlmopen()?

I am working on new parallel execution model (named Process-in-Process (PiP),
detailes: https://dl.acm.org/citation.cfm?id=3208045) and I want to create name
spaces much more than 16 which is the current upper limit.

I already have a patch to do this. It is very simple. Just increase the number
of DL_NNS found in sysdeps/generic/ldsodefs.h.  I would like to have around 300
which is mlarger than the number of cores available on Xeon Phi (KNL).

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug libc/23978] dlmopen(): increasing the number of name spaces

fche at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23978

Atsushi Hori <ahori at riken dot jp> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahori at riken dot jp

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug libc/23978] dlmopen(): increasing the number of name spaces

fche at redhat dot com
In reply to this post by fche at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23978

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug libc/23978] dlmopen(): increasing the number of name spaces

fche at redhat dot com
In reply to this post by fche at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23978

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
I'm not sure that it's a good idea to retrofit such execution models onto an
existing dynamic loader.

libc.so needs around 144 bytes of TLS space.  Supporting 300 name spaces would
need a static TLS reserve of at least 43 KiB, and this reserve could not be
used for anything else.  For such large numbers of name spaces, we would have
to find a way to deal with initial-exec TLS memory used by the implementation
itself.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug libc/23978] dlmopen(): increasing the number of name spaces

fche at redhat dot com
In reply to this post by fche at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23978

--- Comment #2 from Atsushi Hori <ahori at riken dot jp> ---
It's been a long time since I posted and I almost forget about this issue. At
last I got a comment, this is great!

I understand your concern.  Although I have only little knowledge about glibc
including ld.so, I wonder if it is possible to dynamically allocate the 'TLS'
regions.

I also found that the recent audit implementation using a uint32_t as the audit
flags for name spaces is not a good idea.

Anyhow, I am very happy to have this feedback.

P.S.
If some of you might be interested in the PiP model, you can try it by
downloading from;
https://github.com/RIKEN-SysSoft/PiP

I also uploaded some presentation slides which are much easier to read than
reading the HPDC paper.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug libc/23978] dlmopen(): increasing the number of name spaces

fche at redhat dot com
In reply to this post by fche at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23978

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Atsushi Hori from comment #2)
> It's been a long time since I posted and I almost forget about this issue.
> At last I got a comment, this is great!
>
> I understand your concern.  Although I have only little knowledge about
> glibc including ld.so, I wonder if it is possible to dynamically allocate
> the 'TLS' regions.

No, because the implementation is free to store pointers to TLS variables, so
the allocation cannot be moved (and we might have to move it if its size
changes).

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug libc/23978] dlmopen(): increasing the number of name spaces

fche at redhat dot com
In reply to this post by fche at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23978

--- Comment #4 from Atsushi Hori <ahori at riken dot jp> ---
Thank you, Florian,

I think I know what TLS is, but what I wanted yo to do is expanding the size of
name space table, or dynamically allocating name space entriesI  believe this
is independent from TLS variables. Just correct me, if I am wrong.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug libc/23978] dlmopen(): increasing the number of name spaces

fche at redhat dot com
In reply to this post by fche at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23978

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
These two are related.  Each namespace must load libc.so, and libc.so contains
some TLS variables.  The number of usable namespaces is therefore limited by
the size of the static TLS reserve divided by the amount of initial-exec TLS
memory that libc.so uses.

--
You are receiving this mail because:
You are on the CC list for the bug.