All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: Phil Sutter <phil@nwl.cc>, netfilter-devel@vger.kernel.org
Subject: Re: nfnetlink: Busy-loop in nfnetlink_rcv_msg()
Date: Mon, 24 Aug 2020 12:47:46 +0200	[thread overview]
Message-ID: <20200824104746.GA22845@salvia> (raw)
In-Reply-To: <20200822184621.GH15804@breakpoint.cc>

Hi Florian,

Sorry, I overlook your reply.

On Sat, Aug 22, 2020 at 08:46:21PM +0200, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > Starting firewalld with two active zones in an lxc container provokes a
> > situation in which nfnetlink_rcv_msg() loops indefinitely, because
> > nc->call_rcu() (nf_tables_getgen() in this case) returns -EAGAIN every
> > time.
> > 
> > I identified netlink_attachskb() as the originator for the above error
> > code. The conditional leading to it looks like this:
> > 
> > | if ((atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf ||
> > |      test_bit(NETLINK_S_CONGESTED, &nlk->state))) {
> > |         [...]
> > |         if (!*timeo) {
> > 
> > *timeo is zero, so this seems to be a non-blocking socket. Both
> > NETLINK_S_CONGESTED bit is set and sk->sk_rmem_alloc exceeds
> > sk->sk_rcvbuf.
> > 
> > From user space side, firewalld seems to simply call sendto() and the
> > call never returns.
> > 
> > How to solve that? I tried to find other code which does the same, but I
> > haven't found one that does any looping. Should nfnetlink_rcv_msg()
> > maybe just return -EAGAIN to the caller if it comes from call_rcu
> > backend?
> 
> Yes, I think thats the most straightforward solution.
> 
> 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.

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.

So either do this or just extend my patch to use nfnetlink_send()
everywhere to remove all existing translations from EAGAIN to ENOBUFS.

  reply	other threads:[~2020-08-24 10:48 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 [this message]
2020-08-24 12:39     ` Florian Westphal
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=20200824104746.GA22845@salvia \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.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.