Re: l4io_request_iomem() destroyes ioStream

Björn Döbel <[email protected]>
Newsgroups gmane.comp.micro-kernel.l4.devel
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05.01.2015 12:38, ba_f wrote:
> 
> Hello L4-Hackers,
> 
> 
> i noticed some wiered behavior when using l4io_request_iomem().
> 
> Have a look at this simplified code:
> 
>> Server::dispatch(l4_umword_t, L4::Ipc::Iostream &ios){
>> 
>> ios >> v1; ios >> v2;
>> 
>> l4io_request_iomem(ADDR, 4, L4IO_MEM_NONCACHED, &baseaddr);
>> 
>> ios >> v3; ios >> v4;
>> 
>> }
> 
> 
> When using l4io_request_iomem(), it kind of destroys the ioStream
> so that v3 and v4 get wrong values. v1 and v2 are correct and of
> course, i checked that v3 and v4 are correct when
> l4io_request_iomem() is not there.
> 
> 
> It's ok for me, since i just rearrange my code.
> 
> But how does this behavior come? is it a bug, maybe?

This is intentional behavior and caused by the way clients and servers
work.

L4 IPC basically works by the sender putting data into its UTCB and
then invoking a system call. The kernel then copies the data from the
sender's UTCB into the receiver's UTCB and wakes up the receiver if
necessary.

When your server's dispatch() method is called, the arguments for the
call are still within the server's UTCB area. The Iostream's stream
operators allow you to retrieve these arguments and deal with them.

In your code you now do an l4io request, which in turn sends an IPC
message to the IO server. As explained above, for that purpose your
server will now put data into its UTCB and issue an IPC system call.
This overwrites any data that was previously stored in the UTCB and
hence invalidates the Iostream's content.

Possible solutions:
* Move the l4io request to the point where you have read all data
  from the server request, i.e., after the "ios >> v4" line.
* Alternatively, copy the whole UTCB content to an intermediate
  location before issuing another IPC.

Hth,
Bjoern
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlSqfI0ACgkQP5ijxgQLUNm89QCfZYcirTmS5+aAc5NW2N0/W4la
gm0AniqgVqe6lbbzBHKJLWfiKDGf2zBa
=o5Bx
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.