Skip to contentSkip to conversation

Patch "tipc: move fragment importance field to new header position" has been added to the 4.1-stable tree

PATCH [email protected] 1 participant 1 message Oct 23, 2015

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

tipc: move fragment importance field to new header position

to the 4.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
tipc-move-fragment-importance-field-to-new-header-position.patch
and it can be found in the queue-4.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Thu Oct 22 17:25:37 PDT 2015

From: Jon Paul Maloy <[email protected]>
Date: Wed, 14 Oct 2015 09:23:18 -0400
Subject: tipc: move fragment importance field to new header position

From: Jon Paul Maloy <[email protected]>

[ Upstream commit dde4b5ae65de659b9ec64bafdde0430459fcb495 ]

In commit e3eea1eb47a ("tipc: clean up handling of message priorities") we introduced a field in the packet header for keeping track of the priority of fragments, since this value is not present in the specified protocol header. Since the value so far only is used at the transmitting end of the link, we have not yet officially defined it as part of the protocol.

Unfortunately, the field we use for keeping this value, bits 13-15 in in word 5, has turned out to be a poor choice; it is already used by the broadcast protocol for carrying the 'network id' field of the sending node. Since packet fragments also need to be transported across the broadcast protocol, the risk of conflict is obvious, and we see this happen when we use network identities larger than 2^13-1. This has escaped our testing because we have so far only been using small network id values.

We now move this field to bits 0-2 in word 9, a field that is guaranteed to be unused by all involved protocols.

Fixes e3eea1eb47a ("tipc: clean up handling of message priorities")
---
 net/tipc/msg.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/tipc/msg.h +2 -2
@@ -353,7 +353,7 @@ static inline void msg_set_seqno(struct
 static inline u32 msg_importance(struct tipc_msg *m)
 {
 	if (unlikely(msg_user(m) == MSG_FRAGMENTER))
-		return msg_bits(m, 5, 13, 0x7);
+		return msg_bits(m, 9, 0, 0x7);
 	if (likely(msg_isdata(m) && !msg_errcode(m)))
 		return msg_user(m);
 	return TIPC_SYSTEM_IMPORTANCE;
@@ -362,7 +362,7 @@ static inline u32 msg_importance(struct
 static inline void msg_set_importance(struct tipc_msg *m, u32 i)
 {
 	if (unlikely(msg_user(m) == MSG_FRAGMENTER))
-		msg_set_bits(m, 5, 13, 0x7, i);
+		msg_set_bits(m, 9, 0, 0x7, i);
 	else if (likely(i < TIPC_SYSTEM_IMPORTANCE))
 		msg_set_user(m, i);
 	else

Patches currently in stable-queue which might be from [email protected] are

queue-4.1/tipc-move-fragment-importance-field-to-new-header-position.patch