[okl4-developer] Direct IPC from OKLinux userland processes toOKL4 services

[Geoffrey Lee]

On Sun, Mar 02, 2008 at 08:40:28PM -0500, Jorge Torres wrote:
> Hi Nelson,
> 

Hi

> Please forgive my stubornes, It is clear to me that the best thing is to
> have a driver that proxies IPC messages to OKLINUXuser  applications, but I
> see  oklinux threads direct IPC to others, a useful "out of the box-plug and
> play" feature, as stated before this proposal is  way far from the best, but
> regarding to the problems you mention, I believe can still be fixed,
> 
> 1. For starters, OKLinux user threads will be able to starve the
> OKLinux kernel and other user threads if they make continual calls to
> OKL4 services.
> 
> Yes very true, It is on developer hands to prevent this, but a similar or
> worse risk exists if the linux driver is not well developed.

It is up to the system to prevent such abuse by user threads in 
preemptive multi-tasking environments.  Modules are different because
they run with the same privileges as the Linux kernel anyway, this is
not the case for user applications.

> 
>   2. The OKLinux kernel threads act as user threads' pagers.  If a
> pagefault occurs during the RPC, you'll find that the pager is running
> on a lower priority than the thread it's trying to service.  That's
> technically ok, but could lead to funny and interesting (read: weird
> and undefined) behaviour.
> 
> What if not a higher priority but the same one instead?


This does not work because it can allow the "current" pointer
in Linux to get stale.  e.g. Thread A runs, gets interrupted due
to an OK Linux timer interrupt, OK Linux performs scheduling decision + 
dispatch and hence changes the current pointer.  At this point
the L4 timeslice expiry kicks in, the scheduler schedules Thread A
due to robin-robin scheduling and at this point your current pointer
is stale.


> 
> 
> 3. Who is going to increase the user thread's priority when an RPC
> occurs?  You can't trust the user thread itself to do it, and the L4
> security model forbids it anyway.  The RPC server could do it, but
> that would introduce a race condition during the RPC transfer.
> 
> True, but giving the thread the same priority the kernel has would do fine,
> and will fix starvation risk, doesn't it?

Unfortunately this scheme does not work as pointed out above.

Note that currently the system does not enforce who the OK Linux 
user threads can Ipc() to.  What we are trying to say is you
can in theory use Ipc() inside OK Linux user threads, however, there
are many things that need to be considered if you decide to do this,
and you will likely see things behave in mysterious ways if you are
not very careful about it, nor is doing direct Ipc() within OK Linux
user threads supported, and if you go down this path,
we may not be able to help you if you get into trouble.

> 
> 
> Cheers,
> 
> Jorge

	-gl

> 
> On Fri, Feb 29, 2008 at 12:49 AM, Nelson Tam <nelson at ok-labs.com> wrote:
> 
> > Hi all,
> >
> > On 29/02/2008, at 1:58 PM, Kalamkar, Dhiraj D wrote:
> >
> > > I am not sure whether OKLinux userland process can access Iguana
> > > services directly even after the changes you suggested in OKLinux
> > > scheduler. As far as I understand Iguana server and other services
> > > are based on Iguana Single Address Space (SAS). i.e. Iguana server
> > > and other services work on assumption that they have same virtual to
> > > physical mappings for all the threads in Iguana PD (of course with
> > > different access rights). As OKLinux user processes are external
> > > address spaces (EAS) they can not access iguana services directly.
> > >
> > > Of course, after enabling IPC for userland OKLinux process, you can
> > > do a raw IPC to any L4 thread and may write services which don't
> > > assume Iguana SAS.
> >
> >
> > On 29/02/2008, at 2:12 PM, Jorge Torres wrote:
> >
> > > Yes, one could use L4 native calls, and non SAS based iguana
> > > services, like high resolution timers, or driver servers (I guess),
> >
> >
> > Not all OKL4 services rely on the SAS.  As correctly noted, as long as
> > the service doesn't require any sort of shared memory, EAS threads
> > would be able to utilise them also.
> >
> > Which brings me to an earlier question asked by Jorge: how to control
> > IPC permissions in L4?  The answer is L4_SecurityControl() (for IPC
> > permissions you probably want the wrappers L4_IpcAllow() and cousins).
> >
> > But as I said before, you shouldn't do this in the OKLinux setup due
> > to scheduling reasons.
> > --
> > (nt)
> >
> > Nelson Tam
> > nelson at ok-labs.com
> >
> >
> > _______________________________________________
> > Developer mailing list
> > Developer at okl4.org
> > https://lists.okl4.org/mailman/listinfo/developer
> >

> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer


--