All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Jeremy Sowden <jeremy@azazel.net>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next] netfilter: ctnetlink: don't dump ct extensions of unconfirmed conntracks
Date: Tue, 15 Oct 2019 23:22:04 +0200	[thread overview]
Message-ID: <20191015212204.GR25052@breakpoint.cc> (raw)
In-Reply-To: <20191015210647.GA16877@azazel.net>

Jeremy Sowden <jeremy@azazel.net> wrote:
> On 2019-10-14, at 21:41:41 +0200, Florian Westphal wrote:
> > When dumping the unconfirmed lists, the cpu that is processing the ct
> > entry can realloc ct->ext at any time.
> >
> > Accessing extensions from another CPU is ok provided rcu read lock is
> > held.
> >
> > Once extension space will be reallocated with plain krealloc this
> > isn't used anymore.
> >
> > Dumping the extension area for confirmed or dying conntracks is fine:
> > no reallocations are allowed and list iteration holds appropriate
> > locks that prevent ct (and thus ct->ext) from getting free'd.
> >
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
> >  net/netfilter/nf_conntrack_netlink.c | 77 ++++++++++++++++++----------
> >  1 file changed, 51 insertions(+), 26 deletions(-)
> >
> > diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
> > index e2d13cd18875..db04e1bfb04d 100644
> > --- a/net/netfilter/nf_conntrack_netlink.c
> > +++ b/net/netfilter/nf_conntrack_netlink.c
> > @@ -506,9 +506,44 @@ static int ctnetlink_dump_use(struct sk_buff *skb, const struct nf_conn *ct)
> >  	return -1;
> >  }
> >
> > +/* all these functions access ct->ext. Caller must either hold a reference
> > + * on ct or prevent its deletion by holding either the bucket spinlock or
> > + * pcpu dying list lock.
> > + */
> > +static int ctnetlink_dump_extinfo(struct sk_buff *skb,
> > +				  const struct nf_conn *ct, u32 type)
> > +{
> > +	if (ctnetlink_dump_acct(skb, ct, type) < 0 ||
> > +	    ctnetlink_dump_timestamp(skb, ct) < 0 ||
> > +	    ctnetlink_dump_helpinfo(skb, ct) < 0 ||
> > +	    ctnetlink_dump_labels(skb, ct) < 0 ||
> > +	    ctnetlink_dump_ct_seq_adj(skb, ct) < 0 ||
> > +	    ctnetlink_dump_ct_synproxy(skb, ct) < 0)
> > +		return -1;
> > +
> > +	return 0;
> > +}
> > +
> > +static int ctnetlink_dump_info(struct sk_buff *skb, struct nf_conn *ct)
> > +{
> > +	if (ctnetlink_dump_status(skb, ct) < 0 ||
> > +	    ctnetlink_dump_mark(skb, ct) < 0 ||
> > +	    ctnetlink_dump_secctx(skb, ct) < 0 ||
> > +	    ctnetlink_dump_id(skb, ct) < 0 ||
> > +	    ctnetlink_dump_use(skb, ct) < 0 ||
> > +	    ctnetlink_dump_master(skb, ct) < 0)
> > +		return -1;
> > +
> > +	if (!test_bit(IPS_OFFLOAD_BIT, &ct->status) &&
> > +	    (ctnetlink_dump_timeout(skb, ct) < 0 ||
> > +	     ctnetlink_dump_protoinfo(skb, ct) < 0))
> > +
> > +	return 0;
> > +}
> > +
> >  static int
> >  ctnetlink_fill_info(struct sk_buff *skb, u32 portid, u32 seq, u32 type,
> > -		    struct nf_conn *ct)
> > +		    struct nf_conn *ct, bool extinfo)

[..]

> > +
> > +			/* We can't dump extension info for the unconfirmed
> > +			 * list because unconfirmed conntracks can have ct->ext
> > +			 * reallocated (and thus freed).
> > +			 *
> > +			 * In the dying list case ct->ext can't be altered during
> > +			 * list walk anymore, and free can only occur after ct
> > +			 * has been unlinked from the dying list (which can't
> > +			 * happen until after we drop pcpu->lock).
> > +			 */
> >  			res = ctnetlink_fill_info(skb, NETLINK_CB(cb->skb).portid,
> >  						  cb->nlh->nlmsg_seq,
> >  						  NFNL_MSG_TYPE(cb->nlh->nlmsg_type),
> > -						  ct);
> > -			rcu_read_unlock();
> > +						  ct, dying ? true : false);
> 
> s/dying ? true : false/dying/

Yes, but it found it misleading since the last argument isn't about
'dying' or not, it tells that we can safely access ct->ext.

  reply	other threads:[~2019-10-15 21:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-14 19:41 [PATCH nf-next] netfilter: ctnetlink: don't dump ct extensions of unconfirmed conntracks Florian Westphal
2019-10-14 20:52 ` kbuild test robot
2019-10-14 20:52   ` kbuild test robot
2019-10-15  2:58 ` kbuild test robot
2019-10-15  2:58   ` kbuild test robot
2019-10-15  3:14 ` kbuild test robot
2019-10-15  3:14   ` kbuild test robot
2019-10-15  9:23 ` Dan Carpenter
2019-10-15  9:23   ` Dan Carpenter
2019-10-15  9:23   ` Dan Carpenter
2019-10-15 21:06 ` Jeremy Sowden
2019-10-15 21:22   ` Florian Westphal [this message]
2019-10-15 21:29     ` Jeremy Sowden

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=20191015212204.GR25052@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=jeremy@azazel.net \
    --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.