* Re: REGRESSION: 3.4.0->3.5.0-rc2 kernel WARNING on cable plug on Acer Aspire One, no network
From: Alex Villacís Lasso @ 2012-06-10 20:34 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20120610195906.GA15641@electric-eye.fr.zoreil.com>
El 10/06/12 14:59, Francois Romieu escribió:
> Alex Villacís Lasso<a_villacis@palosanto.com> :
> [...]
>
> Which r8169 chipset version is it (dmesg | grep XID) ?
>
$ grep XID dmesg-3.5.0-rc2.txt
[ 15.873858] r8169 0000:02:00.0: eth0: RTL8102e at 0xf7c0e000,
00:1e:68:e5:5d:b1, XID 04a00000 IRQ 44
^ permalink raw reply
* YOU WON!!!!!
From: HTC ANNUAL AWARDS @ 2012-06-10 21:06 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 35 bytes --]
Kindly Read The Attached Mail
[-- Attachment #2: HT.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 14871 bytes --]
^ permalink raw reply
* hello
From: awa sani @ 2012-06-10 21:59 UTC (permalink / raw)
My name is awa,i am woman. i am interest on you in relationship so
that is why i delighted to contact you,i am honest and caring
woman,please contact me if u are interested.
>From awa
^ permalink raw reply
* tcp/ip server timeout
From: Michael D. Berger @ 2012-06-10 22:32 UTC (permalink / raw)
To: netdev
Using Linux, Fedora 16.
Is there a way to have a tcp/ip server socket signal or
disconnect when there has been no traffic in either
direction for, say, 5 minutes?
Thanks for your help,
Mike.
^ permalink raw reply
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4, 6}/route.c
From: Gao feng @ 2012-06-11 0:27 UTC (permalink / raw)
To: Fengguang Wu
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
David Miller
In-Reply-To: <20120610101640.GA14476@localhost>
Hi fengguang:
于 2012年06月10日 18:16, Fengguang Wu 写道:
> On Sat, Jun 09, 2012 at 10:18:01PM -0400, David Miller wrote:
>> From: David Miller <davem@davemloft.net>
>> Date: Sat, 09 Jun 2012 19:09:29 -0700 (PDT)
>>
>>> From: Fengguang Wu <wfg@linux.intel.com>
>>> Date: Sun, 10 Jun 2012 10:08:01 +0800
>>>
>>>> And in another config, an old error still triggers:
>>>>
>>>> net/ipv4/inetpeer.c: In function ‘family_to_base’:
>>>> net/ipv4/inetpeer.c:397:50: error: ‘struct net’ has no member named ‘ipv6’
>>>> net/ipv4/inetpeer.c:398:1: warning: control reaches end of non-void function [-Wreturn-type]
>>>>
>>>> I'm building this patch on top of net-next master.
>>>
>>> What a fucking mess Gao created, I'll fix this.
>>>
>>> Thanks for the report.
>>
>> I just pushed the following to net-next:
>>
>> --------------------
>> inet: Pass inetpeer root into inet_getpeer*() interfaces.
>>
>> Otherwise we reference potentially non-existing members when
>> ipv6 is disabled.
>>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>> ---
>> include/net/inetpeer.h | 10 +++++-----
>> net/ipv4/inetpeer.c | 9 +--------
>> net/ipv4/ip_fragment.c | 2 +-
>> net/ipv4/route.c | 6 +++---
>> net/ipv6/route.c | 2 +-
>> 5 files changed, 11 insertions(+), 18 deletions(-)
>
> It triggers some other errors:
>
> net/ipv4/inetpeer.c: In function ‘inetpeer_invalidate_tree’:
> net/ipv4/inetpeer.c:585:9: error: implicit declaration of function ‘family_to_base’ [-Werror=implicit-function-declaration]
> net/ipv4/inetpeer.c:585:32: warning: initialization makes pointer from integer without a cast [enabled by default]
> net/ipv6/tcp_ipv6.c:1758:2: warning: passing argument 1 of ‘inet_getpeer_v6’ from incompatible pointer type [enabled by default]
> include/net/inetpeer.h:101:33: note: expected ‘struct inet_peer_base *’ but argument is of type ‘struct net *’
> net/ipv4/tcp_ipv4.c:1843:2: warning: passing argument 1 of ‘inet_getpeer_v4’ from incompatible pointer type [enabled by default]
> include/net/inetpeer.h:90:33: note: expected ‘struct inet_peer_base *’ but argument is of type ‘struct net *’
>
> which can be fixed by the following diff.
seams you did not pull the last codes
David has delete the tcp_v(4,6)_tw_get_peer
in commit 2397849baa7c44c242e5d5142d5d16d1e7ed53d0.
Thanks.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4,6}/route.c
From: Fengguang Wu @ 2012-06-11 1:44 UTC (permalink / raw)
To: Gao feng
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
David Miller, Giuseppe CAVALLARO
In-Reply-To: <4FD53B74.1050409-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
> seams you did not pull the last codes
> David has delete the tcp_v(4,6)_tw_get_peer
> in commit 2397849baa7c44c242e5d5142d5d16d1e7ed53d0.
Ah OK, I retested net-next head and it compiles fine, except for these
errors I reported in another thread:
ERROR: "stmmac_pltfr_driver" [drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!
ERROR: "stmmac_pci_driver" [drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!
It seems the bug fixing patch
stmmac: fix driver built w/ w/o both pci and platf modules
was only applied to net/master, but not in net-next/master yet.
Thanks,
Fengguang
^ permalink raw reply
* Re: [BUG report] net.core.rmem_default is larger than net.core.rmem_max
From: Shan Wei @ 2012-06-11 2:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev
In-Reply-To: <4F9A676A.8070406@gmail.com>
Shan Wei said, at 2012/4/27 17:31:
>
> It's unconventional that "default" value is greater than "max". :-(
>
> net.core.rmem_max = 131071
> net.core.rmem_default = 229376
ping......
I have no idea to fix this.
Maybe add rmem_max value to be greater than rmem_default?
Eric, can you look into this?
>
> net.core.wmem_max = 131071
> net.core.wmem_default = 229376
>
>
> And bisect the code to find the following commit caused this phenomenon.
> This patch increase SK_WMEM_MAX and SK_RMEM_MAX which are used to
> initialize them.
> But rmem_max and wmem_max value are still be covered according the RAM size
> in sk_init().
>
> 87fb4b7b533073eeeaed0b6bf7c2328995f6c075 is the first bad commit
> commit 87fb4b7b533073eeeaed0b6bf7c2328995f6c075
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu Oct 13 07:28:54 2011 +0000
>
> net: more accurate skb truesize
>
>
^ permalink raw reply
* Re: [PATCH] usbnet: Activate the halt interrupt endpoint to fix endless "XactErr" error
From: Ming Lei @ 2012-06-11 2:27 UTC (permalink / raw)
To: Huajun Li; +Cc: linux-usb, Network Development, Alan Stern
In-Reply-To: <CA+v9cxZd3W8BwWoxng0zPXe0-WA2pObre=Bjm4htJB_j-3YkJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Jun 10, 2012 at 7:13 PM, Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sun, Jun 10, 2012 at 5:53 PM, Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Sun, Jun 10, 2012 at 9:07 AM, Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>>
>>> However, the other interface can work, it is of "bInterfaceClass
>>> 10 CDC Data". I can set IP to usb0 and it work fine.
>>>
>>> BTW, the device has 2 interfaces, one is of "bInterfaceClass 10
>>> CDC Data" which includes bulk in/out endpoint for rx/tx; the other is
>>> "bInterfaceClass 2 Communications" which contains the
>>> interrupt endpoint. From info dumped by "lsusb -v", the device is
>>> compliance with CDC protocol.
>>
>> Both the two interfaces belongs to cdc_ether device, see cdc spec
>> and usbnet_generic_cdc_bind(), which will make cdc_ether dirver to
>> claim data interface.
>>
>
> Yes, you are right.
>
>>>
>>>>>> BTW, the device can work well if I modprobe cdc_ether driver after
>>>>>> changed the configuration.
>>>>
>>>> Maybe just the delay introduced by 'modprobe cdc_ether' fixes the
>>>> problem.
>>
>> If you can change the firmware, please find the bug and fix it. Otherwise,
>> you can add a simple quirk in cdc_ether.c for your device.
>>
> Yes, this solution can solve the issue directly.
>
> However, besides "-EPIPE", I think usbnet.c should also handle the
> error of "-EPROTO".
Yes, you can clear halt for -EPIPE, and take Alan's suggestion to
reset device if the error of "-EPROTO" is got.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4,6}/route.c
From: David Miller @ 2012-06-11 3:03 UTC (permalink / raw)
To: wfg-VuQAYsv1563Yd54FQh9/CA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <20120610101640.GA14476@localhost>
From: Fengguang Wu <wfg@linux.intel.com>
Date: Sun, 10 Jun 2012 18:16:40 +0800
> net/ipv4/inetpeer.c:585:9: error: implicit declaration of function ‘family_to_base’ [-Werror=implicit-function-declaration]
There are no references to family_to_base in the net-next tree.
If you only applied the patches you were explicitly CC:'d on,
that's the problem. There were other changes made in the net-next
tree in-between that remove the other references to that function.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH] ieee802154: verify packet size before trying to allocate it
From: David Miller @ 2012-06-11 3:04 UTC (permalink / raw)
To: levinsasha928
Cc: dbaryshkov, slapin, linux-zigbee-devel, netdev, linux-kernel
In-Reply-To: <1339326619-1753-1-git-send-email-levinsasha928@gmail.com>
From: Sasha Levin <levinsasha928@gmail.com>
Date: Sun, 10 Jun 2012 13:10:19 +0200
> Currently when sending data over datagram, the send function will attempt to
> allocate any size passed on from the userspace.
>
> We should make sure that this size is checked and limited. The maximum size
> of an IP packet seemed like the safest limit here.
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Why not limit to the device MTU? That's exactly what I suggested
to you.
^ permalink raw reply
* Re: [PATCH rfc net] Allow the autoconfigured network interface to be renamed.
From: David Miller @ 2012-06-11 3:08 UTC (permalink / raw)
To: scott; +Cc: netdev, scott.parlane
In-Reply-To: <1339343619.27293.7.camel@c2d>
From: Scott Parlane <scott@scottnz.com>
Date: Mon, 11 Jun 2012 03:53:39 +1200
> We have been running it for several months on ~80 x86 machines
The number of people already running a patch is not the criteria use
to determine if a patch gets added or not.
^ permalink raw reply
* Re: [PATCH] af_packet: check loop for greater than zero in tpacket_fill_skb
From: David Miller @ 2012-06-11 3:10 UTC (permalink / raw)
To: danborkmann; +Cc: netdev
In-Reply-To: <4FD4F494.6020102@iogearbox.net>
From: Daniel Borkmann <danborkmann@iogearbox.net>
Date: Sun, 10 Jun 2012 21:25:08 +0200
> It could be more safe to check the 'to_write' for 'greater than zero'
> instead for 'not zero'. 'to_write' is of type int and subtraction operations
> are performed on it, so in the case of malformed values that are
> subtracted from 'to_write', it could become less than zero, which is then
> interpreted as 'not zero' in the while condition, thus the loop won't
> return as expected.
>
> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
I hate this kind of change.
The implication is that there are bugs in the loop that can cause
the value to go negative.
Unless you can show that this actually happens, leave this clean
test alone.
^ permalink raw reply
* Re: [PATCH] r8169: avoid NAPI scheduling delay.
From: David Miller @ 2012-06-11 3:21 UTC (permalink / raw)
To: romieu; +Cc: netdev, davej, marc.c.dionne, tglx, js, realnc, hayeswang
In-Reply-To: <20120609205316.GA5915@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Sat, 9 Jun 2012 22:53:16 +0200
> While reworking the r8169 driver a few months ago to perform the
> smallest amount of work in the irq handler, I took care of avoiding
> any irq mask register operation in the slow work dedicated user
> context thread. The slow work thread scheduled an extra round of NAPI
> work which would ultimately set the irq mask register as required,
> thus keeping such irq mask operations in the NAPI handler.
> It would eventually race with the irq handler and delay NAPI execution
> for - assuming no further irq - a whole ksoftirqd period. Mildly a
> problem for rare link changes or corner case PCI events.
>
> The race was always lost after the last bh disabling lock had been
> removed from the work thread and people started wondering where those
> pesky "NOHZ: local_softirq_pending 08" messages came from.
>
> Actually the irq mask register _can_ be set up directly in the slow
> work thread.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Reported-by: Dave Jones <davej@redhat.com>
> Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] virtio-net: fix a race on 32bit arches
From: David Miller @ 2012-06-11 3:23 UTC (permalink / raw)
To: mst; +Cc: eric.dumazet, netdev, linux-kernel, virtualization, shemminger
In-Reply-To: <20120610102512.GB6793@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 10 Jun 2012 13:25:12 +0300
> On Wed, Jun 06, 2012 at 10:35:24AM +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> commit 3fa2a1df909 (virtio-net: per cpu 64 bit stats (v2)) added a race
>> on 32bit arches.
>>
>> We must use separate syncp for rx and tx path as they can be run at the
>> same time on different cpus. Thus one sequence increment can be lost and
>> readers spin forever.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Stephen Hemminger <shemminger@vyatta.com>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Cc: Jason Wang <jasowang@redhat.com>
>
> I'm still thinking about moving tx to take a xmit lock long term,
> meanwhile this fix appears appropriate for 3.5.
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> Dave, can you pick this up pls?
Done, thanks.
^ permalink raw reply
* Re: [PATCH rfc net] Allow the autoconfigured network interface to be renamed.
From: David Miller @ 2012-06-11 3:25 UTC (permalink / raw)
To: scott; +Cc: netdev, scott.parlane
In-Reply-To: <1339228087-14870-1-git-send-email-scott@scottnz.com>
From: Scott Parlane <scott@scottnz.com>
Date: Sat, 9 Jun 2012 19:48:07 +1200
> From: Scott Parlane <scott.parlane@alliedtelesis.co.nz>
>
> if IP_PNP_RENAME_DEV is set, the first interface to be configured
> automatically by the kernel during boot will be renamed.
>
> IP_PNP_DEV_NEWNAME is the name to give the autoconfigured device.
>
> No changes will be made to any interface that is not autoconfigured.
>
> This allows the assurance of the boot device name, without the need
> for an initramfs.
>
> Signed-off-by: Scott Parlane <scott.parlane@alliedtelesis.co.nz>
Making this a compile time option makes absolutely no sense at all.
Assuming this feature is desirable at all (which is a big IF), it
should be a kernel command line option.
^ permalink raw reply
* [PATCH net-next 0/4] 6lowpan: set of bug fixes
From: Tony Cheneau @ 2012-06-11 4:37 UTC (permalink / raw)
To: netdev, linux-zigbee-devel; +Cc: alex.bluesman.smirnov
Hello,
(This is my first time submitting patches. If I fail to apply to
some rules in here, please let me know)
After reading the 6lowpan code, I found a few issues. This patchset
fixes them. This patchset should apply cleanly against the current
net-next. It contains only bug fixes, I'll send later on a few other
patches that will offer new functionalities.
This is a set of 4 small patches that correct bugs in 6lowpan:
- patch 1 fixes a potential crash when reassembling UDP fragments
- patch 2 fixes a type issues that prevent the fragmentation reassembly
to operate properly.
- patch 3 and 4 corrects field encoding issues
Hope it helps.
Regards,
Tony Cheneau
^ permalink raw reply
* [PATCH net-next 2/4] 6lowpan: Incorrect type in lowpan_alloc_new_frame() definition : tag is u8 but should be u16
From: Tony Cheneau @ 2012-06-11 4:39 UTC (permalink / raw)
To: netdev, linux-zigbee-devel; +Cc: alex.bluesman.smirnov
lowpan_alloc_new_frame() takes u8 tag as an argument. Howerer,
its only caller, lowpan_process_data() passes down a u16. Hence,
the tag value got corrupted.
This prevent 6lowpan fragment reassembly after 256 fragmented packets
have been reassembled by the same recipient.
---
net/ieee802154/6lowpan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index a52e795..af4f29b 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -654,7 +654,7 @@ static void lowpan_fragment_timer_expired(unsigned
long entry_addr) }
static struct lowpan_fragment *
-lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8 len, u8 tag)
+lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8 len, u16 tag)
{
struct lowpan_fragment *frame;
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 3/4] 6lowpan: the two bytes of u16 tag needs to be stored/accessed the other way around
From: Tony Cheneau @ 2012-06-11 4:39 UTC (permalink / raw)
To: netdev, linux-zigbee-devel; +Cc: alex.bluesman.smirnov
Or else, tag values, as displayed with a trafic analyser, such a
Wireshark, are not properly displayed (e.g. 0x01 00 insted of 0x00 01,
and so on). ---
net/ieee802154/6lowpan.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index af4f29b..af2f12e 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -307,7 +307,7 @@ static u16 lowpan_fetch_skb_u16(struct sk_buff *skb)
BUG_ON(!pskb_may_pull(skb, 2));
- ret = skb->data[0] | (skb->data[1] << 8);
+ ret = (skb->data[0] << 8) | skb->data[1];
skb_pull(skb, 2);
return ret;
}
@@ -1002,8 +1002,8 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
/* first fragment header */
head[0] = LOWPAN_DISPATCH_FRAG1 | (payload_length & 0x7);
head[1] = (payload_length >> 3) & 0xff;
- head[2] = tag & 0xff;
- head[3] = tag >> 8;
+ head[2] = tag >> 8;
+ head[3] = tag & 0xff;
err = lowpan_fragment_xmit(skb, head, header_length, 0, 0);
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 1/4] 6lowpan: Fix in UDP uncompression function when a null pointer gets dereferenced
From: Tony Cheneau @ 2012-06-11 4:38 UTC (permalink / raw)
To: netdev, linux-zigbee-devel; +Cc: alex.bluesman.smirnov
When a UDP packet gets fragmented, a crash will occur during
reassembly.
skb->transport_header is not set during earlier period of fragment
reassembly. As a consequence, calll to udp_hdr() return NULL and uh
(which is NULL) gets dereferenced without much test.
I will post a patch later that will set skb->transport_header
correctly in lowpan_process_data(), so that
lowpan_uncompress_udp_header() behave as intended.
---
net/ieee802154/6lowpan.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 32eb417..a52e795 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -317,6 +317,9 @@ lowpan_uncompress_udp_header(struct sk_buff *skb)
{
struct udphdr *uh = udp_hdr(skb);
u8 tmp;
+
+ if (!uh)
+ goto err;
tmp = lowpan_fetch_skb_u8(skb);
--
1.7.3.4
^ permalink raw reply related
* [PATCH net-next 4/4] 6lowpan: len field is not stored and accessed properly
From: Tony Cheneau @ 2012-06-11 4:40 UTC (permalink / raw)
To: netdev, linux-zigbee-devel; +Cc: alex.bluesman.smirnov
Lenght field should be encoded (and accessed) the other way around.
As it is currently written, it could lead to interroperability issues.
Also, I rewrote the code so that iphc0 argument of
lowpan_alloc_new_frame could be removed.
---
net/ieee802154/6lowpan.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index af2f12e..b400156 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -654,7 +654,7 @@ static void lowpan_fragment_timer_expired(unsigned
long entry_addr) }
static struct lowpan_fragment *
-lowpan_alloc_new_frame(struct sk_buff *skb, u8 iphc0, u8 len, u16 tag)
+lowpan_alloc_new_frame(struct sk_buff *skb, u16 len, u16 tag)
{
struct lowpan_fragment *frame;
@@ -665,7 +665,7 @@ lowpan_alloc_new_frame(struct sk_buff *skb, u8
iphc0, u8 len, u16 tag)
INIT_LIST_HEAD(&frame->list);
- frame->length = (iphc0 & 7) | (len << 3);
+ frame->length = len;
frame->tag = tag;
/* allocate buffer for frame assembling */
@@ -721,13 +721,17 @@ lowpan_process_data(struct sk_buff *skb)
case LOWPAN_DISPATCH_FRAGN:
{
struct lowpan_fragment *frame;
- u8 len, offset;
- u16 tag;
+ /* slen stores the rightmost 8 bits of the 11 bits
length */
+ u8 slen, offset;
+ u16 len, tag;
bool found = false;
- len = lowpan_fetch_skb_u8(skb); /* frame length */
+ slen = lowpan_fetch_skb_u8(skb); /* frame length */
tag = lowpan_fetch_skb_u16(skb);
+ /* adds the 3 MSB to the 8 LSB to retrieve the 11 bits
length */
+ len = ((iphc0 & 7) << 8) | slen;
+
/*
* check if frame assembling with the same tag is
* already in progress
@@ -742,7 +746,7 @@ lowpan_process_data(struct sk_buff *skb)
/* alloc new frame structure */
if (!found) {
- frame = lowpan_alloc_new_frame(skb, iphc0,
len, tag);
+ frame = lowpan_alloc_new_frame(skb, len, tag);
if (!frame)
goto unlock_and_drop;
}
@@ -1000,8 +1004,8 @@ lowpan_skb_fragmentation(struct sk_buff *skb)
tag = fragment_tag++;
/* first fragment header */
- head[0] = LOWPAN_DISPATCH_FRAG1 | (payload_length & 0x7);
- head[1] = (payload_length >> 3) & 0xff;
+ head[0] = LOWPAN_DISPATCH_FRAG1 | ((payload_length >> 8) &
0x7);
+ head[1] = payload_length & 0xff;
head[2] = tag >> 8;
head[3] = tag & 0xff;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] dummy: fix rcu_sched self-detected stalls
From: David Miller @ 2012-06-11 5:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1339239546.6001.177.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 09 Jun 2012 12:59:06 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Trying to "modprobe dummy numdummies=30000" triggers :
>
> INFO: rcu_sched self-detected stall on CPU { 8} (t=60000 jiffies)
>
> After this splat, RTNL is locked and reboot is needed.
>
> We must call cond_resched() to avoid this, even holding RTNL.
>
> Also remove the ~32767 limit on number of dummies (PAGE_SIZE*8)
>
> Tested with "modprobe dummy numdummies=128000"
> (it took ~12 minutes, because of sysfs)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I'm all for the cond_resched() change, but the name optimization
belongs generically in net/core/dev.c not in specific drivers.
So, please submit this cond_resched() fix first then we can work
on the naming performance issue.
Thanks.
^ permalink raw reply
* [PATCH] net: Reorder initialization in ip_route_output to fix gcc warning
From: Roland Dreier @ 2012-06-11 6:05 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Roland Dreier
From: Roland Dreier <roland@purestorage.com>
If I build with W=1, for every file that includes <net/route.h>, I get the warning
include/net/route.h: In function 'ip_route_output':
include/net/route.h:135:3: warning: initialized field overwritten [-Woverride-init]
include/net/route.h:135:3: warning: (near initialization for 'fl4') [-Woverride-init]
(This is with "gcc (Debian 4.6.3-1) 4.6.3")
A fix seems pretty trivial: move the initialization of .flowi4_tos
earlier. As far as I can tell, this has no effect on code generation.
Signed-off-by: Roland Dreier <roland@purestorage.com>
---
include/net/route.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/route.h b/include/net/route.h
index ed2b78e..9870546 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -130,9 +130,9 @@ static inline struct rtable *ip_route_output(struct net *net, __be32 daddr,
{
struct flowi4 fl4 = {
.flowi4_oif = oif,
+ .flowi4_tos = tos,
.daddr = daddr,
.saddr = saddr,
- .flowi4_tos = tos,
};
return ip_route_output_key(net, &fl4);
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] net: Reorder initialization in ip_route_output to fix gcc warning
From: David Miller @ 2012-06-11 6:44 UTC (permalink / raw)
To: roland; +Cc: netdev, roland
In-Reply-To: <1339394724-28296-1-git-send-email-roland@kernel.org>
From: Roland Dreier <roland@kernel.org>
Date: Sun, 10 Jun 2012 23:05:24 -0700
> From: Roland Dreier <roland@purestorage.com>
>
> If I build with W=1, for every file that includes <net/route.h>, I get the warning
>
> include/net/route.h: In function 'ip_route_output':
> include/net/route.h:135:3: warning: initialized field overwritten [-Woverride-init]
> include/net/route.h:135:3: warning: (near initialization for 'fl4') [-Woverride-init]
>
> (This is with "gcc (Debian 4.6.3-1) 4.6.3")
>
> A fix seems pretty trivial: move the initialization of .flowi4_tos
> earlier. As far as I can tell, this has no effect on code generation.
>
> Signed-off-by: Roland Dreier <roland@purestorage.com>
I can't figure out what it is actually warning about, can you?
^ permalink raw reply
* Re: [PATCH] net: Reorder initialization in ip_route_output to fix gcc warning
From: Roland Dreier @ 2012-06-11 7:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120610.234411.850948486629299757.davem@davemloft.net>
> I can't figure out what it is actually warning about, can you?
I think gcc thinks it already initialized the __fl_common struct
once when it hits the .flowi4_oif initializer (which expands to
__fl_common.flowic_oif), and then having the .daddr / .saddr
initializers makes it thinks its done with that structure.
So it thinks it's initializing __fl_common.flowic_tos to 0, and
then the .flowi4_tos initializer comes along as a surprise.
Hmm, looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52880
which is fixed after gcc 4.7.0. I think it's probably worth working
around this gcc issue, since this makes W=1 way noisier in
my build.
- R.
^ permalink raw reply
* Re: [PATCH] net: Reorder initialization in ip_route_output to fix gcc warning
From: David Miller @ 2012-06-11 7:05 UTC (permalink / raw)
To: roland; +Cc: netdev
In-Reply-To: <CAG4TOxNpw0BAWPK3Zde_mThTvY-ho+Ce_aau3DoLc-0TRFq3PQ@mail.gmail.com>
From: Roland Dreier <roland@kernel.org>
Date: Mon, 11 Jun 2012 00:00:51 -0700
>> I can't figure out what it is actually warning about, can you?
>
> I think gcc thinks it already initialized the __fl_common struct
> once when it hits the .flowi4_oif initializer (which expands to
> __fl_common.flowic_oif), and then having the .daddr / .saddr
> initializers makes it thinks its done with that structure.
>
> So it thinks it's initializing __fl_common.flowic_tos to 0, and
> then the .flowi4_tos initializer comes along as a surprise.
>
> Hmm, looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52880
> which is fixed after gcc 4.7.0. I think it's probably worth working
> around this gcc issue, since this makes W=1 way noisier in
> my build.
I suspected it was a compiler bug :-)
Anyways, agreed, applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox