include/linux/skbuff.h: using '0xffff' instead of '~0U'

PATCH Superseded Chen Gang 5 participants 17 messages May 30, 2013 – Jun 5, 2013

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

Chen Gang

author

2013-05-30 06:04 UTC #0 lore raw

PATCH 1/1 include/linux/skbuff.h: using '0xffff' instead of '~0U'

Both 'transport_header' and 'mac_header' are u16, which are never equal to '~0U'.

So need use '0xffff' instead of '~0U'.

The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
...

Signed-off-by Chen Gang <[email protected]>

---
 include/linux/skbuff.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

include/linux/skbuff.h +2 -2

index 2e0ced1..03ba058 100644
@@ -1581,7 +1581,7 @@ static inline void skb_set_inner_mac_header(struct sk_buff *skb,
 }
 static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
 {
-	return skb->transport_header != ~0U;
+	return skb->transport_header != 0xffff;
 }
 
 static inline unsigned char *skb_transport_header(const struct sk_buff *skb)

@@ -1624,7 +1624,7 @@ static inline unsigned char *skb_mac_header(const struct sk_buff *skb)
 
 static inline int skb_mac_header_was_set(const struct sk_buff *skb)
 {
-	return skb->mac_header != ~0U;
+	return skb->mac_header != 0xffff;
 }
 
 static inline void skb_reset_mac_header(struct sk_buff *skb)

Signature · 1 line

1.7.7.6

Chen Gang

author

2013-05-30 09:55 UTC #1 lore raw

It seems a good idea to "fgrep -rn '~0U'" all source code, and check each one by one.

:-)

Quoted 39 lines · Chen Gang

Both 'transport_header' and 'mac_header' are u16, which are never equal to '~0U'.

So need use '0xffff' instead of '~0U'.

The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
...

Signed-off-by Chen Gang <[email protected]>

---
 include/linux/skbuff.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

include/linux/skbuff.h +2 -2

index 2e0ced1..03ba058 100644
@@ -1581,7 +1581,7 @@ static inline void skb_set_inner_mac_header(struct sk_buff *skb,
 }
 static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
 {
-	return skb->transport_header != ~0U;
+	return skb->transport_header != 0xffff;
 }
 
 static inline unsigned char *skb_transport_header(const struct sk_buff *skb)

@@ -1624,7 +1624,7 @@ static inline unsigned char *skb_mac_header(const struct sk_buff *skb)
 
 static inline int skb_mac_header_was_set(const struct sk_buff *skb)
 {
-	return skb->mac_header != ~0U;
+	return skb->mac_header != 0xffff;
 }
 
 static inline void skb_reset_mac_header(struct sk_buff *skb)

Signature · 3 lines

Chen Gang

Asianux Corporation

Ben Hutchings

2013-05-30 15:30 UTC #2 lore raw

In reply to Chen Gang

Quoted 4 lines · Chen Gang

Both 'transport_header' and 'mac_header' are u16, which are never equal to '~0U'.
So need use '0xffff' instead of '~0U'.

...and give this magic number a name?

Ben.

Quoted 32 lines

The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
...

Signed-off-by Chen Gang <[email protected]>

---
 include/linux/skbuff.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

include/linux/skbuff.h +2 -2

index 2e0ced1..03ba058 100644
@@ -1581,7 +1581,7 @@ static inline void skb_set_inner_mac_header(struct sk_buff *skb,
 }
 static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
 {
-	return skb->transport_header != ~0U;
+	return skb->transport_header != 0xffff;
 }
 
 static inline unsigned char *skb_transport_header(const struct sk_buff *skb)

@@ -1624,7 +1624,7 @@ static inline unsigned char *skb_mac_header(const struct sk_buff *skb)
 
 static inline int skb_mac_header_was_set(const struct sk_buff *skb)
 {
-	return skb->mac_header != ~0U;
+	return skb->mac_header != 0xffff;
 }
 
 static inline void skb_reset_mac_header(struct sk_buff *skb)

Signature · 3 lines

Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Chen Gang

author

2013-06-03 08:53 UTC #3 lore raw

Quoted 6 lines · Ben Hutchings

Quoted 4 lines · Chen Gang
Quoted 4 lines
Both 'transport_header' and 'mac_header' are u16, which are never equal to '~0U'.
So need use '0xffff' instead of '~0U'.
..and give this magic number a name?

It sounds a good idea. I will check which name is suitable for it, then send patch v2, and please help to check it, too.

Thanks.

