netdev - RE: [PATCH net-next v6 04/11] net: Export xmit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17279E9B@AcuExch.aculab.com>
Date:	Mon, 21 Jul 2014 08:52:38 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Pravin B Shelar' <pshelar@...ira.com>,
	"davem@...emloft.net" <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next v6 04/11] net: Export xmit_recursion

From: Pravin B Shelar
> Next patch adds re-circulation action to OVS. This is recursive
> action needs to be limited to safe number recursions to
> avoid overflowing kernel stack space.  This patch export
> xmit_recursion so that OVS can increment and check the value
> before executing recirc action.
...
> +#define NET_RECURSION_LIMIT 10

I'm not entirely sure that any amount of recursion is a good idea
inside the kernel.
If the nested call frame is small enough so that your 10 nestings
are valid it must also be reasonably easy to arrange for the code
to be converted to a loop.

Remember that the highest stack use is likely to be inside some
error path (probably inside printk) so any experiments that seem
to imply that that stack use is ok are doomed.
Static analysis is possible (indirect calls make it tricky) provided
there is no recursion.
I did some static stack use analysis for an embedded system many
years ago. It showed that we needed much larger stacks that we'd
allowed for.

	David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html