Re: inbound connection problems when "netlink: test for all flags of the NLM_F_DUMP composite" commit applied

On Tuesday 2011-01-18 19:10, Alessandro Suardi wrote:

On Tue, Jan 18, 2011 at 6:23 PM, Jarek Poplawski [off-list ref] wrote:

quoted

NLM_F_DUMP flags should be applied to GET requests only, eg. rtnetlink
tests message type to verify this. Since genetlink can't do the same
use "practical" test for ops->dumpit (assuming NEW request won't be
mixed with GET).

-       if (nlh->nlmsg_flags & NLM_F_DUMP) {
-               if (ops->dumpit == NULL)
+       if (ops->dumpit) {
+               if (nlh->nlmsg_flags & NLM_F_DUMP) {
+                       genl_unlock();
+                       err = netlink_dump_start(net->genl_sock, skb, nlh,
+                                                ops->dumpit, ops->done);
+                       genl_lock();
+                       return err;
+               } else {
                       return -EOPNOTSUPP;
-
-               genl_unlock();
-               err = netlink_dump_start(net->genl_sock, skb, nlh,
-                                        ops->dumpit, ops->done);
-               genl_lock();
-               return err;
+               }

2.6.37-git18 + netlink revert + this patch
- fixes Avahi
- breaks acpid
Starting acpi daemon: RTNETLINK1 answers: Operation not supported
acpid: error talking to the kernel via netlink

Deducing from that, it is a GET-like request that was sent by acpid, 
and the message type is one that has both a dumpit and a doit function.
So if EOPNOTSUPP now occurs on all message types that have both dumpit 
and doit, you should have broken a lot more than just acpid.