[PATCH bpf-next] tools/bpf: fix a netlink recv issue

[PATCH bpf-next] tools/bpf: fix a netlink recv issue

[Yonghong Song]

Commit f7010770fbac ("tools/bpf: move bpf/lib netlink related
functions into a new file") introduced a while loop for the
netlink recv path. This while loop is needed since the
buffer in recv syscall may not be enough to hold all the
information and in such cases multiple recv calls are needed.

There is a bug introduced by the above commit as
the while loop may block on recv syscall if there is no
more messages are expected. The netlink message header
flag NLM_F_MULTI is used to indicate that more messages
are expected and this patch fixed the bug by doing
further recv syscall only if multipart message is expected.

The patch added another fix regarding to message length of 0.
When netlink recv returns message length of 0, there will be
no more messages for returning data so the while loop
can end.

Fixes: f7010770fbac ("tools/bpf: move bpf/lib netlink related functions into a new file")
Reported-by: Björn Töpel <bjorn.topel@intel.com>
Tested-by: Björn Töpel <bjorn.topel@intel.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
---
 tools/lib/bpf/netlink.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/netlink.c b/tools/lib/bpf/netlink.c
index 469e068dd0c5..fde1d7bf8199 100644
--- a/tools/lib/bpf/netlink.c
+++ b/tools/lib/bpf/netlink.c
@@ -65,18 +65,23 @@ static int bpf_netlink_recv(int sock, __u32 nl_pid, int seq,
 			    __dump_nlmsg_t _fn, dump_nlmsg_t fn,
 			    void *cookie)
 {
+	bool multipart = true;
 	struct nlmsgerr *err;
 	struct nlmsghdr *nh;
 	char buf[4096];
 	int len, ret;
 
-	while (1) {
+	while (multipart) {
+		multipart = false;
 		len = recv(sock, buf, sizeof(buf), 0);
 		if (len < 0) {
 			ret = -errno;
 			goto done;
 		}
 
+		if (len == 0)
+			break;
+
 		for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len);
 		     nh = NLMSG_NEXT(nh, len)) {
 			if (nh->nlmsg_pid != nl_pid) {
@@ -87,6 +92,8 @@ static int bpf_netlink_recv(int sock, __u32 nl_pid, int seq,
 				ret = -LIBBPF_ERRNO__INVSEQ;
 				goto done;
 			}
+			if (nh->nlmsg_flags & NLM_F_MULTI)
+				multipart = true;
 			switch (nh->nlmsg_type) {
 			case NLMSG_ERROR:
 				err = (struct nlmsgerr *)NLMSG_DATA(nh);
-- 
2.17.1

Re: [PATCH bpf-next] tools/bpf: fix a netlink recv issue

[Alexei Starovoitov]

On Tue, Sep 11, 2018 at 02:09:11PM -0700, Yonghong Song wrote:
> Commit f7010770fbac ("tools/bpf: move bpf/lib netlink related
> functions into a new file") introduced a while loop for the
> netlink recv path. This while loop is needed since the
> buffer in recv syscall may not be enough to hold all the
> information and in such cases multiple recv calls are needed.
> 
> There is a bug introduced by the above commit as
> the while loop may block on recv syscall if there is no
> more messages are expected. The netlink message header
> flag NLM_F_MULTI is used to indicate that more messages
> are expected and this patch fixed the bug by doing
> further recv syscall only if multipart message is expected.
> 
> The patch added another fix regarding to message length of 0.
> When netlink recv returns message length of 0, there will be
> no more messages for returning data so the while loop
> can end.
> 
> Fixes: f7010770fbac ("tools/bpf: move bpf/lib netlink related functions into a new file")
> Reported-by: Björn Töpel <bjorn.topel@intel.com>
> Tested-by: Björn Töpel <bjorn.topel@intel.com>
> Signed-off-by: Yonghong Song <yhs@fb.com>

Applied, Thanks