| Message ID | 20200720145033.401307-1-julian@cipht.net (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | cfg80211: allow vendor dumpit to terminate by returning 0 | expand |
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; }
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@cipht.net> --- net/wireless/nl80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)