On Sat, Mar 22, 2014 at 7:56 PM, Djalal Harouni <[email protected]> wrote: > On Sat, Mar 22, 2014 at 07:37:38PM +0100, Kay Sievers wrote: >> On Sat, Mar 22, 2014 at 3:43 PM, Daniel Mack <[email protected]> wrote: >> >> Also it seems that now there is only support for one level of nested >> >> domains? will this be increased? >> > >> > I don't think so. What's your use case here? >> >> We never tried, but the code was supposed to allow stacking of them. >> I'll fix it. > Yes I was thinking of applications that create domains, they wont work > if they are inside a container domain!
Domain creation at the moment is limited to privileged processes, because we have no limits for accounting or other safeguards in place. Domains are a conceptually bit closer to an OS container, applications should see a custom endpoint or can create their own private buses in the domain they run in. >> >> 2) What about creating custom endpoints on the bus that was already >> >> unrefed ? IMHO this is the same scenario! >> > >> > That shouldn't happen of course. We've been dealing with locking in that >> > area quite a bit, but we might have overlooked something. Please send a >> > patch if you see such an unsafe locking scenario. >> > >> >> Hmm perhaps this can be improved by taking a ref ASAP and revalidate >> >> objects by checking the "*->disconnected" ? >> > >> > ->disconnected isn't so much of an issue, and we do check for it where >> > necessary. Apart from that, users that store a pointer to any object >> > should take a reference, so it can't disappear underneath them. But >> > again, if you think we've overlooked anything, let us know. Reviewing >> > all these details is certainly much appreciated. >> >> I'll add a few more "disconnected checks" before we link into the >> parent objects. > Yes, I've located some sites, and I'm trying to do more tests... > > I'll get back to you, Thanks Daniel, Kay! I've committed a few more guards which check for disconnected, right before we try to link into the parent object. Thanks, Kay _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
