From: Eyal Birger <eyal.birger@gmail.com>
To: John Hurley <john.hurley@netronome.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, fw@strlen.de,
jhs@mojatatu.com, simon.horman@netronome.com,
jakub.kicinski@netronome.com, oss-drivers@netronome.com,
shmulik@metanetworks.com
Subject: Re: [PATCH net-next 2/2] net: sched: protect against stack overflow in TC act_mirred
Date: Tue, 25 Jun 2019 11:30:10 +0300 [thread overview]
Message-ID: <20190625113010.7da5dbcb@jimi> (raw)
In-Reply-To: <1561414416-29732-3-git-send-email-john.hurley@netronome.com>
Hi John,
On Mon, 24 Jun 2019 23:13:36 +0100
John Hurley <john.hurley@netronome.com> wrote:
> TC hooks allow the application of filters and actions to packets at
> both ingress and egress of the network stack. It is possible, with
> poor configuration, that this can produce loops whereby an ingress
> hook calls a mirred egress action that has an egress hook that
> redirects back to the first ingress etc. The TC core classifier
> protects against loops when doing reclassifies but there is no
> protection against a packet looping between multiple hooks and
> recursively calling act_mirred. This can lead to stack overflow
> panics.
>
> Add a per CPU counter to act_mirred that is incremented for each
> recursive call of the action function when processing a packet. If a
> limit is passed then the packet is dropped and CPU counter reset.
>
> Note that this patch does not protect against loops in TC datapaths.
> Its aim is to prevent stack overflow kernel panics that can be a
> consequence of such loops.
>
> Signed-off-by: John Hurley <john.hurley@netronome.com>
> Reviewed-by: Simon Horman <simon.horman@netronome.com>
> ---
> net/sched/act_mirred.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
> index 8c1d736..c3fce36 100644
> --- a/net/sched/act_mirred.c
> +++ b/net/sched/act_mirred.c
> @@ -27,6 +27,9 @@
> static LIST_HEAD(mirred_list);
> static DEFINE_SPINLOCK(mirred_list_lock);
>
> +#define MIRRED_RECURSION_LIMIT 4
Could you increase the limit to maybe 6 or 8? I am aware of cases where
mirred ingress is used for cascading several layers of logical network
interfaces and 4 seems a little limiting.
Thanks,
Eyal.
next prev parent reply other threads:[~2019-06-25 8:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-24 22:13 [PATCH net-next 0/2] Track recursive calls in TC act_mirred John Hurley
2019-06-24 22:13 ` [PATCH net-next 1/2] net: sched: refactor reinsert action John Hurley
2019-06-24 22:13 ` [PATCH net-next 2/2] net: sched: protect against stack overflow in TC act_mirred John Hurley
2019-06-25 8:30 ` Eyal Birger [this message]
2019-06-25 9:06 ` John Hurley
2019-06-25 9:15 ` Florian Westphal
2019-06-25 9:42 ` John Hurley
2019-06-25 11:24 ` Jamal Hadi Salim
2019-06-26 4:37 ` Eyal Birger
2019-06-25 11:18 ` [PATCH net-next 0/2] Track recursive calls " Jamal Hadi Salim
2019-06-25 13:26 ` John Hurley
2019-06-28 21:37 ` David Miller
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=20190625113010.7da5dbcb@jimi \
--to=eyal.birger@gmail.com \
--cc=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=jakub.kicinski@netronome.com \
--cc=jhs@mojatatu.com \
--cc=john.hurley@netronome.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
--cc=shmulik@metanetworks.com \
--cc=simon.horman@netronome.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.