nl_recv() and handling truncated messages

[Thomas Haller]

On Wed, 2015-12-09 at 14:24 +0200, Jan Gutter wrote:
> On Wed, Dec 9, 2015 at 12:14 PM, Thomas Haller <thaller at redhat.com>
> wrote:
> > 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.
> 
> Yes, TBD if the performance impact would negatively impact libvirt, I
> don't think
> it's in fastpath, but I am not sure.

Sure, if that would be fine for your application... I meant: it's not
great in general (but might be fine in your case).





> > But this sounds good. How would you do it?
> 
> It appears the only way to do this is with peeking.

Hm yeah. To my understanding, it is not possible with recvmsg() to
obtain the message only if the buffer is large enough.

Without peek, the message gets effectively truncated and lost. With
MSG_PEEK, you have to always call recvmsg() twice.

It would be better to have a opportunistic MSG_PEEK, which reads the
message if possible.


Pretty bad (from recvmsg). Or maybe I am wrong and it is somehow
possible... anybody??




> Sorry to have raised the false alarm, that'll teach me to look at the
> docs in stead of the code!

cool. No problem :) A good idea is to check upstream master branch
first.


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/ad16b5ff/attachment.sig>