Signature · 3 lines

Chen Gang

Asianux Corporation

Andy Shevchenko

2013-05-31 21:05 UTC #4 lore raw

In reply to Chen Gang

Quoted 5 lines · Chen Gang

Both 'transport_header' and 'mac_header' are u16, which are never equal to '~0U'.
So need use '0xffff' instead of '~0U'.

Why not "(u16)~0" ?
Or even better "!= USHORT_MAX"?

Or mac_header + 1 == 0, though it less clear.

--
With Best Regards,
Andy Shevchenko

Chen Gang

author

2013-06-03 09:23 UTC #5 lore raw

Quoted 10 lines · Andy Shevchenko

Quoted 5 lines · Chen Gang
Quoted 5 lines
Both 'transport_header' and 'mac_header' are u16, which are never equal to '~0U'.
So need use '0xffff' instead of '~0U'.
Why not "(u16)~0" ?
Or even better "!= USHORT_MAX"?
Or mac_header + 1 == 0, though it less clear.

It seems they are just the same as '0xffff' (are all 'magic' number).

We'd better to give a meaningful name to it just like Ben said.

Thanks.

Signature · 3 lines

Chen Gang

Asianux Corporation

Andy Shevchenko

2013-06-03 10:14 UTC #6 lore raw

Quoted 4 lines · Chen Gang

Quoted 1 line · Andy Shevchenko
Why not "(u16)~0" ?
We'd better to give a meaningful name to it just like Ben said.

Yeah, you could give a name, though I don't see this needs for constants like (u16)~0. It's a usual way to mark some values uninitialized.
Just an example from kernel:

/* This is limited by 16 bit "slot" numbers,
* and by available on-disk context storage. *
* Also (u16)~0 is special (denotes a "free" extent).

--
With Best Regards,
Andy Shevchenko

Chen Gang

author

2013-06-03 10:51 UTC #7 lore raw

Quoted 11 lines · Andy Shevchenko

Quoted 4 lines · Chen Gang
Quoted 1 line · Andy Shevchenko
Why not "(u16)~0" ?
We'd better to give a meaningful name to it just like Ben said.
Yeah, you could give a name, though I don't see this needs for constants like (u16)~0. It's a usual way to mark some values uninitialized.
Just an example from kernel:

Quoted 5 lines

/* This is limited by 16 bit "slot" numbers,
* and by available on-disk context storage. *
* Also (u16)~0 is special (denotes a "free" extent).

After "fgrep -rn 'u16' * | fgrep '~0'", it seems better to define a
meaningful macro for it (e.g. "#define SKB_HEADER_WAS_UNSET 0xffff").

Thanks.

Signature · 3 lines

Chen Gang

Asianux Corporation

Chen Gang

author

2013-06-03 11:24 UTC #8 lore raw

PATCH v2 1/1 include/linux/skbuff.h: using '(u16) ~0U' instead of '~0U'

Both 'transport_header' and 'mac_header' are u16, which are never equal to '~0U'.

So need use '(u16) ~0U' instead of '~0U'.

The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
...

Use meaningful macro instead of hard code number, and better to initialize 'skb->transport_header' in __alloc_skb_head(), too.

Signed-off-by Chen Gang <[email protected]>

---
 include/linux/skbuff.h |    6 ++++--
 net/core/skbuff.c      |   11 ++++++-----
 2 files changed, 10 insertions(+), 7 deletions(-)

include/linux/skbuff.h +4 -2

index 5f93119..59493f8 100644
@@ -40,6 +40,8 @@
 #define CHECKSUM_COMPLETE 2
 #define CHECKSUM_PARTIAL 3
 
+#define SKB_HEADER_UNSET_16	((unsigned short) ~0U)
+
 #define SKB_DATA_ALIGN(X)	(((X) + (SMP_CACHE_BYTES - 1)) & \
 				 ~(SMP_CACHE_BYTES - 1))
 #define SKB_WITH_OVERHEAD(X)	\

@@ -1593,7 +1595,7 @@ static inline void skb_set_inner_mac_header(struct sk_buff *skb,
 }
 static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
 {
-	return skb->transport_header != ~0U;
+	return skb->transport_header != SKB_HEADER_UNSET_16;
 }
 
 static inline unsigned char *skb_transport_header(const struct sk_buff *skb)

@@ -1636,7 +1638,7 @@ static inline unsigned char *skb_mac_header(const struct sk_buff *skb)
 
 static inline int skb_mac_header_was_set(const struct sk_buff *skb)
 {
-	return skb->mac_header != ~0U;
+	return skb->mac_header != SKB_HEADER_UNSET_16;
 }
 
 static inline void skb_reset_mac_header(struct sk_buff *skb)

net/core/skbuff.c +6 -5

index f45de07..18c6974 100644
@@ -200,7 +200,8 @@ struct sk_buff *__alloc_skb_head(gfp_t gfp_mask, int node)
 	atomic_set(&skb->users, 1);
 
 #ifdef NET_SKBUFF_DATA_USES_OFFSET
-	skb->mac_header = (__u16) ~0U;
+	skb->mac_header = SKB_HEADER_UNSET_16;
+	skb->transport_header = SKB_HEADER_UNSET_16;
 #endif
 out:
 	return skb;

@@ -276,8 +277,8 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
 	skb_reset_tail_pointer(skb);
 	skb->end = skb->tail + size;
 #ifdef NET_SKBUFF_DATA_USES_OFFSET
-	skb->mac_header = (__u16) ~0U;
-	skb->transport_header = (__u16) ~0U;
+	skb->mac_header = SKB_HEADER_UNSET_16;
+	skb->transport_header = SKB_HEADER_UNSET_16;
 #endif
 
 	/* make sure we initialize shinfo sequentially */

