From: Jeremy Sowden <jeremy@azazel.net>
To: Florian Westphal <fw@strlen.de>
Cc: 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 22:29:18 +0100 [thread overview]
Message-ID: <20191015212917.GA12740@azazel.net> (raw)
In-Reply-To: <20191015212204.GR25052@breakpoint.cc>
[-- Attachment #1: Type: text/plain, Size: 3731 bytes --]
On 2019-10-15, at 23:22:04 +0200, Florian Westphal wrote:
> Jeremy Sowden 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.
Fair enough. Read in the context of a patch, it just looks
tautological.
J.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2019-10-15 21:29 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
2019-10-15 21:29 ` Jeremy Sowden [this message]
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=20191015212917.GA12740@azazel.net \
--to=jeremy@azazel.net \
--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.