Fix RTM_MAX to represent the maximum valid message type
Subsystems (2)
PATCH 1/3 Fix RTM_MAX to represent the maximum valid message type
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.
include/linux/rtnetlink.h +2 -2
@@ -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) };/*
David S. Miller
maintainerQuoted 8 lines · On Sat, 30 Apr 2005 21:50:58 +0200 Thomas Graf <[email protected]> wrote:
RTM_MAXis 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 commandsRTM_MAXwould 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.
Quoted 4 lines
This patch changes
RTM_MAXto 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 <[email protected]>
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.
* David S. Miller <[email protected]> 2005-05-03 14:27
Quoted 5 lines
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?
David S. Miller
maintainerQuoted 9 lines · On Wed, 4 May 2005 00:20:03 +0200 Thomas Graf <[email protected]> wrote:
* David S. Miller <[email protected]> 2005-05-03 14:27
Quoted 5 lines
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 :-)
* David S. Miller <[email protected]> 2005-05-03 15:27
Quoted 8 lines
Quoted 5 lines · On Wed, 4 May 2005 00:20:03 +0200 Thomas Graf <[email protected]> wrote:
* David S. Miller <[email protected]> 2005-05-03 14:27
Quoted 4 lines
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.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
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.