[Xenomai-core] Re: iovec overwriting by CAN stack

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

Sebastian Smolorz wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Jan Kiszka wrote:
>>>> Hi Wolfgang,
>>>>
>>>> it's late, so I may have misread somecode, but don't you "update" the
>>>> iovec descriptors a user passes on send/recvmsg on return (namely
>>>> iovec_len)? I received some complaints about this /wrt to in-kernel CAN
>>>> stack usage.
>>> It's done here:
>>>
>>> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rtcan_
>>> raw.c?v=SVN-trunk#881
>>>
>>> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rtcan_
>>> raw.c?v=SVN-trunk#734
>>>
>>>
>>> I may have missed something. What are the real complaints? Is there a
>>> test program?
>> Not yet (will commit the related patch to our RACK likely later today).
>> It's simply sending frames while re-using the msg+iovec structs in a loop.
>>
>>>> I always considered the same well-know behaviour of RTnet a bug, but now
>>>> I found your code is doing this systematically, also for user space
>>>> callers. Is this behaviour undefined or even required according POSIX or
>>>> whatever?
>>> I don't know, it's Sebastian's Kode.
>> Hmm, hope he will not say that he imitated RTnet...
> 
> Rather an imitation of the Linux kernel's behaviour. The memcpy_toiovec() and 
> memcpy_fromiovec() functions [1] also modify the original iovec. 
> 
> 
> [1] http://lxr.free-electrons.com/source/net/core/iovec.c
> 

But that's the kernel's private (and user-safe) copy. I failed to find
it writing that back to user space.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]