netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next 1/3] netfilter: nf_tables: add generation mask to table objects
Date: Tue, 4 Aug 2015 12:26:35 +0200	[thread overview]
Message-ID: <20150804102635.GC6033@acer.localdomain> (raw)
In-Reply-To: <20150804092905.GA7944@salvia>

On 04.08, Pablo Neira Ayuso wrote:
> On Tue, Aug 04, 2015 at 11:09:17AM +0200, Patrick McHardy wrote:
> > On 04.08, Pablo Neira Ayuso wrote:
> > > The dumping of table objects can be inconsistent when interfering with the
> > > preparation phase of our 2-phase commit protocol because:
> > > 
> > > 1) We remove objects from the lists during the preparation phase, that can be
> > >    added re-added from the abort step. Thus, we may miss objects that are still
> > >    active.
> > > 
> > > 2) We add new objects to the lists during the preparation phase, so we may get
> > >    objects that are not yet active with an internal flag set.
> > > 
> > > We can resolve this problem with generation masks, as we already do for rules
> > > when we expose them to the packet path.
> > > 
> > > After this change, we always obtain a consistent list as long as we stay in the
> > > same generation. The userspace side can detect interferences through the
> > > generation counter. If so, it needs to restart.
> > > 
> > > As a result, we can get rid of the internal NFT_TABLE_INACTIVE flag.
> > 
> > I have a similar patch queued up, however there seems to be something missing
> > in this patch. The lookup functions need to take the genmask into account.
> 
> They already do for the deletion case, so we hit -ENOENT for objects
> that has been deleted in this batch, so we cannot delete objects
> twice.

> @@ -829,10 +860,10 @@ static int nf_tables_deltable(struct sock *nlsk, struct sk_buff *skb,
>       if (IS_ERR(afi))
>               return PTR_ERR(afi);

> -	table = nf_tables_table_lookup(afi, nla[NFTA_TABLE_NAME]);
> +	table = nf_tables_table_lookup(net, afi, nla[NFTA_TABLE_NAME], true);
>       if (IS_ERR(table))
>               return PTR_ERR(table);
> -	if (table->flags & NFT_TABLE_INACTIVE)
> +	if (!nft_table_is_active(net, table))
                return -ENOENT;

Looking at it, that part seems wrong. They need to be active in the *next*
generation, not the current one, to be deleted. All netlink actions only
affect the next generation.

The same bug is present in multiple locations.

> > Otherwise you can not delete and add a new table in the same batch. The same
> > holds for all other object types.
> 
> I can with this patch, we always operate with the *next* bit to
> indicate that the object will be inactive in the future.
> 
> > > +static struct nft_table *nf_tables_table_lookup(struct net *net,
> > > +						const struct nft_af_info *afi,
> > > +						const struct nlattr *nla,
> > > +						bool trans)
> > >  {
> > >  	struct nft_table *table;
> > >  
> > > @@ -382,10 +411,10 @@ static struct nft_table *nf_tables_table_lookup(const struct nft_af_info *afi,
> > >  		return ERR_PTR(-EINVAL);
> > >  
> > >  	table = nft_table_lookup(afi, nla);
> > > -	if (table != NULL)
> > > -		return table;
> > > +	if (table == NULL || (trans && !nft_table_is_active_next(net, table)))
> > > +		return ERR_PTR(-ENOENT);
> > 
> > We really need to check the genid itself, in some cases we *only* want
> > currently active tables, f.i. gettable and dumps.
> 
> This is what this patch is doing from the dump path.
> 
> We shouldn't check if the object is active from the lookup function if
> we're in the middle of a transaction, since we hold the lock there is
> no way we can see inactive objects in the list. There's only one
> transaction at the same time.

That's not entirely correct. Dump continuations happen asynchronously to
netlink modifications and commit operations, so the genid may bump in the
middle. We can get an inconsistent view if we have:

			dump set elements from set x table y
delete table y
create table y
create set x
begin commit
			continue dump from new set
commit, send NEWGEN

Sure, we will get a NEWGEN message, but at that time we might already have
sent a full message for the new table/set since that message is only send
after the commit is completed.

  reply	other threads:[~2015-08-04 10:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-04  9:05 [PATCH nf-next 1/3] netfilter: nf_tables: add generation mask to table objects Pablo Neira Ayuso
2015-08-04  9:05 ` [PATCH nf-next 2/3] netfilter: nf_tables: add generation mask to chain objects Pablo Neira Ayuso
2015-08-04  9:05 ` [PATCH nf-next 3/3] netfilter: nf_tables: add generation mask to set objects Pablo Neira Ayuso
2015-08-04  9:12   ` Patrick McHardy
2015-08-04  9:29     ` Pablo Neira Ayuso
2015-08-04 10:38   ` Patrick McHardy
2015-08-04 17:23     ` Pablo Neira Ayuso
2015-08-04  9:09 ` [PATCH nf-next 1/3] netfilter: nf_tables: add generation mask to table objects Patrick McHardy
2015-08-04  9:29   ` Pablo Neira Ayuso
2015-08-04 10:26     ` Patrick McHardy [this message]
2015-08-04 17:04       ` Pablo Neira Ayuso
2015-08-05  9:09         ` Patrick McHardy
2015-08-06 10:20           ` Pablo Neira Ayuso
2015-08-08 15:53             ` Patrick McHardy
2015-08-10  7:56             ` Patrick McHardy
2015-08-10 18:37               ` Pablo Neira Ayuso
2015-08-04 18:21   ` Pablo Neira Ayuso
2015-08-05  8:41     ` Patrick McHardy
2015-08-06 10:21       ` 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=20150804102635.GC6033@acer.localdomain \
    --to=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).