From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <54E7917F.101@xenomai.org> Date: Fri, 20 Feb 2015 20:56:47 +0100 From: Philippe Gerum MIME-Version: 1.0 References: <54E765A4.20909@xenomai.org> <54E76A59.4060000@siemens.com> In-Reply-To: <54E76A59.4060000@siemens.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] [Xenomai-git] Jan Kiszka : cobalt/posix/syscall: Exclude sc_cobalt_get_current from debug warnings List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka , xenomai@xenomai.org, xenomai-git@xenomai.org On 02/20/2015 06:09 PM, Jan Kiszka wrote: > On 2015-02-20 17:49, Philippe Gerum wrote: >> On 02/20/2015 04:53 PM, git repository hosting wrote: >>> Module: xenomai-jki >>> Branch: for-forge >>> Commit: fc2d70475f4f86da30e68a569e7641982f4dd8e1 >>> URL: http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=fc2d70475f4f86da30e68a569e7641982f4dd8e1 >>> >>> Author: Jan Kiszka >>> Date: Fri Feb 20 16:50:15 2015 +0100 >>> >>> cobalt/posix/syscall: Exclude sc_cobalt_get_current from debug warnings >>> >>> This syscall is used for probing the context, thus may be triggered by >>> non-RT threads as well which we should not report as potential error. >>> >>> Signed-off-by: Jan Kiszka >>> >> >> This would mean that sc_cobalt_get_current is considered valid from any >> process, including those which did not issue sc_cobalt_bind in the first >> place. >> >> Do we depend on this today, or are we granting an extended access with >> this patch? > > This is just to silence a warning you get, e.g., with the smokey fork test. > > I don't think it should be illegal to call such a service, even prior to > binding to the interface. It is already robust against it, isn't it? > Illegal maybe not, but definitely unexpected. I mean that this is a Cobalt service, so I would expect the userland code not to issue any Cobalt syscall until the initial binding took place. The fork sequence seems to depart from this assumption due to some code running on behalf of the atfork handlers in libcobalt, right? -- Philippe.