Skip to contentSkip to conversation

: Enhancements to msg_set_bits() routine]

PATCH In review Jon Paul Maloy 2 participants 3 messages Apr 24, 2007 – Apr 27, 2007 1 message not in the archive

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 : Enhancements to msg_set_bits() routine]

This patch makes two enhancements to msg_set_bits():

1) It now ignores any bits of the new field value that are not covered by the mask being used. (Previously, if the new value exceeded the size of the mask the extra bits could corrupt other fields in the message header word being updated.)

2) The code has been optimized to minimize the number of run-time endianness conversion operations by leveraging the fact that the mask (and, in some cases, the value as well) is constant and the necessary conversion can be performed by the compiler.

Apply the attached patch, or pull from:

git://tipc.cslab.ericsson.net/pub/git/tipc.git

(rebased on linux/kernel/git/davem/net-2.6.git)

Summary:

net/tipc/msg.h | 11 +++++++----

1 files changed, 7 insertions(+), 4 deletions(-)

///Jon

Quoted 1 line

From 1c3c79c4c79aa8a665ddf41c08b4363cbb946950 Mon Sep 17 00:00:00 2001

From: Jon Paul Maloy <[email protected]>
Date: Mon, 23 Apr 2007 11:49:07 -0400
Subject: [PATCH 1/1] [TIPC]: Enhancements to msg_set_bits() routine

This patch makes two enhancements to msg_set_bits():

1) It now ignores any bits of the new field value that are not covered by the mask being used. (Previously, if the new value exceeded the size of the mask the extra bits could corrupt other fields in the message header word being updated.)

2) The code has been optimized to minimize the number of run-time endianness conversion operations by leveraging the fact that the mask (and, in some cases, the value as well) is constant and the necessary conversion can be performed by the compiler.

---
 net/tipc/msg.h |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)
net/tipc/msg.h +7 -4
index 62d5490..5c64e55 100644
@@ -1,8 +1,8 @@
 /*
  * net/tipc/msg.h: Include file for TIPC message header routines
  *
- * Copyright (c) 2000-2006, Ericsson AB
- * Copyright (c) 2005, Wind River Systems
+ * Copyright (c) 2000-2007, Ericsson AB
+ * Copyright (c) 2005-2007, Wind River Systems
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -71,8 +71,11 @@ static inline void msg_set_word(struct tipc_msg *m, u32 w, u32 val)
 static inline void msg_set_bits(struct tipc_msg *m, u32 w,
 				u32 pos, u32 mask, u32 val)
 {
-	u32 word = msg_word(m,w) & ~(mask << pos);
-	msg_set_word(m, w, (word |= (val << pos)));
+	val = (val & mask) << pos;
+	val = htonl(val);
+	mask = htonl(mask << pos);
+	m->hdr[w] &= ~mask;
+	m->hdr[w] |= val;
 }
 
 /*
Signature · 1 line
1.5.0.5
#1 lore raw

Hi Jon,

Quoted 4 lines · Jon Paul Maloy

2) The code has been optimized to minimize the number of run-time endianness conversion operations by leveraging the fact that the mask (and, in some cases, the value as well) is constant and the necessary conversion can be performed by the compiler.

3) It can be checked by sparse, if you use proper types.

net/tipc/msg.h static inline void msg_set_word(struct tipc_msg *m, u32 · line 72

Quoted 7 lines
net/tipc/msg.h +0 -0
index 62d5490..5c64e55 100644
@@ -71,8 +71,11 @@ static inline void msg_set_word(struct tipc_msg *m, u32
 w, u32 val) static inline void msg_set_bits(struct tipc_msg *m, u32 w,
 				u32 pos, u32 mask, u32 val)

static inlinevoid msg_set_bits(struct tipc_msg *m, u32 w,
u32 pos, __be32 mask, __be32 val)

Care to resubmit?

Best Regards

Ingo Oeser

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw

Hi Jon,

Quoted 5 lines · Jon Paul Maloy
Quoted 4 lines · Ingo Oeser

static inlinevoid msg_set_bits(struct tipc_msg *m, u32 w,
u32 pos, __be32 mask, __be32 val)

Quoted 7 lines
Quoted 1 line

Care to resubmit?

I don't mind at all, but I would first like to understand better what this means.
If I understand it correctly __be32 literally means "big-endian 32-bit integer", but the way it is used doesn't seem to imply this, since both input and output to htonl() often is of that type.

Yes, you are right! I mixed up htonl and ntohl :-) Sorry for the confusion!

Best Regards

Ingo Oeser