On Thu, Feb 04, 2021 at 03:52:55PM -0500, Chris Hyser wrote: > A second complication was a decision that new processes (not threads) do not > inherit their parents cookie. Thus forking is also not a means to share a > cookie. Basically with a "from-only" interface, the new task would need to > be modified to call prctl() itself. From-only also does not allow for > setting a cookie on an unmodified already running task. This can be fixed by > providing both a "to" and "from" sharing interface that allows helper > programs to construct arbitrary configurations from unmodified programs.
Do we really want to inhibit on fork() or would exec() be a better place? What about those applications that use fork() based workers? > > Also, how do I set a unique cookie on myself with this interface? > > The v10 patch still uses the overloaded v9 mechanism (which as mentioned > above is if two tasks w/o cookies share a cookie they get a new shared > unique cookie). Yes, that is clearly an inconsistency and kludgy. The > mechanism is documented in the docs, but clearly not obvious from the I've not seen a document so far (also, I'm not one to actually read documentation, much preferring comments and Changelogs). > So based on the above, how about we add a "create" to pair with "clear" and > call it "create" vs "set" since we are creating a unique opaque cookie > versus setting a particular value. And as mentioned, because one can't > specify a cookie directly but only thru sharing relationships, we need both > "to" and "from" to make it completely usable. > > So we end up with something like this: > PR_SCHED_CORE_CREATE -- give yourself a unique > cookie > PR_SCHED_CORE_CLEAR -- clear your core sched cookie > PR_SCHED_CORE_SHARE_FROM <src_task> -- get their cookie for you > PR_SCHED_CORE_SHARE_TO <dest_task> -- push your cookie to them I'm still wondering why we need _FROM/_TO. What exactly will we miss with just _SHARE <pid>? current arg_task <none> <none> -EDAFT <none> <cookie> current gets cookie <cookie> <none> arg_task gets cookie <cookie> <cookie> -EDAFTER (I have a suspicion, but I want to see it spelled out). Also, do we wants this interface to be able to work on processes? Things like fcntl(F_SETOWN_EX) allow you to specify a PID type. > An additional question is should the inheritability of a process' cookie be > configurable? The current code gives the child process their own unique > cookie if the parent had a cookie. That is useful in some cases, but many > other configurations could be made much easier with inheritance. What was the argument for not following the traditional fork() semantics and inheriting everything?