All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH V2] netfilter: ctnetlink: force null nat binding on insert
Date: Mon, 17 Feb 2014 11:58:56 +0100	[thread overview]
Message-ID: <20140217105856.GA16361@localhost> (raw)
In-Reply-To: <20140217104511.GB31125@breakpoint.cc>

On Mon, Feb 17, 2014 at 11:45:11AM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > >  static int
> > > +nfnetlink_attach_null_binding(struct nf_conn *ct,
> > > +			      enum nf_nat_manip_type manip)
> > > +{
> > > +	int ret = -EAGAIN;
> > > +	bool can_alloc;
> > > +
> > > +	/* This looks bogus, but its important.
> > > +	 *
> > > +	 * We cannot be sure that L3 NAT is available.
> > > +	 *
> > > +	 * If it is not, we will oops in nf_nat_setup_info when we try
> > > +	 * to fetch the l4 nat protocol (which would be on top of the l3 one).
> > > +	 *
> > > +	 * Normally nf_nat_setup_info cannot be called without L3 nat
> > > +	 * available, but this function is invoked from ctnetlink.
> > > +	 */
> > > +	rcu_read_lock();
> > > +
> > > +	can_alloc = !!__nf_nat_l3proto_find(nf_ct_l3num(ct));
> > > +	if (can_alloc)
> > > +		ret = __nf_nat_alloc_null_binding(ct, manip);
> > > +
> > > +	rcu_read_unlock();
> > > +	return ret;
> >
> > I think we should always do the module autoloading for nf-nat and
> > nf-nat-ipvX modules depending on nf_ct_l3num(ct), then return EAGAIN
> > to give another retry. Now, this needs to happen in any case, not only
> > when calling ctnetlink_parse_nat_setup().
>
> Not sure what you mean.  If we enter nf_nat_setup_info without ctnetlink
> involvement the nf-nat protocol should already be there (else, how can
> we end up in nf_nat_setup_info? NAT/MASQUERADE depends on nf-nat).
>
> What use-case did you have in mind? (or, to put it differently, where
> do you think the module probing logic should be)?

If __nf_nat_l3proto_find returns NULL before trying to attach the null
binding, I think you should call the routine to autoload the modules
before returning EAGAIN.

        proto = __nf_nat_l3proto_find(nf_ct_l3num(ct));
        if (proto == NULL) {
                ... release locks
                request_module(...);
                ... acquire locks again
                return -EAGAIN;
        }

  reply	other threads:[~2014-02-17 10:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-16 11:15 [PATCH V2] netfilter: ctnetlink: force null nat binding on insert Florian Westphal
2014-02-17 10:37 ` Pablo Neira Ayuso
2014-02-17 10:45   ` Florian Westphal
2014-02-17 10:58     ` Pablo Neira Ayuso [this message]
2014-02-17 11:15       ` Florian Westphal
2014-02-17 13:24         ` Pablo Neira Ayuso
2014-02-17 13:32           ` Florian Westphal
2014-02-18  1:14             ` 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=20140217105856.GA16361@localhost \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    /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.