@@ -345,8 +346,8 @@ struct sk_buff *build_skb(void *data, unsigned int frag_size)
 	skb_reset_tail_pointer(skb);
 	skb->end = skb->tail + size;
 #ifdef NET_SKBUFF_DATA_USES_OFFSET
-	skb->mac_header = (__u16) ~0U;
-	skb->transport_header = (__u16) ~0U;
+	skb->mac_header = SKB_HEADER_UNSET_16;
+	skb->transport_header = SKB_HEADER_UNSET_16;
 #endif
 
 	/* make sure we initialize shinfo sequentially */

Signature · 1 line

1.7.7.6

Andy Shevchenko

2013-06-03 11:34 UTC #9 lore raw

Re: [PATCH v2] include/linux/skbuff.h: using '(u16) ~0U' instead of '~0U'

Quoted 4 lines · Chen Gang

Both 'transport_header' and 'mac_header' are u16, which are never equal to '~0U'.

Quoted 8 lines

So need use '(u16) ~0U' instead of '~0U'.
The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
...
Use meaningful macro instead of hard code number, and better to initialize 'skb->transport_header' in __alloc_skb_head(), too.

Looks okay. Couple of questions below.

include/linux/skbuff.h line 43

Quoted 7 lines

include/linux/skbuff.h +1 -0

@@ -40,6 +40,8 @@
 #define CHECKSUM_COMPLETE 2
 #define CHECKSUM_PARTIAL 3
 
+#define SKB_HEADER_UNSET_16    ((unsigned short) ~0U)

Isn't better to use the same type as used in the structure description?

net/core/skbuff.c struct sk_buff *__alloc_skb_head(gfp_t gfp_mask, int node) · line 204

Quoted 9 lines

net/core/skbuff.c +2 -1

@@ -200,7 +200,8 @@ struct sk_buff *__alloc_skb_head(gfp_t gfp_mask, int node)
        atomic_set(&skb->users, 1);
 
 #ifdef NET_SKBUFF_DATA_USES_OFFSET
-       skb->mac_header = (__u16) ~0U;
+       skb->mac_header = SKB_HEADER_UNSET_16;
+       skb->transport_header = SKB_HEADER_UNSET_16;

Is it correct to assign transport_header here as well?

--
With Best Regards,
Andy Shevchenko

Chen Gang

author

2013-06-03 11:47 UTC #10 lore raw

Re: [PATCH v2] include/linux/skbuff.h: using '(u16) ~0U' instead of '~0U'

Quoted 9 lines · Andy Shevchenko

Quoted 7 lines
--- a/include/linux/skbuff.h
include/linux/skbuff.h line 43
Quoted 6 lines
+++ b/include/linux/skbuff.h
include/linux/skbuff.h +1 -0
@@ -40,6 +40,8 @@
 #define CHECKSUM_COMPLETE 2
 #define CHECKSUM_PARTIAL 3
 
+#define SKB_HEADER_UNSET_16    ((unsigned short) ~0U)
Isn't better to use the same type as used in the structure description?

It sounds reasonable, I will wait 1 days, if no additional suggestions or completions, I will send patch v3.

Quoted 10 lines

