[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220613170849.GG7074@brightrain.aerifal.cx>
Date: Mon, 13 Jun 2022 13:08:49 -0400
From: Rich Felker <dalias@...c.org>
To: Waldek Kozaczuk <jwkozaczuk@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: netlink.c: missing handling of EAGAIN and EWOULDBLOCK
On Mon, Jun 13, 2022 at 11:41:57AM -0400, Waldek Kozaczuk wrote:
> Hi,
>
> Very recently we implemented minimal rnetlink support on OSv side which
> allowed us to finally switch to the netlink-based implementation of
> getifaddrs() and if_nameindex().
>
> However, I noticed that the function __netlink_enumerate() in
> https://github.com/ifduyue/musl/blob/master/src/network/netlink.c uses
> MSG_DONTWAIT flag when calling recv() which may fail with EAGAIN or
> EWOULDBLOCK and there is no error/retry handling for that. I actually saw
> both functions fail occasionally on OSv.
>
> One way to fix is to add missing error handling. But another simpler
> solution is to stop using MSG_DONTWAIT altogether and force recv() to
> block. In other words, the line:
>
> r = recv(fd, u.buf, sizeof(u.buf), MSG_DONTWAIT);
>
> should change to:
>
> r = recv(fd, u.buf, sizeof(u.buf), 0);
>
> For time being we are applying a header trick on OSv side to re-define
> MSG_DONTWAIT as 0 when compiling those specific musl sources.
Thanks! I'll try to track this down. One concern is that I'm not sure
how MSG_DONTWAIT is supposed to interact with "short reads" -- is it
needed (for netlink) to prevent blocking when some data has been read
but there is still buffer space for more?
On a related issue, I'm pretty sure the netlink API doesn't allow for
partial reads with some data remaining buffered on the kernel side,
but we should probably verify that too.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
