From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2096 invoked from network); 14 Jun 2022 05:19:36 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2022 05:19:36 -0000 Received: (qmail 5835 invoked by uid 550); 14 Jun 2022 05:19:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5800 invoked from network); 14 Jun 2022 05:19:33 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=nOOsQhQA0LTZDleMdKUrqJB1gaGgWyAT2GyHiWP1XDQ=; b=Mn47HQ5eE2XNXPuor+AiJ24c4FoWxq8aTdRjNDdr568ig5UICpKYHtqnLKCv6oYR5w XVfulAE7sRconNOVgV9/b185GOWO+9v55QyyGzqsdmVXAA9AVw25iHVDP3jQbLD032Gr BHcRZTf8hupsHk+u2fNbfFWY6fYdVdhya3c9/0pa/rFHVASbo8hZ6goO0eSRLRNYTI3I SHC0+p5OEzb3rByZ4mjj66/TJ90k8TCjaUeobsL3SZOlzcuqyAzbUDKcmiMsd4JmvNGX m3UWV6+QiXhXFlslog1xAcosgrBhbdeYOEpnrDUZ97inzAANYEr6Aaj1AA1tm3d0lsuH RO1w== X-Gm-Message-State: AJIora8ugq6ZeBDQxtdF/SvoBudgTlYND5Hsk5H0TLIr1KpXRdUrUaYW c0mqtbyP54peiu9V0ddB9V8= X-Google-Smtp-Source: AGRyM1s9DRvV3e3Rl6ZFjWfj5IG43t7W+eJbByjmhUm3PIPHMzmBIm5cyrQMY0qy7aVVHaqQxSrvYw== X-Received: by 2002:a05:6512:48f:b0:479:1f1a:544d with SMTP id v15-20020a056512048f00b004791f1a544dmr1997251lfq.206.1655183961458; Mon, 13 Jun 2022 22:19:21 -0700 (PDT) Date: Tue, 14 Jun 2022 08:19:18 +0300 From: Timo Teras To: Rich Felker Cc: musl@lists.openwall.com, Waldek Kozaczuk Message-ID: <20220614081918.56d88f3d@vostro> In-Reply-To: <20220613170849.GG7074@brightrain.aerifal.cx> References: <20220613170849.GG7074@brightrain.aerifal.cx> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-alpine-linux-musl) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [musl] netlink.c: missing handling of EAGAIN and EWOULDBLOCK On Mon, 13 Jun 2022 13:08:49 -0400 Rich Felker wrote: > On Mon, Jun 13, 2022 at 11:41:57AM -0400, Waldek Kozaczuk wrote: > > 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. In linux the kernel generates the responses during recv() syscall, which guarantees that there is no EAGAIN or EWOULDBLOCK unless the operation has completed and there really is no longer any response data left. IIRC, I added the MSG_DONTWAIT just to be protective against bad implementation to not block indefinitely if NLMSG_DONE/NLMSG_ERROR is not received or parsed properly. This could happen e.g. if the assumption about buffer size no longer is true. But seems 8kB is now documented as upper buffer size universally. > > 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); This should work equally well on Linux if the kernel response is parsed correctly and contains a terminating message. > > 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. The netlink socket is datagram-oriented. The kernel has special measures on how the datagrams are generated. Currently NLM_F_DUMP requests generate maximum size of NLMSG_GOODSIZE (capped to 8kB by code and docs) to make sure no super large buffers are needed. And as mentioned, the current implementation generates additional response datagrams during the syscall if possible. So the socket buffer size does not really effect things here. (The netlink socket buffer size affects only sockets listening for events where the messages are really buffered.) Another way to detect the wrong-sized buffer is to use MSG_TRUNC and make sure the returned value is not larger than buffer size. If that happens, then the buffer size is not enough. But given the current man page, and stability of the Linux implementation. I think we can assume the 8kB buffer size and current code is good. I would not have objection on the suggested change. However, if we do support alternative implementations, it might be good to document the assumptions made. I wonder if the buffer size check is needed in case the alternate implementation used something different? Timo