Quoted 9 lines
net/core/skbuff.c struct sk_buff *__alloc_skb_head(gfp_t gfp_mask, int node) · line 204
Quoted 9 lines
net/core/skbuff.c +2 -1
@@ -200,7 +200,8 @@ struct sk_buff *__alloc_skb_head(gfp_t gfp_mask, int node)
        atomic_set(&skb->users, 1);
 
 #ifdef NET_SKBUFF_DATA_USES_OFFSET
-       skb->mac_header = (__u16) ~0U;
+       skb->mac_header = SKB_HEADER_UNSET_16;
+       skb->transport_header = SKB_HEADER_UNSET_16;
Is it correct to assign transport_header here as well?

At least, it is correct: they are in the same structure, and almost a neighbor with each other.

Hmm... I guess that may be useless currently which will waste one instruction.

But I still suggest to add it, it can avoid the new mistakes in the future.

Welcome another members to provide their suggestions for it.

Thanks.

Signature · 3 lines

Chen Gang

Asianux Corporation

David Laight

2013-06-03 12:26 UTC #11 lore raw

RE: [PATCH v2] include/linux/skbuff.h: using '(u16) ~0U' instead of '~0U'

In reply to Chen Gang

include/linux/skbuff.h line 44

Quoted 2 lines

include/linux/skbuff.h +2 -0

+#define SKB_HEADER_UNSET_16	((unsigned short) ~0U)
+

The _16 part isn't really correct, the type could be changed and then it would be wrong.

I think I might have used SKB_HEADER_OFFSET.

David

David Laight

2013-06-03 12:47 UTC #12 lore raw

RE: [PATCH v2] include/linux/skbuff.h: using '(u16) ~0U' instead of '~0U'

Quoted 7 lines

include/linux/skbuff.h line 44
Quoted 2 lines
include/linux/skbuff.h +2 -0
+#define SKB_HEADER_UNSET_16	((unsigned short) ~0U)
+
The _16 part isn't really correct, the type could be changed and then it would be wrong.
I think I might have used SKB_HEADER_OFFSET.

I meant SKB_HEADER_UNSET_OFFSET or SKB_HEADER_OFFSET_UNSET

Quoted 1 line

NrybXǧv^)޺{.n+z^)w*jgݢj/zޖ2ޙ&)ߡaGhj:+vw٥

I've NFI what adds this!

David

Chen Gang

author

2013-06-05 03:28 UTC #13 lore raw

Re: [PATCH v2] include/linux/skbuff.h: using '(u16) ~0U' instead of '~0U'

Quoted 9 lines · David Laight

Quoted 7 lines
Quoted 7 lines
+#define SKB_HEADER_UNSET_16 ((unsigned short) ~0U)
Quoted 1 line
Quoted 1 line
+
The _16 part isn't really correct, the type could be changed and then it would be wrong.
I think I might have used SKB_HEADER_OFFSET.
I meant SKB_HEADER_UNSET_OFFSET or SKB_HEADER_OFFSET_UNSET

It sound good, I choose the 2nd: 'SKB_HEADER_OFFSET_UNSET', for it may be a 'noun', not a 'sentence'.

I will send patch v3 (also use '__u16' instead of 'unsigned short')

Thanks.

Signature · 3 lines

Chen Gang

Asianux Corporation

Chen Gang

author

2013-06-05 02:55 UTC #14 lore raw

PATCH v3 1/1 include/linux/skbuff.h: using '(__u16) ~0U' instead of '~0U'

Both 'transport_header' and 'mac_header' are __u16, which are never equal to '~0U'.

So need use '(__u16) ~0U' instead of '~0U'.

The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
...

Use meaningful macro instead of hard code number, and better to initialize 'skb->transport_header' in __alloc_skb_head(), too.

Signed-off-by Chen Gang <[email protected]>

---
 include/linux/skbuff.h |    6 ++++--
 net/core/skbuff.c      |   11 ++++++-----
 2 files changed, 10 insertions(+), 7 deletions(-)

include/linux/skbuff.h +4 -2

index 5f93119..3314911 100644
@@ -40,6 +40,8 @@
 #define CHECKSUM_COMPLETE 2
 #define CHECKSUM_PARTIAL 3
 
+#define SKB_HEADER_OFFSET_UNSET	((__u16) ~0U)
+
 #define SKB_DATA_ALIGN(X)	(((X) + (SMP_CACHE_BYTES - 1)) & \
 				 ~(SMP_CACHE_BYTES - 1))
 #define SKB_WITH_OVERHEAD(X)	\

