From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,
netfilter-devel@vger.kernel.org
Subject: Re: nfnetlink: Busy-loop in nfnetlink_rcv_msg()
Date: Mon, 24 Aug 2020 14:39:35 +0200 [thread overview]
Message-ID: <20200824123935.GJ15804@breakpoint.cc> (raw)
In-Reply-To: <20200824104746.GA22845@salvia>
Pablo Neira Ayuso <pablo@netfilter.org> 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?
next prev parent reply other threads:[~2020-08-24 12:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 23:06 nfnetlink: Busy-loop in nfnetlink_rcv_msg() Phil Sutter
2020-08-22 18:46 ` Florian Westphal
2020-08-24 10:47 ` Pablo Neira Ayuso
2020-08-24 12:39 ` Florian Westphal [this message]
2020-08-24 13:11 ` Phil Sutter
2020-08-26 15:32 ` Pablo Neira Ayuso
2020-08-26 18:54 ` Eric Garver
2020-08-27 14:23 ` Phil Sutter
2020-08-27 17:50 ` Pablo Neira Ayuso
2020-08-23 12:04 ` Pablo Neira Ayuso
-- strict thread matches above, loose matches on Subject: below --
2020-08-23 11:55 [PATCH nf] netfilter: nfnetlink: nfnetlink_unicast() reports EAGAIN instead of ENOBUFS Pablo Neira Ayuso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200824123935.GJ15804@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.