* 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
* [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: [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
* 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: 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
* 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: 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
* 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: 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: 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: 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
* 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: 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
* 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
* [PATCH] af_packet: fix freeing pg_vec twice on error path
From: Changli Gao @ 2010-12-07 15:05 UTC (permalink / raw)
To: David S. Miller
Cc: Eric Dumazet, Jiri Pirko, Neil Horman, netdev, Changli Gao
It is introduced in:
commit 0e3125c755445664f00ad036e4fc2cd32fd52877
Author: Neil Horman <nhorman@tuxdriver.com>
Date: Tue Nov 16 10:26:47 2010 -0800
packet: Enhance AF_PACKET implementation to not require high order contiguous memory allocation (v4)
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/packet/af_packet.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 0e152b1..d163f78 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2408,7 +2408,6 @@ out:
out_free_pgvec:
free_pg_vec(pg_vec, order, block_nr);
- kfree(pg_vec);
pg_vec = NULL;
goto out;
}
^ permalink raw reply related
* Re: usbnet: Recursive Locking bug ?
From: Oliver Neukum @ 2010-12-07 14:54 UTC (permalink / raw)
To: Neil Jones, David Brownell
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTikBjxZEvWu+322qP2v0MU9xFQrgJmq2xA-Zdo32-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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
--
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
* [PATCH] isdn/hisax: fix compiler warning on hisax_pci_tbl
From: Namhyung Kim @ 2010-12-07 14:49 UTC (permalink / raw)
To: Karsten Keil; +Cc: netdev, linux-kernel
Annotate hisax_pci_tbl as '__used' to fix following warning:
CC drivers/isdn/hisax/config.o
drivers/isdn/hisax/config.c:1920: warning: ‘hisax_pci_tbl’ defined but not used
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/isdn/hisax/config.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/isdn/hisax/config.c b/drivers/isdn/hisax/config.c
index b133378..c110f86 100644
--- a/drivers/isdn/hisax/config.c
+++ b/drivers/isdn/hisax/config.c
@@ -1917,7 +1917,7 @@ static void EChannel_proc_rcv(struct hisax_d_if *d_if)
#ifdef CONFIG_PCI
#include <linux/pci.h>
-static struct pci_device_id hisax_pci_tbl[] __devinitdata = {
+static struct pci_device_id hisax_pci_tbl[] __devinitdata __used = {
#ifdef CONFIG_HISAX_FRITZPCI
{PCI_VDEVICE(AVM, PCI_DEVICE_ID_AVM_A1) },
#endif
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] use total_highpages when calculating lowmem-only allocation sizes (dccp)
From: Jan Beulich @ 2010-12-07 14:38 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev
In-Reply-To: <20101206.093630.104060994.davem@davemloft.net>
>>> On 06.12.10 at 18:36, David Miller <davem@davemloft.net> wrote:
> From: "Jan Beulich" <JBeulich@novell.com>
> Date: Mon, 06 Dec 2010 16:42:46 +0000
>
>> For those (large) table allocations that come only from lowmem, the
>> total amount of memory shouldn't really matter.
>>
>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>
> Instead of continually tweaking the bits in these code paths,
> we should be converting them over to using a central routine
> such as alloc_large_system_hash() where the logic is consolidated
> _AND_ the code knows to use vmalloc() and NUMA aware allocations
> when warranted.
Hmm, not sure. For one, alloc_large_system_hash() is (and imo
ought to remain) an __init function. Second, looking at the one
non-modular case (netlink_proto_init()), I don't think using this
function would be the intention here.
Jan
^ permalink raw reply
* [PATCH] af_packet: eliminate pgv_to_page on some arches
From: Changli Gao @ 2010-12-07 14:26 UTC (permalink / raw)
To: David S. Miller
Cc: Eric Dumazet, Jiri Pirko, Neil Horman, netdev, Changli Gao
Some arches don't need flush_dcache_page(), and don't implement it, so
we can eliminate pgv_to_page() calls on those arches.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/packet/af_packet.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index a11c731..0e152b1 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -223,7 +223,7 @@ struct packet_skb_cb {
#define PACKET_SKB_CB(__skb) ((struct packet_skb_cb *)((__skb)->cb))
-static inline struct page *pgv_to_page(void *addr)
+static inline __pure struct page *pgv_to_page(void *addr)
{
if (is_vmalloc_addr(addr))
return vmalloc_to_page(addr);
@@ -805,6 +805,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
__packet_set_status(po, h.raw, status);
smp_mb();
+#if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 1
{
u8 *start, *end;
@@ -812,6 +813,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
for (start = h.raw; start < end; start += PAGE_SIZE)
flush_dcache_page(pgv_to_page(start));
}
+#endif
sk->sk_data_ready(sk, 0);
^ permalink raw reply related
* usbnet: Recursive Locking bug ?
From: Neil Jones @ 2010-12-07 14:08 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
Hi,
I get a recursice lock warning from usbnet (asix adapter) with lockdep
checking on:
=============================================
[ INFO: possible recursive locking detected ]
2.6.37-rc4+ #1695
---------------------------------------------
ifconfig/536 is trying to acquire lock:
(&(&list->lock)->rlock#2){-.-...}, at: [<401a63bc>] _defer_bh+0x24/0x124
but task is already holding lock:
(&(&list->lock)->rlock#2){-.-...}, at: [<401a5f28>] _unlink_urbs+0x1c/0xa8
other info that might help us debug this:
2 locks held by ifconfig/536:
#0: (rtnl_mutex){+.+.+.}, at: [<4026b4f8>] _rtnl_lock+0x1c/0x2c
#1: (&(&list->lock)->rlock#2){-.-...}, at: [<401a5f28>] _unlink_urbs+0x1c/0xa8
this occurs on bring the interface down.
I think this is due to unlink_urbs():
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:
If people agree I will submit a patch.
Cheers
Neil
--
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 net-next-2.6 8/17 v2] can: EG20T PCH: Change Copyright and module description
From: Tomoya MORINAGA @ 2010-12-07 11:22 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, Wolfgang Grandegger
In-Reply-To: <4CFE1454.90200@pengutronix.de>
On Tuesday, December 07, 2010 8:02 PM, Marc Kleine-Budde wrote:
> Then check your settings, e.g. username, ssmtp, TSL, port, passwd.
By adding "--smtp-usr=xxx", I can send a patch to external domain.
Thank you.^_^
However, I sent v8 series by hand.
Next, I will use get-send-email command.
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
Tomoya Morinaga
OKI SEMICONDUCTOR CO., LTD.
----- Original Message -----
From: "Marc Kleine-Budde" <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: "Tomoya MORINAGA" <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Cc: "Wolfgang Grandegger" <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>;
<socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org>; <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>;
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; <qi.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>;
<yong.y.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>;
<joel.clark-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <margie.foster-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Sent: Tuesday, December 07, 2010 8:02 PM
Subject: Re: [PATCH net-next-2.6 8/17 v2] can: EG20T PCH: Change Copyright
and module description
^ permalink raw reply
* [PATCH net-next-2.6 v8 20/20] CAN : Replace netif_rx to netif_receive_skb
From: Tomoya MORINAGA @ 2010-12-07 11:12 UTC (permalink / raw)
To: Wolfgang Grandegger, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
Since this driver is implemented as NAPI,
netif_receive_skb must be used not netif_rx.
Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
---
drivers/net/can/pch_can.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 4697b1c..8d45fdd 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -572,7 +572,7 @@ static void pch_can_error(struct net_device *ndev, u32 status)
cf->data[7] = (errc & PCH_REC) >> 8;
priv->can.state = state;
- netif_rx(skb);
+ netif_receive_skb(skb);
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
--
1.6.0.6
^ permalink raw reply related
* [PATCH net-next-2.6 v8 19/20] CAN : Add setting TEC/REC statistics processing
From: Tomoya MORINAGA @ 2010-12-07 11:12 UTC (permalink / raw)
To: Wolfgang Grandegger, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
Add setting TEC/REC statistics processing.
Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
---
drivers/net/can/pch_can.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index dcd8f00..4697b1c 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -568,6 +568,9 @@ static void pch_can_error(struct net_device *ndev, u32 status)
break;
}
+ cf->data[6] = errc & PCH_TEC;
+ cf->data[7] = (errc & PCH_REC) >> 8;
+
priv->can.state = state;
netif_rx(skb);
--
1.6.0.6
^ permalink raw reply related
* [PATCH net-next-2.6 v8 18/20] CAN : Optimize "if" condition in rx/tx processing
From: Tomoya MORINAGA @ 2010-12-07 11:11 UTC (permalink / raw)
To: Wolfgang Grandegger, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
For reduce "if" condition, easy to read/understand the code,
optimize "if" condition in rx/tx processing.
Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
---
drivers/net/can/pch_can.c | 26 ++++++++++----------------
1 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 8efbe35..dcd8f00 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -746,19 +746,16 @@ static int pch_can_poll(struct napi_struct *napi, int quota)
if (int_stat == PCH_STATUS_INT) {
reg_stat = ioread32(&priv->regs->stat);
- if (reg_stat & (PCH_BUS_OFF | PCH_LEC_ALL)) {
- if (reg_stat & PCH_BUS_OFF ||
- (reg_stat & PCH_LEC_ALL) != PCH_LEC_ALL) {
- pch_can_error(ndev, reg_stat);
- quota--;
- }
- }
- if (reg_stat & PCH_TX_OK)
- pch_can_bit_clear(&priv->regs->stat, PCH_TX_OK);
+ if ((reg_stat & (PCH_BUS_OFF | PCH_LEC_ALL)) &&
+ ((reg_stat & PCH_LEC_ALL) != PCH_LEC_ALL)) {
+ pch_can_error(ndev, reg_stat);
+ quota--;
+ }
- if (reg_stat & PCH_RX_OK)
- pch_can_bit_clear(&priv->regs->stat, PCH_RX_OK);
+ if (reg_stat & (PCH_TX_OK | PCH_RX_OK))
+ pch_can_bit_clear(&priv->regs->stat,
+ reg_stat & (PCH_TX_OK | PCH_RX_OK));
int_stat = pch_can_int_pending(priv);
}
@@ -900,14 +897,13 @@ static netdev_tx_t pch_xmit(struct sk_buff *skb, struct net_device *ndev)
if (can_dropped_invalid_skb(ndev, skb))
return NETDEV_TX_OK;
+ tx_obj_no = priv->tx_obj;
if (priv->tx_obj == PCH_TX_OBJ_END) {
if (ioread32(&priv->regs->treq2) & PCH_TREQ2_TX_MASK)
netif_stop_queue(ndev);
- tx_obj_no = priv->tx_obj;
priv->tx_obj = PCH_TX_OBJ_START;
} else {
- tx_obj_no = priv->tx_obj;
priv->tx_obj++;
}
@@ -926,9 +922,7 @@ static netdev_tx_t pch_xmit(struct sk_buff *skb, struct net_device *ndev)
id2 |= PCH_ID_MSGVAL;
/* If remote frame has to be transmitted.. */
- if (cf->can_id & CAN_RTR_FLAG)
- id2 &= ~PCH_ID2_DIR;
- else
+ if (!(cf->can_id & CAN_RTR_FLAG))
id2 |= PCH_ID2_DIR;
iowrite32(id2, &priv->regs->ifregs[1].id2);
--
1.6.0.6
^ permalink raw reply related
* [PATCH net-next-2.6 v8 17/20] CAN : Fix incorrect return processing
From: Tomoya MORINAGA @ 2010-12-07 11:11 UTC (permalink / raw)
To: Wolfgang Grandegger, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
Fix incorrect return processing.
Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
---
drivers/net/can/pch_can.c | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index ace1fe7..8efbe35 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -580,9 +580,11 @@ static irqreturn_t pch_can_interrupt(int irq, void *dev_id)
struct net_device *ndev = (struct net_device *)dev_id;
struct pch_can_priv *priv = netdev_priv(ndev);
+ if (!pch_can_int_pending(priv))
+ return IRQ_NONE;
+
pch_can_set_int_enables(priv, PCH_CAN_NONE);
napi_schedule(&priv->napi);
-
return IRQ_HANDLED;
}
@@ -671,8 +673,10 @@ static int pch_can_rx_normal(struct net_device *ndev, u32 obj_num, int quota)
}
skb = alloc_can_skb(priv->ndev, &cf);
- if (!skb)
- return -ENOMEM;
+ if (!skb) {
+ netdev_err(ndev, "alloc_can_skb Failed\n");
+ return rcv_pkts;
+ }
/* Get Received data */
id2 = ioread32(&priv->regs->ifregs[0].id2);
@@ -733,8 +737,8 @@ static int pch_can_poll(struct napi_struct *napi, int quota)
struct net_device *ndev = napi->dev;
struct pch_can_priv *priv = netdev_priv(ndev);
u32 int_stat;
- int rcv_pkts = 0;
u32 reg_stat;
+ int quota_save = quota;
int_stat = pch_can_int_pending(priv);
if (!int_stat)
@@ -763,10 +767,7 @@ static int pch_can_poll(struct napi_struct *napi, int quota)
goto end;
if ((int_stat >= PCH_RX_OBJ_START) && (int_stat <= PCH_RX_OBJ_END)) {
- rcv_pkts += pch_can_rx_normal(ndev, int_stat, quota);
- quota -= rcv_pkts;
- if (quota < 0)
- goto end;
+ quota -= pch_can_rx_normal(ndev, int_stat, quota);
} else if ((int_stat >= PCH_TX_OBJ_START) &&
(int_stat <= PCH_TX_OBJ_END)) {
/* Handle transmission interrupt */
@@ -777,7 +778,7 @@ end:
napi_complete(napi);
pch_can_set_int_enables(priv, PCH_CAN_ALL);
- return rcv_pkts;
+ return quota_save - quota;
}
static int pch_set_bittiming(struct net_device *ndev)
--
1.6.0.6
^ 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