* WARNING at local_bh_enable while tcp_retransmit
From: Ilya Loginov @ 2010-12-07 15:23 UTC (permalink / raw)
To: netdev; +Cc: davem
Hi, I am working on some network drivers.
First one is raw netdevice for RapidIO packets. Second one is
Ethernet network device that encapsulates Ethernet traffic into RapidIO
messages.
Ethernet device changes skb->dev to RapidIO device, calls
RapidIO create_header and calls dev_queue_xmit on skb.
All works well for linear skb's but I have trouble with
multi-fragment skb's when frags have bad alignment. In that case my
controller RapidIO fails to transmit packets. While a bit internal tx
queue with descriptors of underlying RapidIO device overflows and it
returns NETDEV_TX_BUSY in start_xmit.
TCP stack retransmits packets after timeout and I gets this:
------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable+0x150/0x158()
Modules linked in: rioth rsmp k128 [last unloaded: k128]
Call Trace:
[<ffffffff80022170>] dump_stack+0x8/0x48
[<ffffffff800518e8>] warn_slowpath_common+0x90/0xb8
[<ffffffff80059ca0>] local_bh_enable+0x150/0x158
[<ffffffff80303f04>] dev_queue_xmit+0x55c/0x730
[<c0000000000591b0>] rio_send+0x1b0/0x380 [rsmp] <- Stack over RapidIO device (similar to can)
[<c000000000068364>] rioth_start_xmit+0x74/0x88 [rioth] <- Ethernet over RapidIO
[<ffffffff80303620>] dev_hard_start_xmit+0x350/0x578
[<ffffffff8031cff4>] sch_direct_xmit+0x214/0x3a8
[<ffffffff80303e20>] dev_queue_xmit+0x478/0x730
[<ffffffff80332ba8>] ip_finish_output+0x168/0x408
[<ffffffff803312ec>] ip_local_out+0x3c/0x58
[<ffffffff80331bf0>] ip_queue_xmit+0x230/0x4a0
[<ffffffff8034bce0>] tcp_transmit_skb+0x4a8/0xaa0
[<ffffffff8034dfb8>] tcp_retransmit_skb+0x260/0x698
[<ffffffff803504d8>] tcp_retransmit_timer+0x110/0x700
[<ffffffff80350cf0>] tcp_write_timer+0x228/0x278
[<ffffffff80062584>] run_timer_softirq+0x174/0x398
[<ffffffff80059804>] __do_softirq+0x174/0x270
[<ffffffff800599c8>] do_softirq+0xc8/0xf8
[<ffffffff80059d7c>] irq_exit+0x7c/0x88
[<ffffffff80001400>] ret_from_irq+0x0/0x4
[<ffffffff8001ed4c>] cpu_idle+0x1c/0xa0
[<ffffffff8049bc80>] start_kernel+0x518/0x628
---[ end trace cc7486cd1e47e9db ]---
I watched bonding, but I could not realize why it didn't get
same warning. It use very similar scheme of work.
Do you have any ideas?
--
Ilya Loginov <isloginov@gmail.com>
^ permalink raw reply
* Re: bugs/regressions: report in LKML or in bugzilla?
From: Eric Dumazet @ 2010-12-07 16:12 UTC (permalink / raw)
To: Martin Steigerwald; +Cc: linux-kernel, netdev
In-Reply-To: <201012071639.58884.Martin@lichtvoll.de>
Le mardi 07 décembre 2010 à 16:39 +0100, Martin Steigerwald a écrit :
> A participant of a linux performance training I hold found a bug with
> window scaling which did not receive any reply as well:
>
> Bug 20312 - System freeze with multiples of 32 in
> /proc/sys/net/ipv4/tcp_adv_win_scale
> https://bugzilla.kernel.org/show_bug.cgi?id=20312
>
User bug ?
Documentation/networking/ip-sysctl.txt
tcp_adv_win_scale - INTEGER
Count buffering overhead as bytes/2^tcp_adv_win_scale
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
if it is <= 0.
Default: 2
Given we use 32bit numbers, using values outside of [-31 ... 31] makes litle sense.
We could add sysctl range limit, but user should not mess with
/proc/sys/net/ipv4/parameters unless he knows what he is doing ?
Almost all /proc/sys/net/ipv4/parameters dont have range limits and unexpected
results with insane values feeded.
An other way to freeze a machine being root is :
halt
^ permalink raw reply
* Fwd: usbnet: Recursive Locking bug ?
From: Neil Jones @ 2010-12-07 16:15 UTC (permalink / raw)
To: netdev, linux-usb
In-Reply-To: <AANLkTi=Dzc37qxXC0oK48pnuWss9gHJE3ARDEUGfi7QA@mail.gmail.com>
> But what makes sure that the URB unlinked in unlink_urbs() stays a valid pointer?
> The bottom half may run and free the URB.
I think it may be safe to remove the lock as we are walking a list of
SKBs not URBs,
the BH can remove SKB's from the list but we are doing a safe list walk.
+ the BH takse the list lock when it does the remove.
I could be wrong though?
On Tue, Dec 7, 2010 at 2:54 PM, Oliver Neukum <oneukum@suse.de> wrote:
> Am Dienstag, 7. Dezember 2010, 15:08:43 schrieb Neil Jones:
>> I think this is due to unlink_urbs():
>
> Definitely.
>
>> static int unlink_urbs (struct usbnet *dev, struct sk_buff_head *q)
>> {
>> unsigned long flags;
>> struct sk_buff *skb, *skbnext;
>> int count = 0;
>>
>> spin_lock_irqsave (&q->lock, flags);
>> skb_queue_walk_safe(q, skb, skbnext) {
>> struct skb_data *entry;
>> struct urb *urb;
>> int retval;
>>
>> entry = (struct skb_data *) skb->cb;
>> urb = entry->urb;
>>
>> // during some PM-driven resume scenarios,
>> // these (async) unlinks complete immediately
>> retval = usb_unlink_urb (urb);
>> if (retval != -EINPROGRESS && retval != 0)
>> netdev_dbg(dev->net, "unlink urb err, %d\n", retval);
>> else
>> count++;
>> }
>> spin_unlock_irqrestore (&q->lock, flags);
>> return count;
>> }
>>
>> I dont think this should hold the list lock when calling usb_unlink_urb (urb).
>> The completion for the URBs takes the lock as required in its bottom half:
>
> But what makes sure that the URB unlinked in unlink_urbs() stays a valid pointer?
> The bottom half may run and free the URB.
>
> Regards
> Oliver
>
^ permalink raw reply
* Re: Fwd: usbnet: Recursive Locking bug ?
From: Alan Stern @ 2010-12-07 16:46 UTC (permalink / raw)
To: Neil Jones; +Cc: netdev, linux-usb
In-Reply-To: <AANLkTi=VB0Kt=2c1C1b-Ps8x_zA5Tnf+tfHjvO8gWgm8@mail.gmail.com>
On Tue, 7 Dec 2010, Neil Jones wrote:
> > But what makes sure that the URB unlinked in unlink_urbs() stays a valid pointer?
> > The bottom half may run and free the URB.
>
> I think it may be safe to remove the lock as we are walking a list of
> SKBs not URBs,
> the BH can remove SKB's from the list but we are doing a safe list walk.
> + the BH takse the list lock when it does the remove.
>
> I could be wrong though?
A simple answer to Oliver's question is to take a reference to the
URB while still holding the lock, then release the lock before calling
usb_unlink_urb(), then drop the reference to the URB.
Of course, this also requires you to restart the loop from the
beginning after each unlink, and it means you need to have a way to
recognize when an URB has already been unlinked.
Alan Stern
^ permalink raw reply
* Re: biosdevname v0.3.2
From: Ben Hutchings @ 2010-12-07 18:16 UTC (permalink / raw)
To: Matt Domsch
Cc: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Colin Watson
In-Reply-To: <20101206140649.GA13628@auslistsprd01.us.dell.com>
On Mon, 2010-12-06 at 08:06 -0600, Matt Domsch wrote:
> Bugfix update to biosdevname, now version 0.3.2.
>
> The legacy code for reading the PCI IRQ Routing Table ($PIR) and the
> PCMCIA information has been removed. This means biosdevname will only
> report BIOS-provided names if your system has SMBIOS 2.6 or higher and
> has the information in Type 9 or Type 41. This is in preparation for
> widespread use, and will keep biosdevname from suggesting names on
> systems that are well into or beyond their useful lifetime and
> introducing an unexpected change of behavior on them. Dell PowerEdge
> 10G and newer, HP ProLiant G6 and newer are known to have SMBIOS 2.6,
> as do a number of desktop, laptop, and netbook-class systems as
> reported on the fedora-devel mailing list.
>
> This release also provides correct names for Intel and Broadcom
> quad-port GigE cards that I've tried. Format is pci<slot>#<port>.
[...]
I tried this on a Supermicro board here, which doesn't have this
information. eth0 and eth1 are LOM ports, eth2 and eth3 are on a NIC.
The debug output is:
BIOS device:
Kernel name: eth2
Assigned MAC : 00:0F:53:01:41:14
Driver: sfc
Driver version: 3.0
Firmware version: 3.0.8.2217
Bus Info: 0000:01:00.0
PCI name : 0000:01:00.0
PCI Slot : Unknown
Index in slot: 7
BIOS device:
Kernel name: eth3
Assigned MAC : 00:0F:53:01:41:15
Driver: sfc
Driver version: 3.0
Firmware version: 3.0.8.2217
Bus Info: 0000:01:00.1
PCI name : 0000:01:00.1
PCI Slot : Unknown
Index in slot: 8
BIOS device:
Kernel name: eth0
Permanant MAC: 00:30:48:90:81:9E
Assigned MAC : 00:30:48:90:81:9E
Driver: e1000e
Driver version: 1.2.7-k2
Firmware version: 0.15-4
Bus Info: 0000:0d:00.0
PCI name : 0000:0d:00.0
PCI Slot : Unknown
Index in slot: 9
BIOS device:
Kernel name: eth1
Permanant MAC: 00:30:48:90:81:9F
Assigned MAC : 00:30:48:90:81:9F
Driver: e1000e
Driver version: 1.2.7-k2
Firmware version: 0.5-7
Bus Info: 0000:0e:00.0
PCI name : 0000:0e:00.0
PCI Slot : Unknown
Index in slot: 10
It appears that 'unknown slot' is treated as a specific slot and all
devices with an unknown slot are given unique indices. Perhaps this
doesn't matter in the end, since no name is generated when the slot is
unknown.
However, the 2 NIC ports do have their own indices (specified with the
dev_id attribute) and it should be possible to distinguish slots by
PCI/PCIe topology even though the name given won't correspond to any
markings on the motherboard.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: biosdevname v0.3.2
From: Matt Domsch @ 2010-12-07 18:19 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Colin Watson
In-Reply-To: <1291745782.21627.6.camel@bwh-desktop>
On Tue, Dec 07, 2010 at 06:16:22PM +0000, Ben Hutchings wrote:
> It appears that 'unknown slot' is treated as a specific slot and all
> devices with an unknown slot are given unique indices. Perhaps this
> doesn't matter in the end, since no name is generated when the slot is
> unknown.
Yes on all counts.
> However, the 2 NIC ports do have their own indices (specified with the
> dev_id attribute) and it should be possible to distinguish slots by
> PCI/PCIe topology even though the name given won't correspond to any
> markings on the motherboard.
Tell me more about the dev_id attribute. I'm happy to use it, but I
don't understand the rules around populating it.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Breno Leitao @ 2010-12-07 18:34 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <1291697844.17494.260.camel@Joe-Laptop>
On 12/07/2010 02:57 AM, Joe Perches wrote:
> I'll get this sorted out after the merges are done.
> Bruno? I hope you don't mind testing again later.
It's ok for me.
Thanks
^ permalink raw reply
* Re: biosdevname v0.3.2
From: Ben Hutchings @ 2010-12-07 18:41 UTC (permalink / raw)
To: Matt Domsch
Cc: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Colin Watson
In-Reply-To: <20101207181910.GA2643@auslistsprd01.us.dell.com>
On Tue, 2010-12-07 at 12:19 -0600, Matt Domsch wrote:
> On Tue, Dec 07, 2010 at 06:16:22PM +0000, Ben Hutchings wrote:
> > It appears that 'unknown slot' is treated as a specific slot and all
> > devices with an unknown slot are given unique indices. Perhaps this
> > doesn't matter in the end, since no name is generated when the slot is
> > unknown.
>
> Yes on all counts.
>
> > However, the 2 NIC ports do have their own indices (specified with the
> > dev_id attribute) and it should be possible to distinguish slots by
> > PCI/PCIe topology even though the name given won't correspond to any
> > markings on the motherboard.
>
> Tell me more about the dev_id attribute. I'm happy to use it, but I
> don't understand the rules around populating it.
As I understand it, dev_id is supposed to distinguish net devices
corresponding to multiple ports on a single network controller.
However, a value of 0 could mean either 'unspecified' or 'first port' so
you would have to verify that multiple net devices for the same slot
have unique dev_id values before taking them into account.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* SEASONAL FINANCIAL LENDER
From: PRIVATE HOME LENDER INC @ 2010-12-07 18:52 UTC (permalink / raw)
To: saff
apply for a loan to establish your business.
our interest is very affordable and our loan process is very fast as well as
percentage rate of 2.5% yearly from $5 000.00 min To $100 000 000.00 max
get back to us on this information below
name
phone
duration
address
amount
regards
private home lender inc
phlmikejackson@gmail.com
mr mike jackson
^ permalink raw reply
* Re: [PATCH 0/4] ath: logging message conversion
From: John W. Linville @ 2010-12-07 19:05 UTC (permalink / raw)
To: Joe Perches
Cc: Luis R. Rodriguez, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath5k-devel-juf53994utBLZpfksSYvnA,
ath9k-devel-juf53994utBLZpfksSYvnA, Peter Stuge, Felix Fietkau,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1291333543.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
On Thu, Dec 02, 2010 at 07:12:34PM -0800, Joe Perches wrote:
> ath_print is misleading as it's only used with CONFIG_ATH_DEBUG.
>
> Add and use the more normal <subsystem>_printk and <subsystem>_<level>
> printk equivalents. (ath_printk and ath_<level>)
>
> Fix various defects in the current uses of ath_print formats
> and arguments: Unnecessary casts, missing newlines, multiple
> prints, and 1 loop which can exceed array bounds.
>
> Bundled and integrated the individual patches into a single patch series.
>
> Joe Perches (4):
> ath: Add and use ath_printk and ath_<level>
> ath: Convert ath_print(.., ATH_DBG_FATAL to ath_err
> ath: Convert ath_print to ath_dbg
> ath: Fix ath_dbg access beyond array bound
Is the Atheros crew happy with this series? They didn't seem to like
the original patches very much...
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: weird network problem - stalls, reload works
From: Jarek Poplawski @ 2010-12-07 19:20 UTC (permalink / raw)
To: Michael Tokarev; +Cc: netdev
In-Reply-To: <4CFC17B8.4050908@msgid.tls.msk.ru>
Michael Tokarev wrote:
> Hello.
Hi,
>
> I've a weird networking problem here, which I'm
> trying to hunt for some time.
...
> So I'm quite stuck here, and don't know what to do next.
> My next bet is to try another motherboard, in a hope that
> this is just some broken interrupt controller, but it is
> a bit too unreal...
>
> Any hints on what to try are greatly apprecated...
You might try the usual stuff like in linux-2.6/REPORTING-BUGS ;-)
Plus maybe some debugging turned on in the config (DMA?) and
driver (s/#if 0/#if 1/ around line 69 in forcedeth.c). Btw, it
seems there should be some watchdog traces in logs around those
stalled pings.
Cheers,
Jarek P.
^ permalink raw reply
* Re: [PATCH 0/4] ath: logging message conversion
From: Luis R. Rodriguez @ 2010-12-07 19:26 UTC (permalink / raw)
To: John W. Linville
Cc: Joe Perches, Luis Rodriguez, linux-wireless@vger.kernel.org,
ath5k-devel@venema.h4ckr.net, ath9k-devel@venema.h4ckr.net,
Peter Stuge, Felix Fietkau, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20101207190528.GD2700@tuxdriver.com>
On Tue, Dec 07, 2010 at 11:05:28AM -0800, John W. Linville wrote:
> On Thu, Dec 02, 2010 at 07:12:34PM -0800, Joe Perches wrote:
> > ath_print is misleading as it's only used with CONFIG_ATH_DEBUG.
> >
> > Add and use the more normal <subsystem>_printk and <subsystem>_<level>
> > printk equivalents. (ath_printk and ath_<level>)
> >
> > Fix various defects in the current uses of ath_print formats
> > and arguments: Unnecessary casts, missing newlines, multiple
> > prints, and 1 loop which can exceed array bounds.
> >
> > Bundled and integrated the individual patches into a single patch series.
> >
> > Joe Perches (4):
> > ath: Add and use ath_printk and ath_<level>
> > ath: Convert ath_print(.., ATH_DBG_FATAL to ath_err
> > ath: Convert ath_print to ath_dbg
> > ath: Fix ath_dbg access beyond array bound
>
> Is the Atheros crew happy with this series? They didn't seem to like
> the original patches very much...
Its fine now that Joe has addressed some more important items.
But I'd like for the patches to be applied last of all pending
patches :)
Luis
^ permalink raw reply
* [PATCH] X.25: decrement netdev reference counts on unload
From: Apollon Oikonomopoulos @ 2010-12-07 19:43 UTC (permalink / raw)
To: netdev
Hello,
We came across this bug when we accidentally loaded and unloaded the x25
kernel module on a host with KVM virtual machines. All subsequent
attempts to stop a KVM instance resulted in the KVM process entering D
state. Reproducing this behaviour can be done in the following way:
1. modprobe x25
2. tunctl && ifconfig tap0 up
3. rmmod x25
4. tunctl -d tap0 (hangs)
A patch follows - we don't use X.25 ourselves so I'm not sure it won't
panic someone's system.
Regards,
Apollon
PS: I am not subscribed to the list, so please copy any replies to my
address. Thanks!
----
x25 does not decrement the network device reference counts on module unload.
Thus unregistering any pre-existing interface after unloading the x25 module
hangs and results in
unregister_netdevice: waiting for tap0 to become free. Usage count = 1
This patch decrements the reference counts of all interfaces in x25_link_free,
the way it is already done in x25_link_device_down for NETDEV_DOWN events.
Signed-off-by: Apollon Oikonomopoulos <apollon@noc.grnet.gr>
---
net/x25/x25_link.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/x25/x25_link.c b/net/x25/x25_link.c
index 73e7b95..b25c646 100644
--- a/net/x25/x25_link.c
+++ b/net/x25/x25_link.c
@@ -394,6 +394,7 @@ void __exit x25_link_free(void)
list_for_each_safe(entry, tmp, &x25_neigh_list) {
nb = list_entry(entry, struct x25_neigh, node);
__x25_remove_neigh(nb);
+ dev_put(nb->dev);
}
write_unlock_bh(&x25_neigh_list_lock);
}
--
1.7.1
^ permalink raw reply related
* Re: [stable] [PATCH 2.6.36 stable] vlan: Avoid hwaccel vlan packets when vid not used.
From: Greg KH @ 2010-12-07 19:50 UTC (permalink / raw)
To: Jesse Gross; +Cc: stable, netdev, David Miller
In-Reply-To: <1289251381-6671-1-git-send-email-jesse@nicira.com>
On Mon, Nov 08, 2010 at 01:23:01PM -0800, Jesse Gross wrote:
> Normally hardware accelerated vlan packets are quickly dropped if
> there is no corresponding vlan device configured. The one exception
> is promiscuous mode, where we allow all of these packets through so
> they can be picked up by tcpdump. However, this behavior causes a
> crash if we actually try to receive these packets. This fixes that
> crash by ignoring packets with vids not corresponding to a configured
> device in the vlan hwaccel routines and then dropping them before they
> get to consumers in the network stack.
>
> This patch applies only to 2.6.36 stable. The problem was introduced
> in that release and is already fixed by larger changes to the vlan
> code in 2.6.37.
Applied, thanks.
greg k-h
^ permalink raw reply
* Re: [stable] [PATCH 2.6.36 stable] vlan: Avoid hwaccel vlan packets when vid not used.
From: Eric Dumazet @ 2010-12-07 20:50 UTC (permalink / raw)
To: Greg KH; +Cc: Jesse Gross, stable, netdev, David Miller
In-Reply-To: <20101207195019.GP13189@kroah.com>
Le mardi 07 décembre 2010 à 11:50 -0800, Greg KH a écrit :
> On Mon, Nov 08, 2010 at 01:23:01PM -0800, Jesse Gross wrote:
> > Normally hardware accelerated vlan packets are quickly dropped if
> > there is no corresponding vlan device configured. The one exception
> > is promiscuous mode, where we allow all of these packets through so
> > they can be picked up by tcpdump. However, this behavior causes a
> > crash if we actually try to receive these packets. This fixes that
> > crash by ignoring packets with vids not corresponding to a configured
> > device in the vlan hwaccel routines and then dropping them before they
> > get to consumers in the network stack.
> >
> > This patch applies only to 2.6.36 stable. The problem was introduced
> > in that release and is already fixed by larger changes to the vlan
> > code in 2.6.37.
>
> Applied, thanks.
>
Oh well, which version ?
A new version of the patch was submitted 6 days ago .
http://patchwork.ozlabs.org/patch/73791/
Thanks
^ permalink raw reply
* Re: WARNING at local_bh_enable while tcp_retransmit
From: Jarek Poplawski @ 2010-12-07 20:56 UTC (permalink / raw)
To: Ilya Loginov; +Cc: netdev, davem
In-Reply-To: <20101207182308.664e171d.isloginov@gmail.com>
Ilya Loginov wrote:
> Hi, I am working on some network drivers.
...
> I watched bonding, but I could not realize why it didn't get
> same warning. It use very similar scheme of work.
>
> Do you have any ideas?
Hi, isn't any of your drivers disabling irqs on this path?
(If no, what is the kernel version?)
Jarek P.
^ permalink raw reply
* Re: bugs/regressions: report in LKML or in bugzilla?
From: Ben Hutchings @ 2010-12-07 21:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Martin Steigerwald, linux-kernel, netdev
In-Reply-To: <1291738321.2695.338.camel@edumazet-laptop>
On Tue, 2010-12-07 at 17:12 +0100, Eric Dumazet wrote:
> Le mardi 07 décembre 2010 à 16:39 +0100, Martin Steigerwald a écrit :
>
> > A participant of a linux performance training I hold found a bug with
> > window scaling which did not receive any reply as well:
> >
> > Bug 20312 - System freeze with multiples of 32 in
> > /proc/sys/net/ipv4/tcp_adv_win_scale
> > https://bugzilla.kernel.org/show_bug.cgi?id=20312
> >
>
> User bug ?
>
> Documentation/networking/ip-sysctl.txt
>
> tcp_adv_win_scale - INTEGER
> Count buffering overhead as bytes/2^tcp_adv_win_scale
> (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
> if it is <= 0.
> Default: 2
>
> Given we use 32bit numbers, using values outside of [-31 ... 31] makes litle sense.
>
> We could add sysctl range limit, but user should not mess with
> /proc/sys/net/ipv4/parameters unless he knows what he is doing ?
[...]
For mere humans, the range is not quite os obvious. Which is why this
has been fixed in net-2.6 (as noted on that bug report now).
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [stable] [PATCH 2.6.36 stable] vlan: Avoid hwaccel vlan packets when vid not used.
From: Greg KH @ 2010-12-07 21:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Jesse Gross, stable, David Miller
In-Reply-To: <1291755026.5324.3.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
On Tue, Dec 07, 2010 at 09:50:26PM +0100, Eric Dumazet wrote:
> Le mardi 07 décembre 2010 à 11:50 -0800, Greg KH a écrit :
> > On Mon, Nov 08, 2010 at 01:23:01PM -0800, Jesse Gross wrote:
> > > Normally hardware accelerated vlan packets are quickly dropped if
> > > there is no corresponding vlan device configured. The one exception
> > > is promiscuous mode, where we allow all of these packets through so
> > > they can be picked up by tcpdump. However, this behavior causes a
> > > crash if we actually try to receive these packets. This fixes that
> > > crash by ignoring packets with vids not corresponding to a configured
> > > device in the vlan hwaccel routines and then dropping them before they
> > > get to consumers in the network stack.
> > >
> > > This patch applies only to 2.6.36 stable. The problem was introduced
> > > in that release and is already fixed by larger changes to the vlan
> > > code in 2.6.37.
> >
> > Applied, thanks.
> >
>
> Oh well, which version ?
>
> A new version of the patch was submitted 6 days ago .
>
> http://patchwork.ozlabs.org/patch/73791/
I applied the one below.
If that is incorrect, please send me the correct one.
thanks,
greg k-h
[-- Attachment #2: vlan-avoid-hwaccel-vlan-packets-when-vid-not-used.patch --]
[-- Type: text/x-patch, Size: 2482 bytes --]
>From jesse@nicira.com Tue Dec 7 11:49:39 2010
From: Jesse Gross <jesse@nicira.com>
Date: Mon, 8 Nov 2010 13:23:01 -0800
Subject: [stable] [PATCH 2.6.36 stable] vlan: Avoid hwaccel vlan packets when vid not used.
To: stable@kernel.org
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>
Message-ID: <1289251381-6671-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
[This patch applies only to 2.6.36 stable. The problem was introduced
in that release and is already fixed by larger changes to the vlan
code in 2.6.37.]
Normally hardware accelerated vlan packets are quickly dropped if
there is no corresponding vlan device configured. The one exception
is promiscuous mode, where we allow all of these packets through so
they can be picked up by tcpdump. However, this behavior causes a
crash if we actually try to receive these packets. This fixes that
crash by ignoring packets with vids not corresponding to a configured
device in the vlan hwaccel routines and then dropping them before they
get to consumers in the network stack.
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Nikola Ciprich <extmaillist@linuxbox.cz>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: David Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/8021q/vlan_core.c | 3 +++
net/core/dev.c | 13 +++++++++++++
2 files changed, 16 insertions(+)
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -43,6 +43,9 @@ int vlan_hwaccel_do_receive(struct sk_bu
struct net_device *dev = skb->dev;
struct vlan_rx_stats *rx_stats;
+ if (unlikely(!is_vlan_dev(dev)))
+ return 0;
+
skb->dev = vlan_dev_info(dev)->real_dev;
netif_nit_deliver(skb);
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2891,6 +2891,19 @@ static int __netif_receive_skb(struct sk
ncls:
#endif
+ /* If we got this far with a hardware accelerated VLAN tag, it means
+ * that we were put in promiscuous mode but nobody is interested in
+ * this vid. Drop the packet now to prevent it from getting propagated
+ * to other parts of the stack that won't know how to deal with packets
+ * tagged in this manner.
+ */
+ if (unlikely(vlan_tx_tag_present(skb))) {
+ if (pt_prev)
+ ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+ kfree_skb(skb);
+ goto out;
+ }
+
/* Handle special case of bridge or macvlan */
rx_handler = rcu_dereference(skb->dev->rx_handler);
if (rx_handler) {
^ permalink raw reply
* Re: bugs/regressions: report in LKML or in bugzilla?
From: Martin Steigerwald @ 2010-12-07 21:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1291738321.2695.338.camel@edumazet-laptop>
[-- Attachment #1: Type: Text/Plain, Size: 2059 bytes --]
Am Dienstag 07 Dezember 2010 schrieb Eric Dumazet:
> Le mardi 07 décembre 2010 à 16:39 +0100, Martin Steigerwald a écrit :
> > A participant of a linux performance training I hold found a bug with
> > window scaling which did not receive any reply as well:
> >
> > Bug 20312 - System freeze with multiples of 32 in
> > /proc/sys/net/ipv4/tcp_adv_win_scale
> > https://bugzilla.kernel.org/show_bug.cgi?id=20312
>
> User bug ?
Sure, but whats the point?
> Documentation/networking/ip-sysctl.txt
>
> tcp_adv_win_scale - INTEGER
> Count buffering overhead as bytes/2^tcp_adv_win_scale
> (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
> if it is <= 0.
> Default: 2
>
> Given we use 32bit numbers, using values outside of [-31 ... 31] makes
> litle sense.
Granted, it does not make sense. The user tried that on an exercise to
make TCP/IP networking in Linux as slow as possible (to understand why its
fast at all).
Still: Here isn't documented that the kernel freezes when writing a wrong
value in there.
> We could add sysctl range limit, but user should not mess with
> /proc/sys/net/ipv4/parameters unless he knows what he is doing ?
>
> Almost all /proc/sys/net/ipv4/parameters dont have range limits and
> unexpected results with insane values feeded.
Well I disagree. Its a user interface, even tough a root user interface,
that is even writable without writing a program. And as far as I
understand even at least some system calls do some basic sanity checking
on arguments.
If it doesn't cost too much overhead, arguments in there should receive at
least some basic sanity checking.
> An other way to freeze a machine being root is :
>
> halt
It won't freeze the machine. It does a clean halt which reduces the chance
to reduce valuable data in yet unwritten pages.
And here it is documented that this will halt the machine.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: bugs/regressions: report in LKML or in bugzilla?
From: Martin Steigerwald @ 2010-12-07 21:28 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Eric Dumazet, linux-kernel, netdev
In-Reply-To: <1291755776.21627.13.camel@bwh-desktop>
[-- Attachment #1: Type: Text/Plain, Size: 1359 bytes --]
Am Dienstag 07 Dezember 2010 schrieb Ben Hutchings:
> On Tue, 2010-12-07 at 17:12 +0100, Eric Dumazet wrote:
> > Le mardi 07 décembre 2010 à 16:39 +0100, Martin Steigerwald a écrit :
> > > A participant of a linux performance training I hold found a bug
> > > with window scaling which did not receive any reply as well:
> > >
> > > Bug 20312 - System freeze with multiples of 32 in
> > > /proc/sys/net/ipv4/tcp_adv_win_scale
> > > https://bugzilla.kernel.org/show_bug.cgi?id=20312
> >
> > User bug ?
> >
> > Documentation/networking/ip-sysctl.txt
> >
> > tcp_adv_win_scale - INTEGER
> >
> > Count buffering overhead as bytes/2^tcp_adv_win_scale
> > (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
> > if it is <= 0.
> > Default: 2
> >
> > Given we use 32bit numbers, using values outside of [-31 ... 31]
> > makes litle sense.
> >
> > We could add sysctl range limit, but user should not mess with
> > /proc/sys/net/ipv4/parameters unless he knows what he is doing ?
>
> [...]
>
> For mere humans, the range is not quite os obvious. Which is why this
> has been fixed in net-2.6 (as noted on that bug report now).
>
> Ben.
I verified the fix on 2.6.37-rc5.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] tcp: avoid a possible divide by zero
From: Ben Hutchings @ 2010-12-07 21:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Martin Steigerwald, netdev
In-Reply-To: <1291757288.5324.18.camel@edumazet-laptop>
On Tue, 2010-12-07 at 22:28 +0100, Eric Dumazet wrote:
[...]
> Thanks
>
> Great, I feel we are going to fix all sysctls, one by one then :(
>
> lkml removed from Cc
>
>
> [PATCH] tcp: avoid a possible divide by zero
>
> sysctl_tcp_tso_win_divisor might be set to zero while one cpu runs in
> tcp_tso_should_defer(). Make sure we dont allow a divide by zero by
> reading sysctl_tcp_tso_win_divisor once.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/tcp_output.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 05b1ecf..0281223 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1513,6 +1513,7 @@ static int tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb)
> struct tcp_sock *tp = tcp_sk(sk);
> const struct inet_connection_sock *icsk = inet_csk(sk);
> u32 send_win, cong_win, limit, in_flight;
> + int win_divisor;
>
> if (TCP_SKB_CB(skb)->flags & TCPHDR_FIN)
> goto send_now;
> @@ -1544,13 +1545,14 @@ static int tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb)
> if ((skb != tcp_write_queue_tail(sk)) && (limit >= skb->len))
> goto send_now;
>
> - if (sysctl_tcp_tso_win_divisor) {
> + win_divisor = sysctl_tcp_tso_win_divisor;
You need to use ACCESS_ONCE(sysctl_tcp_tso_win_divisor). Otherwise the
compiler may eliminate the local variable and read the global twice.
Ben.
> + if (win_divisor) {
> u32 chunk = min(tp->snd_wnd, tp->snd_cwnd * tp->mss_cache);
>
> /* If at least some fraction of a window is available,
> * just use it.
> */
> - chunk /= sysctl_tcp_tso_win_divisor;
> + chunk /= win_divisor;
> if (limit >= chunk)
> goto send_now;
> } else {
>
>
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] tcp: avoid a possible divide by zero
From: Eric Dumazet @ 2010-12-07 21:28 UTC (permalink / raw)
To: Ben Hutchings, David Miller; +Cc: Martin Steigerwald, netdev
In-Reply-To: <1291755776.21627.13.camel@bwh-desktop>
Le mardi 07 décembre 2010 à 21:02 +0000, Ben Hutchings a écrit :
> On Tue, 2010-12-07 at 17:12 +0100, Eric Dumazet wrote:
> > Le mardi 07 décembre 2010 à 16:39 +0100, Martin Steigerwald a écrit :
> >
> > > A participant of a linux performance training I hold found a bug with
> > > window scaling which did not receive any reply as well:
> > >
> > > Bug 20312 - System freeze with multiples of 32 in
> > > /proc/sys/net/ipv4/tcp_adv_win_scale
> > > https://bugzilla.kernel.org/show_bug.cgi?id=20312
> > >
> >
> > User bug ?
> >
> > Documentation/networking/ip-sysctl.txt
> >
> > tcp_adv_win_scale - INTEGER
> > Count buffering overhead as bytes/2^tcp_adv_win_scale
> > (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
> > if it is <= 0.
> > Default: 2
> >
> > Given we use 32bit numbers, using values outside of [-31 ... 31] makes litle sense.
> >
> > We could add sysctl range limit, but user should not mess with
> > /proc/sys/net/ipv4/parameters unless he knows what he is doing ?
> [...]
>
> For mere humans, the range is not quite os obvious. Which is why this
> has been fixed in net-2.6 (as noted on that bug report now).
>
Thanks
Great, I feel we are going to fix all sysctls, one by one then :(
lkml removed from Cc
[PATCH] tcp: avoid a possible divide by zero
sysctl_tcp_tso_win_divisor might be set to zero while one cpu runs in
tcp_tso_should_defer(). Make sure we dont allow a divide by zero by
reading sysctl_tcp_tso_win_divisor once.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp_output.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 05b1ecf..0281223 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1513,6 +1513,7 @@ static int tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb)
struct tcp_sock *tp = tcp_sk(sk);
const struct inet_connection_sock *icsk = inet_csk(sk);
u32 send_win, cong_win, limit, in_flight;
+ int win_divisor;
if (TCP_SKB_CB(skb)->flags & TCPHDR_FIN)
goto send_now;
@@ -1544,13 +1545,14 @@ static int tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb)
if ((skb != tcp_write_queue_tail(sk)) && (limit >= skb->len))
goto send_now;
- if (sysctl_tcp_tso_win_divisor) {
+ win_divisor = sysctl_tcp_tso_win_divisor;
+ if (win_divisor) {
u32 chunk = min(tp->snd_wnd, tp->snd_cwnd * tp->mss_cache);
/* If at least some fraction of a window is available,
* just use it.
*/
- chunk /= sysctl_tcp_tso_win_divisor;
+ chunk /= win_divisor;
if (limit >= chunk)
goto send_now;
} else {
^ permalink raw reply related
* Re: [PATCH 1/4] ath: Add and use ath_printk and ath_<level>
From: John W. Linville @ 2010-12-07 21:38 UTC (permalink / raw)
To: Joe Perches
Cc: Luis R. Rodriguez, linux-kernel, Peter Stuge, Felix Fietkau,
linux-wireless, netdev
In-Reply-To: <241e75c84fdd26bfae1c7b8806fe64fbac5de627.1291333544.git.joe@perches.com>
On Thu, Dec 02, 2010 at 07:12:35PM -0800, Joe Perches wrote:
> Add ath_printk and ath_<level> similar to
> dev_printk and dev_<level> from device.h
>
> This allows a more gradual rename of ath_print
> to to ath_dbg or perhaps ath_debug.
>
> This basically removes debug.h leaving
> only an #define ath_printk ath_dbg
> there and moving all the ATH_DBG_<foo>
> enums to ath.h
>
> I do not think there's much purpose for struct
> ath_common * being passed to the ath_printk
> functions, but perhaps there might be.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> +#define ATH_DBG_WARN(foo, arg...) WARN(foo, arg)
> +
> +#else
> +
> +static inline __attribute__ ((format (printf, 3, 4))) int
> +ath_dbg(struct ath_common *common, enum ATH_DEBUG dbg_mask,
> + const char *fmt, ...)
> +{
> + return 0;
> +}
> +#define ATH_DBG_WARN(foo, arg) do {} while (0)
Missing the "..." after "arg" -- I fixed it up...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* pull request: sfc-2.6 2010-12-07
From: Ben Hutchings @ 2010-12-07 21:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sf-linux-drivers
The following changes since commit 46bcf14f44d8f31ecfdc8b6708ec15a3b33316d9:
filter: fix sk_filter rcu handling (2010-12-06 09:29:43 -0800)
are available in the git repository at:
git://git.kernel.org/linux/kernel/git/bwh/sfc-2.6.git sfc-2.6.37
(or will be shortly).
These fix bugs introduced in 2.6.37-rc1. Please pull.
Ben.
Ben Hutchings (2):
sfc: Fix crash in legacy onterrupt handler during ring reallocation
sfc: Fix NAPI list corruption during ring reallocation
drivers/net/sfc/efx.c | 43 ++++++++++++++++++++++++++++-------------
drivers/net/sfc/net_driver.h | 2 +
drivers/net/sfc/nic.c | 6 +++++
3 files changed, 37 insertions(+), 14 deletions(-)
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-2.6 1/2] sfc: Fix crash in legacy onterrupt handler during ring reallocation
From: Ben Hutchings @ 2010-12-07 21:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291758047.21627.19.camel@bwh-desktop>
If we are using a legacy interrupt, our IRQ may be shared and our
interrupt handler may be called even though interrupts are disabled on
the NIC. When we change ring sizes, we reallocate the event queue and
the interrupt handler may use an invalid pointer when called for
another device's interrupt.
Maintain a legacy_irq_enabled flag and test that at the top of the
interrupt handler. Note that this problem results from the need to
work around broken INT_ISR0 reads, and does not affect the legacy
interrupt handler for Falcon A1.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/efx.c | 12 ++++++++++--
drivers/net/sfc/net_driver.h | 2 ++
drivers/net/sfc/nic.c | 6 ++++++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/net/sfc/efx.c b/drivers/net/sfc/efx.c
index 05df20e..d06cb74 100644
--- a/drivers/net/sfc/efx.c
+++ b/drivers/net/sfc/efx.c
@@ -335,8 +335,10 @@ void efx_process_channel_now(struct efx_channel *channel)
/* Disable interrupts and wait for ISRs to complete */
efx_nic_disable_interrupts(efx);
- if (efx->legacy_irq)
+ if (efx->legacy_irq) {
synchronize_irq(efx->legacy_irq);
+ efx->legacy_irq_enabled = false;
+ }
if (channel->irq)
synchronize_irq(channel->irq);
@@ -351,6 +353,8 @@ void efx_process_channel_now(struct efx_channel *channel)
efx_channel_processed(channel);
napi_enable(&channel->napi_str);
+ if (efx->legacy_irq)
+ efx->legacy_irq_enabled = true;
efx_nic_enable_interrupts(efx);
}
@@ -1400,6 +1404,8 @@ static void efx_start_all(struct efx_nic *efx)
efx_start_channel(channel);
}
+ if (efx->legacy_irq)
+ efx->legacy_irq_enabled = true;
efx_nic_enable_interrupts(efx);
/* Switch to event based MCDI completions after enabling interrupts.
@@ -1460,8 +1466,10 @@ static void efx_stop_all(struct efx_nic *efx)
/* Disable interrupts and wait for ISR to complete */
efx_nic_disable_interrupts(efx);
- if (efx->legacy_irq)
+ if (efx->legacy_irq) {
synchronize_irq(efx->legacy_irq);
+ efx->legacy_irq_enabled = false;
+ }
efx_for_each_channel(channel, efx) {
if (channel->irq)
synchronize_irq(channel->irq);
diff --git a/drivers/net/sfc/net_driver.h b/drivers/net/sfc/net_driver.h
index 0a7e26d..b137c88 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -621,6 +621,7 @@ struct efx_filter_state;
* @pci_dev: The PCI device
* @type: Controller type attributes
* @legacy_irq: IRQ number
+ * @legacy_irq_enabled: Are IRQs enabled on NIC (INT_EN_KER register)?
* @workqueue: Workqueue for port reconfigures and the HW monitor.
* Work items do not hold and must not acquire RTNL.
* @workqueue_name: Name of workqueue
@@ -709,6 +710,7 @@ struct efx_nic {
struct pci_dev *pci_dev;
const struct efx_nic_type *type;
int legacy_irq;
+ bool legacy_irq_enabled;
struct workqueue_struct *workqueue;
char workqueue_name[16];
struct work_struct reset_work;
diff --git a/drivers/net/sfc/nic.c b/drivers/net/sfc/nic.c
index 41c36b9..67cb0c9 100644
--- a/drivers/net/sfc/nic.c
+++ b/drivers/net/sfc/nic.c
@@ -1418,6 +1418,12 @@ static irqreturn_t efx_legacy_interrupt(int irq, void *dev_id)
u32 queues;
int syserr;
+ /* Could this be ours? If interrupts are disabled then the
+ * channel state may not be valid.
+ */
+ if (!efx->legacy_irq_enabled)
+ return result;
+
/* Read the ISR which also ACKs the interrupts */
efx_readd(efx, ®, FR_BZ_INT_ISR0);
queues = EFX_EXTRACT_DWORD(reg, 0, 31);
--
1.7.3.2
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
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