Warning from ORe stub driver

[Alexander Valitov]

Hi,

> > > When I use L4Linux ORe stub driver it constantly prints these
> warnings:
> > >
> > > l4lx    | eth0: buffer too small (1)
> > > l4lx    | eth0: buffer too small (1)
> > > l4lx    | eth0: buffer too small (1)
> >
> > the internal receive buffer used by the stub to receive network packets
> > is too small to suit the packet that ORe is trying to deliver.
> >
> > In drivers/net/l4ore.c:146 can you print the value of the variable size
> > before and after the call to l4ore_recv_blocking()?
>
> Situation is really strange here:
> Buffer size is 1514, after call it is equal to e.g. 60.
> But l4ore_recv_blocking() return value is always 1.
> Return value should be the required buffer size or 
> negative error code or zero.
>
> I checked return value on ORe side. It is zero.
>
> Then I looked deeper into function ore_rxtx_recv_reply() 
> generated by DICE.
> It is called on server side if answer was delayed 
> (l4ore_recv_blocking() - is async).
> The function contains following code:
> 
> _dice_msg_buffer.rxtx_recv_out._dice_return = _dice_return;
>
> _dice_return is equal to zero here but for some unknown reason
> _dice_msg_buffer.rxtx_recv_out._dice_return field never
> transmitted to ore_rxtx_recv_call() function. So in 
> ore_rxtx_recv_call() function:
>
> _dice_msg_buffer.rxtx_recv_out._dice_return := 1 

I found the source of problem. It is GCC bug.
The bug is DSE (dead storage elimination) related.
The issue is valid for GCC 4.3.x, 4.4.x, 4.5.x.
In 4.2.x and earlier problem does not exist.

Workaround for problem on GCC 4.3.x, 4.4.x, 4.5.x is to add
"-fno-dse" options. E.g. you can change in ./l4/mk/binary.inc
following line:
OPTS    ?= -g -O2 -fno-strict-aliasing
into this one:
OPTS    ?= -g -O2 -fno-strict-aliasing -fno-dse

Bug is reported to GCC developers. They said that it is known issue
and they believe that it's connected with this problem:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
where DSE algorithm wrongly eliminate used storage.

Here is more detailed description of issue with ORe:

The issue lies in ore_rxtx-server.c file in function ore_rxtx_recv_reply().
Here GCC thinks (and "$objdump -S ore" shows it) that
_dice_send_dope field of _dice_msg_buffer.rxtx_recv_out structure
is not used by l4_ipc_send_tag() syscall so GCC partially removes some
operations on _dice_send_dope.

As a result _dice_send_dope is equal to 0x0100 (not 0x6100), thus only
one strdope and zero dword are transfered. That is why on client side
dwords are non-initialized values from stack. Particularly, in my case,
_dice_return was just accidentally equal to 1, as another function
always put '1' to this position.

If I change this line:
_dice_msg_buffer.rxtx_recv_out._dice_send_dope = L4_IPC_DOPE(
sizeof(_dice_msg_buffer.rxtx_recv_out)/sizeof(long)-7, 1);

into this one (it is actually equal to above one):
_dice_msg_buffer.rxtx_recv_out._dice_send_dope = 0x6100;

then GCC removes all operations under _dice_send_dope. And 
_dice_send_dope becomes equal to 0x0.

Best Regards,
  Alexander Valitov
-- 
View this message in context: http://www.nabble.com/Warning-from-ORe-stub-driver-tp22827840p23194631.html
Sent from the L4 mailing list archive at Nabble.com.