Re: Implementing Deletion of Set Elements in Rulesets

[Phil Sutter <phil@nwl.cc>]

On Sat, Mar 23, 2019 at 11:10:24PM +0530, Karuna Grewal wrote:
> Thanks a lot Phil. This was lucid indeed. I still have a few more doubts:
> * what's the purpose of  a context (netlink or eval)?

Contexts provide context. ;)
E.g. nft_ctx holds application information like configured output/error
file descriptors.
In general, these context structures are used to provide data to
functions further down in the call stack without the need for excessive
amounts of function parameters or use of global variables (which should
be avoided for obvious reasons).
If you want to know more about where and how they are used, look up what
fields are contained in each context struct and where they are
instantiated.

> * What is the purpose of the cache being used after the netlink message has
> been already sent to the kernel?

Cache belongs to nft_ctx, which is created by the application. The
application may run multiple commands so keeping the cache after a
commit to kernel is useful. I think it is used from echo callback as
well, although I can't find an example right now.

> * Could you please explain a bit about the kernel interaction once the
> netlink message is sent esp. which structures store the data which was
> carried by the message from userpace. I'm aware of the concept of hooks
> being registered and thereon the processing is handled by the netfilter
> code but I'm not completely clear about how the netlink message gets
> handled internally.

Libnftables objects (struct rule, struct chain, etc.) are converted into
libnftnl objects (struct nftnl_rule, struct nftnl_chain, etc.) within
libnftables. In libnftnl, there are *_build_payload() functions which
serialize libnftnl objects into a netlink message identified by an
instance of struct nlmsghdr.

Netlink messages contain a static header (see struct nlmsghdr) and an
arbitrary amount of attributes of the form [len, type, data]. Libnftnl
uses libmnl to append those attributes to a message. In order to find
out where and how a given netlink message is handled in the kernel, the
quickest way is often to grep for some attribute type definition.

One caveat with nlmsg attributes is that libnftnl and kernel have
distinct ones. E.g. NFTNL_TABLE_NAME in libnftnl corresponds with
NFTA_TABLE_NAME in kernel. See *_build_payload() functions in libnftnl
for details, but in general NFTNL_FOO corresponds with NFTA_FOO in
kernel.

Cheers, Phil