Although it's likely that I'm misunderstanding the intended interface
for vendor command dumpit, I couldn't find any detailed documentation
on it, or examples of drivers implementing it, so I'm sending in this
patch hoping it will at least lead to clarification.
It seems to me that dumpit, like netlink_callback->dump, should signal
successful completion by returning 0.
Currently, that will just cause dumpit to be called again, possibly
many times until an error occurs. Since skb->len is never going to be
0 by the time dumpit is called, the only way for dumpit to signal
completion is by returning an error. If it returns a positive value,
the current message is cancelled, but that positive value is returned
and nl80211_vendor_cmd_dump gets called again.
Signed-off-by: Julian Squires <julian@xxxxxxxxx>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 78442fc4fc01..229d48ccf57f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13156,7 +13156,7 @@ static int nl80211_vendor_cmd_dump(struct sk_buff *skb,
if (err == -ENOBUFS || err == -ENOENT) {
genlmsg_cancel(skb, hdr);
break;
- } else if (err) {
+ } else if (err <= 0) {
genlmsg_cancel(skb, hdr);
goto out;
}
--
2.27.0
