[PATCH net-next 3/6] 6lowpan: introduce lowpan_fetch_skb function

This patch adds a helper function to parse the ipv6 header to a
6lowpan header in stream.

This function checks first if we can pull data with a specific
length from a skb. If this seems to be okay, we copy skb data to
a destination pointer and run skb_pull.

Signed-off-by: Alexander Aring <redacted>
Reviewed-by: Werner Almesberger <redacted>
---
 net/ieee802154/6lowpan.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index 61f0ce9..e3348ec 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h

@@ -233,4 +233,16 @@
 					dest = 16 bit inline */
 #define LOWPAN_NHC_UDP_CS_P_11	0xF3 /* source & dest = 0xF0B + 4bit inline */
 
+static inline bool lowpan_fetch_skb(struct sk_buff *skb,
+		void *data, const unsigned int len)
+{
+	if (unlikely(!pskb_may_pull(skb, len)))
+		return true;
+
+	skb_copy_from_linear_data(skb, data, len);
+	skb_pull(skb, len);
+
+	return false;
+}
+
 #endif /* __6LOWPAN_H__ */

-- 
1.8.3.3


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk

On Wed, Aug 14, 2013 at 01:01:45PM +0200, Alexander Aring wrote:

Isn't the return value inverted here?

Greetings,

  Hannes

On 08/14/2013 03:49 PM, Hannes Frederic Sowa wrote:

On Wed, Aug 14, 2013 at 01:01:45PM +0200, Alexander Aring wrote:

quoted

This patch adds a helper function to parse the ipv6 header to a
6lowpan header in stream.

This function checks first if we can pull data with a specific
length from a skb. If this seems to be okay, we copy skb data to
a destination pointer and run skb_pull.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Reviewed-by: Werner Almesberger <redacted>
---
  net/ieee802154/6lowpan.h | 12 ++++++++++++
  1 file changed, 12 insertions(+)

diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index 61f0ce9..e3348ec 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h

@@ -233,4 +233,16 @@
  					dest = 16 bit inline */
  #define LOWPAN_NHC_UDP_CS_P_11	0xF3 /* source & dest = 0xF0B + 4bit inline */

+static inline bool lowpan_fetch_skb(struct sk_buff *skb,
+		void *data, const unsigned int len)
+{
+	if (unlikely(!pskb_may_pull(skb, len)))
+		return true;
+
+	skb_copy_from_linear_data(skb, data, len);
+	skb_pull(skb, len);
+
+	return false;
+}

Isn't the return value inverted here?

Nope, everything is right here, but I spent several minutes to get it...
Probably using of standard intergers will be better here: return -EINVAL 
and return 0;

Greetings,

   Hannes

On Wed, Aug 14, 2013 at 03:55:21PM +0400, Alexander Smirnov wrote:

On 08/14/2013 03:49 PM, Hannes Frederic Sowa wrote:

quoted

On Wed, Aug 14, 2013 at 01:01:45PM +0200, Alexander Aring wrote:

quoted

This patch adds a helper function to parse the ipv6 header to a
6lowpan header in stream.

This function checks first if we can pull data with a specific
length from a skb. If this seems to be okay, we copy skb data to
a destination pointer and run skb_pull.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Reviewed-by: Werner Almesberger <redacted>
---
 net/ieee802154/6lowpan.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index 61f0ce9..e3348ec 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h

@@ -233,4 +233,16 @@
 					dest = 16 bit inline */
 #define LOWPAN_NHC_UDP_CS_P_11	0xF3 /* source & dest = 0xF0B + 4bit 
 inline */

+static inline bool lowpan_fetch_skb(struct sk_buff *skb,
+		void *data, const unsigned int len)
+{
+	if (unlikely(!pskb_may_pull(skb, len)))
+		return true;
+
+	skb_copy_from_linear_data(skb, data, len);
+	skb_pull(skb, len);
+
+	return false;
+}

Isn't the return value inverted here?

Nope, everything is right here, but I spent several minutes to get it...
Probably using of standard intergers will be better here: return -EINVAL 
and return 0;

Ah, yes, I saw it in your next patch. You could also use false for failure and
true for success. Either way, this seemd a bit unnatural for me.

Thanks,

  Hannes

Hi Alex,

On Wed, Aug 14, 2013 at 03:55:21PM +0400, Alexander Smirnov wrote:

On 08/14/2013 03:49 PM, Hannes Frederic Sowa wrote:

quoted

On Wed, Aug 14, 2013 at 01:01:45PM +0200, Alexander Aring wrote:

quoted

This patch adds a helper function to parse the ipv6 header to a
6lowpan header in stream.

This function checks first if we can pull data with a specific
length from a skb. If this seems to be okay, we copy skb data to
a destination pointer and run skb_pull.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Reviewed-by: Werner Almesberger <redacted>
---
 net/ieee802154/6lowpan.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index 61f0ce9..e3348ec 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h

@@ -233,4 +233,16 @@
 					dest = 16 bit inline */
 #define LOWPAN_NHC_UDP_CS_P_11	0xF3 /* source & dest = 0xF0B + 4bit inline */

+static inline bool lowpan_fetch_skb(struct sk_buff *skb,
+		void *data, const unsigned int len)
+{
+	if (unlikely(!pskb_may_pull(skb, len)))
+		return true;
+
+	skb_copy_from_linear_data(skb, data, len);
+	skb_pull(skb, len);
+
+	return false;
+}

Isn't the return value inverted here?

Nope, everything is right here, but I spent several minutes to get it...
Probably using of standard intergers will be better here: return
-EINVAL and return 0;

This was the old behaviour, we decide it to make it like this:

fail = ...
fail |= ....

if (fail)
	...

We discussed that already at the linux-zigbee-devel mailinglist.
I don't know what I should do now, on linux-zigbee-devel we decide it to
this way, now we decide it in a other way...

Regards
Alex

On Wed, Aug 14, 2013 at 02:45:47PM +0200, Alexander Aring wrote:

This was the old behaviour, we decide it to make it like this:

fail = ...
fail |= ....

if (fail)
	...

We discussed that already at the linux-zigbee-devel mailinglist.
I don't know what I should do now, on linux-zigbee-devel we decide it to
this way, now we decide it in a other way...

Oh, I didn't know. Please just take my mail as a suggestion. If there
already was a discussion and you had a consensus about that please just
ignore my mails. :)

Thanks,

  Hannes

Hi Hannes,

On Wed, Aug 14, 2013 at 02:47:54PM +0200, Hannes Frederic Sowa wrote:

On Wed, Aug 14, 2013 at 02:45:47PM +0200, Alexander Aring wrote:

quoted

This was the old behaviour, we decide it to make it like this:

fail = ...
fail |= ....

if (fail)
	...

We discussed that already at the linux-zigbee-devel mailinglist.
I don't know what I should do now, on linux-zigbee-devel we decide it to
this way, now we decide it in a other way...

Oh, I didn't know. Please just take my mail as a suggestion. If there
already was a discussion and you had a consensus about that please just
ignore my mails. :)

This discussion was only with two persons.
So I am happy to hear some other opinions. :-)

Regards
Alex