@@ -1593,7 +1595,7 @@ static inline void skb_set_inner_mac_header(struct sk_buff *skb,
 }
 static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
 {
-	return skb->transport_header != ~0U;
+	return skb->transport_header != SKB_HEADER_OFFSET_UNSET;
 }
 
 static inline unsigned char *skb_transport_header(const struct sk_buff *skb)

@@ -1636,7 +1638,7 @@ static inline unsigned char *skb_mac_header(const struct sk_buff *skb)
 
 static inline int skb_mac_header_was_set(const struct sk_buff *skb)
 {
-	return skb->mac_header != ~0U;
+	return skb->mac_header != SKB_HEADER_OFFSET_UNSET;
 }
 
 static inline void skb_reset_mac_header(struct sk_buff *skb)

net/core/skbuff.c +6 -5

index f45de07..6808433 100644
@@ -200,7 +200,8 @@ struct sk_buff *__alloc_skb_head(gfp_t gfp_mask, int node)
 	atomic_set(&skb->users, 1);
 
 #ifdef NET_SKBUFF_DATA_USES_OFFSET
-	skb->mac_header = (__u16) ~0U;
+	skb->mac_header = SKB_HEADER_OFFSET_UNSET;
+	skb->transport_header = SKB_HEADER_OFFSET_UNSET;
 #endif
 out:
 	return skb;

@@ -276,8 +277,8 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
 	skb_reset_tail_pointer(skb);
 	skb->end = skb->tail + size;
 #ifdef NET_SKBUFF_DATA_USES_OFFSET
-	skb->mac_header = (__u16) ~0U;
-	skb->transport_header = (__u16) ~0U;
+	skb->mac_header = SKB_HEADER_OFFSET_UNSET;
+	skb->transport_header = SKB_HEADER_OFFSET_UNSET;
 #endif
 
 	/* make sure we initialize shinfo sequentially */

@@ -345,8 +346,8 @@ struct sk_buff *build_skb(void *data, unsigned int frag_size)
 	skb_reset_tail_pointer(skb);
 	skb->end = skb->tail + size;
 #ifdef NET_SKBUFF_DATA_USES_OFFSET
-	skb->mac_header = (__u16) ~0U;
-	skb->transport_header = (__u16) ~0U;
+	skb->mac_header = SKB_HEADER_OFFSET_UNSET;
+	skb->transport_header = SKB_HEADER_OFFSET_UNSET;
 #endif
 
 	/* make sure we initialize shinfo sequentially */

Signature · 1 line

1.7.7.6

David Miller

maintainer

2013-06-05 08:36 UTC #15 lore raw

Re: [PATCH v3] include/linux/skbuff.h: using '(__u16) ~0U' instead of '~0U'

From: Chen Gang <[email protected]>
Date: Wed, 05 Jun 2013 08:54:22 +0800

Quoted 10 lines

Both 'transport_header' and 'mac_header' are __u16, which are never equal to '~0U'.
So need use '(__u16) ~0U' instead of '~0U'.
The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
...

Quoted 6 lines

Use meaningful macro instead of hard code number, and better to initialize 'skb->transport_header' in __alloc_skb_head(), too.
Signed-off-by Chen Gang <[email protected]>

Your patch doesn't apply to the tree because this has been fixed already for several days by using "typeof(x) ~0U"

Chen Gang

author

2013-06-05 11:16 UTC #16 lore raw

Re: [PATCH v3] include/linux/skbuff.h: using '(__u16) ~0U' instead of '~0U'

Quoted 13 lines · David Miller

From: Chen Gang <[email protected]>
Date: Wed, 05 Jun 2013 08:54:22 +0800
Quoted 10 lines
Quoted 10 lines
Both 'transport_header' and 'mac_header' are __u16, which are never equal to '~0U'.
So need use '(__u16) ~0U' instead of '~0U'.
The related warning (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
include/linux/skbuff.h:1587:2: warning: comparison is always true due to limited range of data type [-Wtype-limits]
...

Quoted 10 lines

Quoted 6 lines
Quoted 6 lines
Use meaningful macro instead of hard code number, and better to initialize 'skb->transport_header' in __alloc_skb_head(), too.
Signed-off-by Chen Gang <[email protected]>
Your patch doesn't apply to the tree because this has been fixed already for several days by using "typeof(x) ~0U"

OK, thanks.

Signature · 3 lines

Chen Gang

Asianux Corporation