nl_recv() and handling truncated messages

[Thomas Haller]

Hi Jan,


On Tue, 2015-12-08 at 17:37 +0200, Jan Gutter wrote:



> nl_recv() works as expected if MSG_PEEK has been set, though, so it's
> possible to fix in libvirt by either making the buffer bigger, or
> enabling peeking.

using MSG_PEEK requires two syscall to get the data, even if no
truncation happens. Which is why you want to avoid that and why it's
opt-in.




> However, it would be nice if the error is passed up to the user of
> libnl3.
> 
> There's a couple of options open:
> 1) Return NLE_MSG_TRUNC when a truncated message is received.

I don't really understand the problem yet. Are you testing master?

How does this relate to the two recent fixes:
https://github.com/thom311
/libnl/commit/fd9d1da28c9d989f88b6c5edaa352c0https://github.com/thom311
/libnl/commit/bbdcaea9a779885fedc04817dcc1195


> 2) Enable MSG_TRUNC for all recvmsg calls and resize the buffer as
> needed (meaning that NLE_MSG_TRUNC won't happen, but receive buffer
> sizes can grow until realloc fails or a limit is hit...).

With MSG_TRUNC, how can you resize the buffer and recover from the
error? Isn't the message you failed to read (partly) lost?

But this sounds good. How would you do it?


> 3) Make 2) optional (similar to enabling peeking) and return
> NLE_MSG_TRUNC if it's not enabled.

Not sure. Are there any downsides of using (2) that would require to
make it optional?



> I'm really not sure how much software is currently in the wild and
> relies on this silent failure.


ciao,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20151209/7fb1aa2b/attachment.sig>