Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > We can of course also intercept -EAGAIN in nf_tables_api.c and translate > > it to -ENOBUFS like in nft_get_set_elem(). > > > > But I think a generic solution it better. The call_rcu backends should > > not result in changes to nf_tables internal state so they do not load > > modules and therefore don't need a restart. > > Handling this from the core would be better, so people don't have to > remember to use the nfnetlink_unicast() that I'm proposing. Your patch looks good to me. > Looking at the tree, call_rcu is not enough to assume this: there are > several nfnetlink subsystems calling netlink_unicast() that translate > EAGAIN to ENOBUFS, from .call and .call_rcu. The way to identify this > would be to decorate callbacks to know what are specifically GET > commands. ? Which .call_rcu is NOT "passive" (does not just peek at things) and, more specifically, which .call_rcu depends on -EAGAIN requiring a tansaction replay?