[PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type\f

[PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type\f

[Thomas Graf]

RTM_MAX is currently set to the maximum reserverd message type plus one
thus being the cause of two bugs for new types being assigned a) given the
new family registers only the NEW command in its reserved block the array
size for per family entries is calculated one entry short and b) given the
new family registers all commands RTM_MAX would point to the first entry
of the block following this one and the rtnetlink receive path would accept
a message type for a nonexisting family.

This patch changes RTM_MAX to point to the maximum valid message type
by aligning it to the start of the next block and subtracting one.

Signed-off-by: Thomas Graf <tgraf@suug.ch>

--- linux-2.6.12-rc3.orig/include/linux/rtnetlink.h	2005-04-30 20:22:19.000000000 +0200
+++ linux-2.6.12-rc3/include/linux/rtnetlink.h	2005-04-30 20:25:09.000000000 +0200
@@ -89,8 +89,8 @@
 	RTM_GETANYCAST	= 62,
 #define RTM_GETANYCAST	RTM_GETANYCAST
 
-	RTM_MAX,
-#define RTM_MAX		RTM_MAX
+	__RTM_MAX,
+#define RTM_MAX		(((__RTM_MAX + 3) & ~3) - 1)
 };
 
 /* 

Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type

[David S. Miller]

On Sat, 30 Apr 2005 21:50:58 +0200
Thomas Graf <tgraf@suug.ch> wrote:

> RTM_MAX is currently set to the maximum reserverd message type plus one
> thus being the cause of two bugs for new types being assigned a) given the
> new family registers only the NEW command in its reserved block the array
> size for per family entries is calculated one entry short and b) given the
> new family registers all commands RTM_MAX would point to the first entry
> of the block following this one and the rtnetlink receive path would accept
> a message type for a nonexisting family.
> 
> This patch changes RTM_MAX to point to the maximum valid message type
> by aligning it to the start of the next block and subtracting one.
> 
> Signed-off-by: Thomas Graf <tgraf@suug.ch>

Excellent observation.  The fact that we encode the "modifies state"
in the low bits of the RTM_* numbers has always been a source of
obscure bugs and hard to track down errors.

Patch applied, thanks.

Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type

[Thomas Graf]

* David S. Miller <20050503142740.345925ea.davem@davemloft.net> 2005-05-03 14:27
> Excellent observation.  The fact that we encode the "modifies state"
> in the low bits of the RTM_* numbers has always been a source of
> obscure bugs and hard to track down errors.
> 
> Patch applied, thanks.

Do you want 2.4 backports for all patches or just the xfrm
off-by-one fix?

Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type

[David S. Miller]

On Wed, 4 May 2005 00:20:03 +0200
Thomas Graf <tgraf@suug.ch> wrote:

> * David S. Miller <20050503142740.345925ea.davem@davemloft.net> 2005-05-03 14:27
> > Excellent observation.  The fact that we encode the "modifies state"
> > in the low bits of the RTM_* numbers has always been a source of
> > obscure bugs and hard to track down errors.
> > 
> > Patch applied, thanks.
> 
> Do you want 2.4 backports for all patches or just the xfrm
> off-by-one fix?

Congratulations if you can find xfrm in the vanilla
2.4.x tree :-)

Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type

[Thomas Graf]

* David S. Miller <20050503152704.4c6744d6.davem@davemloft.net> 2005-05-03 15:27
> On Wed, 4 May 2005 00:20:03 +0200
> Thomas Graf <tgraf@suug.ch> wrote:
> 
> > * David S. Miller <20050503142740.345925ea.davem@davemloft.net> 2005-05-03 14:27
> > > Excellent observation.  The fact that we encode the "modifies state"
> > > in the low bits of the RTM_* numbers has always been a source of
> > > obscure bugs and hard to track down errors.
> > > 
> > > Patch applied, thanks.
> > 
> > Do you want 2.4 backports for all patches or just the xfrm
> > off-by-one fix?
> 
> Congratulations if you can find xfrm in the vanilla
> 2.4.x tree :-)

Heh, ok ok ;-> I think none of the patches need to be backported
then, although the type > RTM_MAX has an off-by-one issue the
current RTM_MAX is set to one below the start of the next block
so the behaviour matches the 2.6 tree.