All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Andrey Vagin <avagin@openvz.org>
Cc: linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	netfilter@vger.kernel.org, coreteam@netfilter.org,
	netdev@vger.kernel.org, vvs@parallels.com,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Patrick McHardy <kaber@trash.net>,
	Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] netfilter: nf_conntrack: reserve two bytes for nf_ct_ext->len
Date: Thu, 27 Mar 2014 16:50:33 +0100	[thread overview]
Message-ID: <20140327155033.GF21741@breakpoint.cc> (raw)
In-Reply-To: <1395934354-13226-1-git-send-email-avagin@openvz.org>

Andrey Vagin <avagin@openvz.org> wrote:
> "len" contains sizeof(nf_ct_ext) and size of extensions. In a worst
> case it can contain all extensions. Bellow you can find sizes for all
> types of extensions. Their sum is definitely bigger than 256.
> 
> nf_ct_ext_types[0]->len = 24
> nf_ct_ext_types[1]->len = 32
> nf_ct_ext_types[2]->len = 24
> nf_ct_ext_types[3]->len = 32
> nf_ct_ext_types[4]->len = 152

Guess its  the timer in the ecache extension (with LOCKDEP on probably).

I'll submit a patch to get rid of that shortly.

I think your patch is fine because the 'no timer
in ecache extension' change is quite large, needs review/stress testing
etc and is inapropriate for stable tree anyway.

> I have seen "len" up to 280 and my host has crashes w/o this patch.

ecache is 24 bytes without that timer, should be < 256 in total for
all extensions.

I think BUILD_BUG_ON test would be nice.

  parent reply	other threads:[~2014-03-27 15:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 15:32 [PATCH] netfilter: nf_conntrack: reserve two bytes for nf_ct_ext->len Andrey Vagin
2014-03-27 15:45 ` Patrick McHardy
2014-03-27 20:06   ` [PATCH] netfilter: nf_conntrack: reserve two bytes for nf_ct_ext->len (v2) Andrey Vagin
2014-03-27 15:50 ` Florian Westphal [this message]
2014-03-27 16:01   ` [PATCH] netfilter: nf_conntrack: reserve two bytes for nf_ct_ext->len Patrick McHardy

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=20140327155033.GF21741@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=avagin@openvz.org \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=netfilter@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=vvs@parallels.com \
    /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.