On 04/01/11 03:14, Jan Engelhardt wrote: > Hey there, > > > I can't really say whether it's genetlink or netlink to blame, > but I noticed that a request with > > nlmsg_flags = NLM_F_CREATE | NLM_F_EXCL > > to a genl-registered component can return -EOPNOTSUPP because it does > not have a dumpit function defined in struct genl_ops. Make sense? > Not at first sight at least. > include/linux/netlink.h has this nice anecdote: > > /* Modifiers to GET request */ > #define NLM_F_ROOT 0x100 > #define NLM_F_MATCH 0x200 > #define NLM_F_ATOMIC 0x400 > #define NLM_F_DUMP (NLM_F_ROOT|NLM_F_MATCH) > > /* Modifiers to NEW request */ > #define NLM_F_REPLACE 0x100 > #define NLM_F_EXCL 0x200 > #define NLM_F_CREATE 0x400 > #define NLM_F_APPEND 0x800 > > Except there is nothing that declares a particular Netlink message > as "GET" or "NEW". Subsequently, genetlink chokes: > > if (nlh->nlmsg_flags & NLM_F_DUMP) > if (ops->dumpit == NULL) > return -EOPNOTSUPP; > > Because NLM_F_CREATE | NLM_F_EXCL == NLM_F_DUMP. > That, of course, is absolutely bogus. Hm, NLM_F_CREATE | NLM_F_EXCL is not equal to NLM_F_DUMP. You must be hitting -EOPNOTSUPP elsewhere. > [N.B.: I am also wondering whether > (nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP > may have been desired, because NLM_F_DUMP is composed of two bits.] Someone may include NLM_F_ATOMIC to a dump operation, in that case the checking that you propose is not valid. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
