This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Linux: Implement per-thread file system attributes


On 4/10/19 1:03 PM, Florian Weimer wrote:
* Carlos O'Donell:

Any child created with CLONE_FS will have per-thread properties, that's
clear and easy to understand.

However, in the case of !CLONE_FS you will have a set of descendants
which all share the same properties (not those of the process itself).

(a) Is there any desire to want to create a new thread that has the same
     shared properties as that of the process (not that of the parent
     task)?

I doubt we'll ever need it.  We could implement it with a separate
helper thread with a tiny stack, specifically serving such requests (and
which is created the first time per-thread attributes are created).  I
don't think we need to implement it right now.

I agree we do not need to implement this right now, and you're right this
could be done with a helper thread, or a signaling/msg system like setxid
(which I actually like).

(The setxid mechanism could be used as well, but we probably do not want
to pile more functionality onto it.)

(b) Is there any need to identify the parent that created the set of
     descendants that share all the same filesystem properties?

We do not have a unique identifier for the parent thread, so I don't
think that can be implemented today.

Right there is an ABA issue with TID reuse.

With my TID patches and kcmp with KCMP_FS, it will be possible to test
if two running threads share the same file system attributes.

Perfect, and that's already useful because you it solves the use case
I was thinking about which is mostly "Do my changes affect the process?"
If (a) was possible, and I don't think it is given the current linux
interfaces, then when you have "PTHREAD_PER_PROCESS_NP" it would really
do what the name says, and attach the thread's fs-attributes to the
process (not the most recent set of descendant children from a parent
task that set this value).

I think that would be super-confusing because the net effect will be
that pthread_create changes these attributes (in the sense that the new
thread starts out with different values).

The solution we have today is also confusing, in that the semantics of
PTHREAD_PER_PROCESS_NP are changed by the state of the caller.

A library, with an outside view, can't tell, by accessing the
thread attributes via pthread_getattr_np(), if it shares with
the process or not because PTHREAD_PER_PROCESS_NP will bet set.

True, but one of the threads may have called unshare, so you need kernel
support anyway.

That's very different from calling pthread_create() which is a known
API that might not be expected to change the behaviour of future
pthread_create() invocations.

We could also make PTHREAD_PER_THREAD_NP sticky in the sense that *all*
descendent threads have it set automatically, nom atter what the
attribute requests.  This is what we need to implement for user and
group IDs, as discussed before.  We could also add a third flag for the
non-sticky behavior.

Yes, I like this idea. I think PTHREAD_PER_THREAD_NP should be sticky
and setting PTHREAD_PER_PROCESS_NP should result in a error, while
setting some new non-sticky value PTHREAD_PARENT_NP allows you to
inherit your FS from the thread calling pthread_create().

Did we miss anything else?

--
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]