* Re: [PATCH] Don't allow sharing of tx skbs on xen-netfront
From: Neil Horman @ 2011-11-17 19:25 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev, David S. Miller, Jeremy Fitzhardinge,
Konrad Rzeszutek Wilk, xen-devel
In-Reply-To: <1321543238.3664.278.camel@zakaz.uk.xensource.com>
On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > It was pointed out to me recently that the xen-netfront driver can't safely
> > support shared skbs on transmit, since, while it doesn't maintain skb state
> > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > the hypervisor may expect the contents of the skb to remain stable. Clearing
> > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
>
> What are the actual constraints here? The skb is used as a handle to the
> skb->data and shinfo (frags) and to complete at the end. It's actually
> those which are passed to the hypervisor (effectively the same as
> passing those addresses to the h/w for DMA).
>
> Which parts of the skb are expected/allowed to not remain stable?
>
> (Appologies if the above seems naive, I seem to have missed the
> introduction of shared tx skbs and IFF_TX_SKB_SHARING)
>
Its ok, this is the most accurate description from the previous threads on the
subject:
http://lists.openwall.net/netdev/2011/08/22/63
The basic problem boils down the notion that some drivers, when they receive an
skb in their xmit paths, presume to have sole ownership of the skb, and as a
result may do things like add the skb to a list, or otherwise store stateful
data in the skb. If the skb is shared, thats unsafe to do, as the stack still
holds a reference to the skb, and make make changes without serializing them
against the driver. So we have to flag those drivers which preform these kinds
of actions. xen-netfront doesn't strictly speaking modify any state directly ni
an skb, but it does place a pointer to the skb in a data structure here:
np->tx_skbs[id].skb = skb;
Which then gets handed off to the hypervisior. Since the hypervisor now has
access to that skb pointer, and we can't be sure (from the guest perspective),
what it does with that information, it would be better to be safe by disallowing
shared skbs in this path.
Neil
> Ian.
>
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > CC: "David S. Miller" <davem@davemloft.net>
> > CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > CC: xen-devel@lists.xensource.com
> > ---
> > drivers/net/xen-netfront.c | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 226faab..fb1077b 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -1252,6 +1252,12 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
> > return ERR_PTR(-ENOMEM);
> > }
> >
> > + /*
> > + * Since frames remain on a queue after a return from xennet_start_xmit,
> > + * we can't support tx shared skbs
> > + */
> > + netdev->priv_flags &= ~IFF_TX_SKB_SHARING;
> > +
> > np = netdev_priv(netdev);
> > np->xbdev = dev;
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] net, bridge: print log message after state changed
From: David Lamparter @ 2011-11-17 19:23 UTC (permalink / raw)
To: David Miller; +Cc: Wolfgang.Fritz, holger.brunck, netdev, shemminger, bridge
In-Reply-To: <20111114.020749.1176229013272872343.davem@davemloft.net>
On Mon, Nov 14, 2011 at 02:07:49AM -0500, David Miller wrote:
> >> The message is therefore appropriately timed as far as I'm concerned.
> >>
> >
> > It's not.
> >
> > Please test: create a bridge with STP disabled, add an interface to the
> > bridge and set that interface down. You get the message "... entering
> > forwarding state". That's wrong because it's "about to enter" disabled
> > state some lines later.
> >
> > All other (4) calls to br_log_state are located after the state change,
> > see for example br_stp_enable_port() just some lines above the patch.
>
> I would never expect an "entering" message to print out after the event
> happens, and in fact I'd _always_ want to see it beforehand so that if
> the state change caused a crash or similar it'd be that much easier
> to pinpoint the proper location.
There seems to be a misunderstanding here. The patch effectively does:
- br_log_state(p);
p->state = BR_STATE_DISABLED;
+ br_log_state(p);
and the issue it is trying to fix is not the timing but rather the code
printing the wrong (old, now-left) state.
I do agree that the log message should be printed before anything
happens, so, Holger, can you brew a patch that does that?
-David
^ permalink raw reply
* Re: [PATCH 1/6] sky2: fix hang on shutdown (and other irq issues)
From: Stephen Hemminger @ 2011-11-17 19:18 UTC (permalink / raw)
To: Sven Joachim; +Cc: davem, netdev
In-Reply-To: <87pqgqoard.fsf@turtle.gmx.de>
Does this fix it?
--- a/drivers/net/ethernet/marvell/sky2.c 2011-11-17 11:10:35.938076778 -0800
+++ b/drivers/net/ethernet/marvell/sky2.c 2011-11-17 11:15:49.527882932 -0800
@@ -1723,6 +1723,8 @@ static int sky2_setup_irq(struct sky2_hw
if (err)
dev_err(&pdev->dev, "cannot assign irq %d\n", pdev->irq);
else {
+ hw->flags |= SKY2_HW_IRQ_SETUP;
+
napi_enable(&hw->napi);
sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
sky2_read32(hw, B0_IMSK);
@@ -2120,6 +2122,7 @@ static int sky2_close(struct net_device
napi_disable(&hw->napi);
free_irq(hw->pdev->irq, hw);
+ hw->flags &= ~SKY2_HW_IRQ_SETUP;
} else {
u32 imask;
@@ -3423,12 +3426,13 @@ static void sky2_all_down(struct sky2_hw
{
int i;
- sky2_read32(hw, B0_IMSK);
- sky2_write32(hw, B0_IMSK, 0);
+ if (hw->flags & SKY2_HW_IRQ_SETUP) {
+ sky2_read32(hw, B0_IMSK);
+ sky2_write32(hw, B0_IMSK, 0);
- if (hw->ports > 1 || netif_running(hw->dev[0]))
synchronize_irq(hw->pdev->irq);
- napi_disable(&hw->napi);
+ napi_disable(&hw->napi);
+ }
for (i = 0; i < hw->ports; i++) {
struct net_device *dev = hw->dev[i];
@@ -3445,7 +3449,7 @@ static void sky2_all_down(struct sky2_hw
static void sky2_all_up(struct sky2_hw *hw)
{
- u32 imask = 0;
+ u32 imask = Y2_IS_BASE;
int i;
for (i = 0; i < hw->ports; i++) {
@@ -3461,8 +3465,7 @@ static void sky2_all_up(struct sky2_hw *
netif_wake_queue(dev);
}
- if (imask || hw->ports > 1) {
- imask |= Y2_IS_BASE;
+ if (hw->flags & SKY2_HW_IRQ_SETUP) {
sky2_write32(hw, B0_IMSK, imask);
sky2_read32(hw, B0_IMSK);
sky2_read32(hw, B0_Y2_SP_LISR);
--- a/drivers/net/ethernet/marvell/sky2.h 2011-11-16 15:15:40.964280527 -0800
+++ b/drivers/net/ethernet/marvell/sky2.h 2011-11-17 11:13:00.154858718 -0800
@@ -2287,6 +2287,7 @@ struct sky2_hw {
#define SKY2_HW_RSS_BROKEN 0x00000100
#define SKY2_HW_VLAN_BROKEN 0x00000200
#define SKY2_HW_RSS_CHKSUM 0x00000400 /* RSS requires chksum */
+#define SKY2_HW_IRQ_SETUP 0x00000800
u8 chip_id;
u8 chip_rev;
^ permalink raw reply
* Occasional oops with IPSec and IPv6.
From: Nick Bowler @ 2011-11-17 19:09 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Timo Teras
Hi folks,
One of the tests we do with IPsec involves sending and receiving UDP
datagrams of all sizes from 1 to N bytes, where N is much larger than
the MTU. In this particular instance, the MTU is 1500 bytes and N is
10000 bytes. This test works fine with IPv4, but I'm getting an
occasional oops on Linus' master with IPv6 (output at end of email). We
also run the same test where N is less than the MTU, and it does not
trigger this issue. The resulting fallout seems to eventually lock up
the box (although it continues to work for a little while afterwards).
The issue appears timing related, and it doesn't always occur. This
probably also explains why I've not seen this issue before now, as we
recently upgraded all our lab systems to machines from this century
(with newfangled dual core processors). This also makes it somewhat
hard to reproduce, but I can trigger it pretty reliably by running 'yes'
in an ssh session (which doesn't use IPsec) while running the test:
it'll usually trigger in 2 or 3 runs. The choice of cipher suite
appears to be irrelevant.
I built a relatively old kernel (2.6.34) and could not reproduce the
issue there, so I ran a git bisect. It pointed to the following, which
(unsurprisingly) no longer reverts cleanly.
Let me know if you need any more info. I'll see if I can reproduce the
issue with a smaller test case...
80c802f3073e84c956846e921e8a0b02dfa3755f is the first bad commit
commit 80c802f3073e84c956846e921e8a0b02dfa3755f
Author: Timo Teräs <timo.teras@iki.fi>
Date: Wed Apr 7 00:30:05 2010 +0000
xfrm: cache bundles instead of policies for outgoing flows
__xfrm_lookup() is called for each packet transmitted out of
system. The xfrm_find_bundle() does a linear search which can
kill system performance depending on how many bundles are
required per policy.
This modifies __xfrm_lookup() to store bundles directly in
the flow cache. If we did not get a hit, we just create a new
bundle instead of doing slow search. This means that we can now
get multiple xfrm_dst's for same flow (on per-cpu basis).
Signed-off-by: Timo Teras <timo.teras@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
:040000 040000 d8e60f5fa4c1329f450d9c7cdf98b34e6a177f22 9f576e68e5bf4ce357d7f0305aee5f410250dfe2 M include
:040000 040000 f2876df688ee36907af7b4123eea96592faaed3e a3f6f6f94f0309106856cd99b38ec90b024eb016 M net
[ 138.024462] skb_under_panic: text:f83aff05 len:1470 put:14 head:f2ee4800 data:f2ee47fa tail:0xf2ee4db8 end:0xf2ee4f40 dev:p10p1
[ 138.036298] ------------[ cut here ]------------
[ 138.037077] kernel BUG at net/core/skbuff.c:147!
[ 138.037077] invalid opcode: 0000 [#1] PREEMPT SMP
[ 138.037077] Modules linked in: authenc esp6 xfrm6_mode_transport deflate zlib_deflate ctr twofish_generic twofish_common camellia serpent blowfish_generic blowfish_common cast5 des_generic cbc xcbc rmd160 sha512_generic sha256_generic sha1_generic md5 hmac crypto_null af_key nfs lockd auth_rpcgss sunrpc rng_core ip6table_filter ip6_tables iptable_filter ip_tables x_tables psmouse sg r8169 mii evdev button ipv6 autofs4 ehci_hcd sd_mod ohci_hcd usbcore usb_common radeon ttm drm_kms_helper drm backlight i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect [last unloaded: scsi_wait_scan]
[ 138.067337]
[ 138.067337] Pid: 2846, comm: udp_scan Not tainted 3.2.0-rc2-00043-gaa1b052 #53 System manufacturer System Product Name/M4A785T-M
[ 138.067337] EIP: 0060:[<c11ff3d7>] EFLAGS: 00010246 CPU: 0
[ 138.067337] EIP is at skb_push+0x52/0x5b
[ 138.067337] EAX: 00000089 EBX: f3abf000 ECX: 00000080 EDX: 00000003
[ 138.067337] ESI: f3abf000 EDI: f2ee4808 EBP: f2655b70 ESP: f2655b44
[ 138.067337] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 138.067337] Process udp_scan (pid: 2846, ti=f2654000 task=f2683420 task.ti=f2654000)
[ 138.067337] Stack:
[ 138.067337] c13a2802 f83aff05 000005be 0000000e f2ee4800 f2ee47fa f2ee4db8 f2ee4f40
[ 138.067337] f3abf000 f2725780 f4454d18 f2655b90 f83aff05 f4454d08 00000000 f4454c00
[ 138.067337] f27256c0 f3dfc528 f26fec38 f2655be4 f83b0f58 00000201 f2655ba4 00000046
[ 138.067337] Call Trace:
[ 138.067337] [<f83aff05>] ? ip6_finish_output2+0x26c/0x31a [ipv6]
[ 138.067337] [<f83aff05>] ip6_finish_output2+0x26c/0x31a [ipv6]
[ 138.067337] [<f83b0f58>] ip6_fragment+0x3b4/0x941 [ipv6]
[ 138.067337] [<f83afc99>] ? NF_HOOK.constprop.4+0x30/0x30 [ipv6]
[ 138.067337] [<f83b1524>] ip6_finish_output+0x3f/0x4c [ipv6]
[ 138.067337] [<f83b15e9>] ip6_output+0xb8/0xc0 [ipv6]
[ 138.067337] [<c1252241>] xfrm_output_resume+0x75/0x2c5
[ 138.067337] [<c125249e>] xfrm_output2+0xd/0xf
[ 138.067337] [<c1252533>] xfrm_output+0x93/0x9c
[ 138.067337] [<f83cdb5e>] xfrm6_output_finish+0x13/0x15 [ipv6]
[ 138.067337] [<f83cda4b>] __xfrm6_output+0x108/0x10d [ipv6]
[ 138.067337] [<f83cdba7>] xfrm6_output+0x47/0x4c [ipv6]
[ 138.067337] [<f83af7b4>] dst_output+0x12/0x15 [ipv6]
[ 138.067337] [<f83b036a>] ip6_local_out+0x17/0x1a [ipv6]
[ 138.067337] [<f83b2283>] ip6_push_pending_frames+0x2a4/0x346 [ipv6]
[ 138.067337] [<f83bf055>] udp_v6_push_pending_frames+0x213/0x271 [ipv6]
[ 138.067337] [<f83bfea4>] ? udpv6_sendmsg+0x68d/0x832 [ipv6]
[ 138.067337] [<f83bfec6>] udpv6_sendmsg+0x6af/0x832 [ipv6]
[ 138.067337] [<c123ffc4>] ? ip_fast_csum+0x30/0x30
[ 138.067337] [<c1240500>] inet_sendmsg+0x4e/0x57
[ 138.067337] [<c11f8f0e>] sock_sendmsg+0xbe/0xd9
[ 138.067337] [<c10542df>] ? mark_lock+0x26/0x1ea
[ 138.067337] [<c10542df>] ? mark_lock+0x26/0x1ea
[ 138.067337] [<c10548e7>] ? __lock_acquire+0x444/0xb17
[ 138.067337] [<c10acd97>] ? fget_light+0x28/0x7c
[ 138.067337] [<c11fa362>] sys_sendto+0xb1/0xcd
[ 138.067337] [<c10548e7>] ? __lock_acquire+0x444/0xb17
[ 138.067337] [<c1021085>] ? __wake_up+0x15/0x3b
[ 138.067337] [<c10d2f0f>] ? fsnotify+0x64/0x208
[ 138.067337] [<c102866b>] ? get_parent_ip+0xb/0x31
[ 138.067337] [<c1055038>] ? lock_release_non_nested+0x7e/0x1bb
[ 138.067337] [<c11fa396>] sys_send+0x18/0x1a
[ 138.067337] [<c11fa99f>] sys_socketcall+0xce/0x19a
[ 138.067337] [<c11508f0>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 138.067337] [<c12717d0>] sysenter_do_call+0x12/0x36
[ 138.067337] Code: c1 85 f6 0f 45 de 53 ff b1 98 00 00 00 ff b1 94 00 00 00 50 ff b1 9c 00 00 00 52 ff 71 50 ff 75 04 68 02 28 3a c1 e8 86 c7 06 00 <0f> 0b 8d 65 f8 5b 5e 5d c3 55 89 c1 89 e5 56 53 83 79 54 00 8b
[ 138.067337] EIP: [<c11ff3d7>] skb_push+0x52/0x5b SS:ESP 0068:f2655b44
[ 138.398457] ---[ end trace cb87617e5ef07196 ]---
[ 138.404512] BUG: sleeping function called from invalid context at kernel/rwsem.c:21
[ 138.412662] in_atomic(): 0, irqs_disabled(): 0, pid: 2846, name: udp_scan
[ 138.420076] INFO: lockdep is turned off.
[ 138.424721] Pid: 2846, comm: udp_scan Tainted: G D 3.2.0-rc2-00043-gaa1b052 #53
[ 138.433542] Call Trace:
[ 138.436387] [<c10307b1>] ? console_unlock+0x1b6/0x1c9
[ 138.442035] [<c1024dbd>] __might_sleep+0xe2/0xe9
[ 138.447249] [<c127009f>] down_read+0x17/0x3b
[ 138.452139] [<c105fc85>] acct_collect+0x39/0x134
[ 138.457431] [<c1032c08>] do_exit+0x188/0x5de
[ 138.462369] [<c1031464>] ? kmsg_dump+0xdf/0xe7
[ 138.467328] [<c1004737>] oops_end+0x92/0x9a
[ 138.472238] [<c1004868>] die+0x51/0x59
[ 138.476546] [<c1002626>] do_trap+0x89/0xa2
[ 138.481264] [<c1002776>] ? do_bounds+0x52/0x52
[ 138.486308] [<c10027e7>] do_invalid_op+0x71/0x7b
[ 138.491727] [<c11ff3d7>] ? skb_push+0x52/0x5b
[ 138.496685] [<c12710a0>] ? restore_all+0xf/0xf
[ 138.501659] [<c10307b1>] ? console_unlock+0x1b6/0x1c9
[ 138.507479] [<c102369b>] ? need_resched+0x14/0x1e
[ 138.512845] [<c126f34f>] ? preempt_schedule+0x40/0x46
[ 138.518685] [<c1030c19>] ? vprintk+0x390/0x3ae
[ 138.523751] [<c1052d01>] ? trace_hardirqs_off_caller+0x2e/0x86
[ 138.530302] [<c1150900>] ? trace_hardirqs_off_thunk+0xc/0x10
[ 138.536680] [<c1271563>] error_code+0x5f/0x64
[ 138.541625] [<c1002776>] ? do_bounds+0x52/0x52
[ 138.546741] [<c11ff3d7>] ? skb_push+0x52/0x5b
[ 138.551812] [<f83aff05>] ? ip6_finish_output2+0x26c/0x31a [ipv6]
[ 138.558652] [<f83aff05>] ip6_finish_output2+0x26c/0x31a [ipv6]
[ 138.565308] [<f83b0f58>] ip6_fragment+0x3b4/0x941 [ipv6]
[ 138.571373] [<f83afc99>] ? NF_HOOK.constprop.4+0x30/0x30 [ipv6]
[ 138.578173] [<f83b1524>] ip6_finish_output+0x3f/0x4c [ipv6]
[ 138.584534] [<f83b15e9>] ip6_output+0xb8/0xc0 [ipv6]
[ 138.590172] [<c1252241>] xfrm_output_resume+0x75/0x2c5
[ 138.596199] [<c125249e>] xfrm_output2+0xd/0xf
[ 138.601362] [<c1252533>] xfrm_output+0x93/0x9c
[ 138.606581] [<f83cdb5e>] xfrm6_output_finish+0x13/0x15 [ipv6]
[ 138.613283] [<f83cda4b>] __xfrm6_output+0x108/0x10d [ipv6]
[ 138.619672] [<f83cdba7>] xfrm6_output+0x47/0x4c [ipv6]
[ 138.625676] [<f83af7b4>] dst_output+0x12/0x15 [ipv6]
[ 138.631628] [<f83b036a>] ip6_local_out+0x17/0x1a [ipv6]
[ 138.637749] [<f83b2283>] ip6_push_pending_frames+0x2a4/0x346 [ipv6]
[ 138.644714] [<f83bf055>] udp_v6_push_pending_frames+0x213/0x271 [ipv6]
[ 138.652186] [<f83bfea4>] ? udpv6_sendmsg+0x68d/0x832 [ipv6]
[ 138.658621] [<f83bfec6>] udpv6_sendmsg+0x6af/0x832 [ipv6]
[ 138.665021] [<c123ffc4>] ? ip_fast_csum+0x30/0x30
[ 138.670635] [<c1240500>] inet_sendmsg+0x4e/0x57
[ 138.676069] [<c11f8f0e>] sock_sendmsg+0xbe/0xd9
[ 138.681502] [<c10542df>] ? mark_lock+0x26/0x1ea
[ 138.686811] [<c10542df>] ? mark_lock+0x26/0x1ea
[ 138.692188] [<c10548e7>] ? __lock_acquire+0x444/0xb17
[ 138.698257] [<c10acd97>] ? fget_light+0x28/0x7c
[ 138.703692] [<c11fa362>] sys_sendto+0xb1/0xcd
[ 138.708962] [<c10548e7>] ? __lock_acquire+0x444/0xb17
[ 138.714935] [<c1021085>] ? __wake_up+0x15/0x3b
[ 138.720165] [<c10d2f0f>] ? fsnotify+0x64/0x208
[ 138.725623] [<c102866b>] ? get_parent_ip+0xb/0x31
[ 138.731295] [<c1055038>] ? lock_release_non_nested+0x7e/0x1bb
[ 138.737980] [<c11fa396>] sys_send+0x18/0x1a
[ 138.743113] [<c11fa99f>] sys_socketcall+0xce/0x19a
[ 138.748806] [<c11508f0>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 138.755407] [<c12717d0>] sysenter_do_call+0x12/0x36
[ 198.038028] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected by 1, t=60002 jiffies)
[ 198.039017] INFO: Stall ended before state dump start
Thanks,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: [patch net-next 2/2] team: avoid using variable-length array
From: Jiri Pirko @ 2011-11-17 18:52 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, netdev, bhutchings, shemminger, andy, fbl, jzupka,
ivecera, mirqus
In-Reply-To: <20111117.134022.653641656780834689.davem@davemloft.net>
Thu, Nov 17, 2011 at 07:40:22PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jpirko@redhat.com>
>Date: Thu, 17 Nov 2011 16:10:32 +0100
>
>> Sure, I'll do this in separate patch.
>
>No, you'll do it in _this_ patch.
>
>Jiri, please stop resisting the incorporation of feedback into
>the patches you post. You've done this twice in the past 3 days
>and it's really irritating.
Well, the change Eric suggested is unrelated to this patch so it seemed
good to me to do not mangle it together.
Anyway, I'm sorry being source of irritation :( (alhought I have
absolutelly no intention to do so)
Jirka
^ permalink raw reply
* Re: [patch net-next 2/2] team: avoid using variable-length array
From: David Miller @ 2011-11-17 18:40 UTC (permalink / raw)
To: jpirko
Cc: eric.dumazet, netdev, bhutchings, shemminger, andy, fbl, jzupka,
ivecera, mirqus
In-Reply-To: <20111117151031.GA3209@minipsycho>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 17 Nov 2011 16:10:32 +0100
> Sure, I'll do this in separate patch.
No, you'll do it in _this_ patch.
Jiri, please stop resisting the incorporation of feedback into
the patches you post. You've done this twice in the past 3 days
and it's really irritating.
^ permalink raw reply
* Re: [PATCH 1/6] sky2: fix hang on shutdown (and other irq issues)
From: Sven Joachim @ 2011-11-17 18:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20111117090104.002e110a@s6510.linuxnetplumber.net>
On 2011-11-17 18:01 +0100, Stephen Hemminger wrote:
> On Thu, 17 Nov 2011 09:46:43 +0100
> Sven Joachim <svenjoac@gmx.de> wrote:
>
>> On 2011-11-17 00:42 +0100, Stephen Hemminger wrote:
>>
>> > There are several problems with recent change to how IRQ's are setup.
>> > * synchronize_irq in sky2_shutdown would hang because there
>> > was no IRQ setup.
>> > * when device was set to down, some IRQ bits left enabled so a
>> > hardware error would produce IRQ with no handler
>> > * quick link on Optima chip set was enabled without handler
>> > * suspend/resume would leave IRQ on with no handler if device
>> > was down
>>
>> Unfortunately, this patch does not fix the hang at shutdown for me. :-(
>
> You are probably stuck in some part of the code path in sky2_shutdown.
Indeed.
> The best debug for this is sprinkling the code printk's. That is how I
> narrowed the problem down to synchronize_irq.
So I found out it's hanging in napi_disable() in sky2_all_down(). Not
being a kernel hacker, I don't know where to go from there.
Cheers,
Sven
^ permalink raw reply
* pull request: wireless-next 2011-11-17
From: John W. Linville @ 2011-11-17 18:29 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 34189 bytes --]
commit e11c259f745889b55bc5596ca78271f2f5cf08d2
Dave,
Here is a huge pull request for wireless bits intended for 3.3. I
reckon that the extended release cycle for 3.1 led to a backlog of new
work that appeared during the merge window for 3.2?
At any rate...there is a big Bluetooth pull with a lot of code
refactoring; a lot of brcm80211 bits including cleanups, refactoring,
and some new hardware support; the normal set of iwlwifi updates plus
some refactoring; an unusual large flurry of mac80211 and cfg80211
updates from Johannes (including the new wireless TX status socket
option); some updates to the new NFC subsystem; and the usual collection
of other driver and mac80211 updates. This also includes a pull of the
wireless.git tree to resolve some build issues.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 8d26784cf0d04c1238e906efdd5de76439cb0a1e:
ipv6: Use pr_warn() in ip6_fib.c (2011-11-17 03:18:28 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
Alexander Simon (1):
mac80211: Add HT helper functions
Alwin Beukers (4):
brcm80211: cleanup defines in main.c
brcm80211: removed duplicate defines
brcm80211: smac: don't modify sta parameters when adding sta
brcm80211: smac: combine promiscuous mode functionality
Amitkumar Karwar (3):
mwifiex: enable SDIO multiport aggregation
mwifiex: remove unnecessary free_priv handler
mwifiex: release bss structure returned by cfg80211_inform_bss()
Andre Guedes (3):
Bluetooth: Create hci_do_inquiry()
Bluetooth: Create hci_cancel_inquiry()
Bluetooth: Periodic Inquiry and Discovery
Andrei Emeltchenko (33):
Bluetooth: EFS: l2cap extended feature mask update
Bluetooth: EFS: add enable_hs kernel param
Bluetooth: convert flushable variable to flag in l2cap chan
Bluetooth: convert force_reliable variable to flag in l2cap chan
Bluetooth: convert force_active variable to flag in l2cap chan
Bluetooth: convert role_switch variable to flag in l2cap chan
Bluetooth: clean up spaces in L2CAP header
Bluetooth: EWS: extended window size option support
Bluetooth: EWS: adds ext control field bit mask
Bluetooth: EWS: rewrite handling Supervisory (S) bits
Bluetooth: EWS: rewrite handling SAR bits
Bluetooth: EWS: rewrite reqseq calculation
Bluetooth: EWS: rewrite L2CAP ERTM txseq calculation
Bluetooth: EWS: rewrite check frame type function
Bluetooth: EWS: rewrite handling FINAL (F) bit
Bluetooth: EWS: rewrite handling POLL (P) bit
Bluetooth: EWS: recalculate L2CAP header size
Bluetooth: EWS: define L2CAP header sizes
Bluetooth: EFS: definitions and headers
Bluetooth: EFS: assign default values in chan add
Bluetooth: EFS: add efs option in L2CAP conf req
Bluetooth: AMP: read local amp info HCI command
Bluetooth: EWS: handling different Control fields
Bluetooth: EWS: support extended seq numbers
Bluetooth: EWS: remove magic numbers in l2cap
Bluetooth: EWS: fix max_pdu calculation
Bluetooth: EFS: parse L2CAP config request
Bluetooth: EFS: implement L2CAP config pending state
Bluetooth: remove magic offset and size
Bluetooth: correct debug output
Bluetooth: Initialize tx_win_max for fixed channel
Bluetooth: Define HCI reasons instead of magic number
Bluetooth: EFS: parse L2CAP config response
Andrzej Kaczmarek (1):
Bluetooth: Use miliseconds for L2CAP channel timeouts
Arek Lichwa (1):
Bluetooth: Revert: Fix L2CAP connection establishment
Arend van Spriel (21):
brcm80211: smac: eliminate a null pointer dereference in dma.c
brcm80211: smac: drop "40MHz intolerant" flag from HT capability info
brcm80211: smac: remove obsolete srom variables from n-phy
brcm80211: smac: avoid sprom endianess conversions for crc8 check
brcm80211: smac: some local function made static in main.c
brcm80211: smac: remove phy api bypass in rate.h
brcm80211: util: move brcmu_pktfrombuf() function to brcmfmac
brcm80211: util: remove function brcmu_format_hex() from brcmutil
brcm80211: fmac: use sk_buff list for handling frames in receive path
brcm80211: smac: rename buffer endianess conversion functions
brcm80211: smac: use sk_buff list for handling frames in receive path
brcm80211: smac: change buffer endianess convert function interface
brcm80211: smac: fix endianess issue for OTP memory access
brcm80211: smac: remove code under unused macro definitions
brcm80211: smac: replace own access category definitions with mac80211 enum
brcm80211: smac: remove duplicate definition of D11_PHY_HDR_LEN
brcm80211: smac: remove usage of brcmu_pkttotlen
brcm80211: util: use sk_buff_head in precedence queue functions
brcm80211: util: move brcmu_pkttotlen() function to brcmfmac
brcm80211: util: remove pointer traversal from brcmu_pkt_buf_free_skb
brcm80211: fmac: add function to free the glom skb queue
Arik Nemtsov (6):
mac80211: support adding IV-room in the skb for CCMP keys
mac80211: init rate-control for TDLS sta when supp-rates are known
mac80211: make sure hw_key exists before checking its flags
nl80211: Add probe response offload attribute
nl80211: Pass probe response data to drivers
mac80211: Save probe response data for bss
Ben Greear (1):
ath9k: Improve debugfs printout for stations.
Christian Lamparter (1):
mac80211: handle HT PHY BSS membership selector value correctly
Dan Carpenter (6):
ath9k_hw: min_t() casts u32 to int
rndis_wlan: add range check in del_key()
iwmc3200wifi: add some more range checks
mwifiex: remove unneeded kfree(NULL);
mwifiex: remove an unneeded NULL check
mwifiex: prevent corruption instead of just warning
Daniel Kuehn (1):
ath9k: set ATH9K_PCI to y by default
David Herrmann (13):
Bluetooth: hidp: Stop I/O on shutdown
Bluetooth: Fix hci core device initialization
Bluetooth: Rename sysfs un/register to add/del
Bluetooth: Forward errors from hci_register_dev
Bluetooth: Return proper error codes on rfcomm tty init
Bluetooth: Replace rfcomm tty tasklet by workqueue
Bluetooth: Ignore hci_unregister_dev return value
Bluetooth: Make hci_unregister_dev return void
Bluetooth: ath3k: Use GFP_KERNEL instead of GFP_ATOMIC
Bluetooth: bcm203x: Fix race condition on disconnect
Bluetooth: bcm203x: Use GFP_KERNEL in workqueue
Bluetooth: bfusb: Fix error path on firmware load
Bluetooth: hidp: Fix module reference cleanup
David Kilroy (1):
orinoco: release BSS structures returned by cfg80211_inform_bss()
Dmitry Tarnyagin (1):
cfg80211: merge in beacon ies of hidden bss.
Don Fry (8):
iwlagn: remove unnecessary type for tracing operations
iwlagn: simplify iwl_alloc_all
iwlagn: move ucode_write_complete from priv to trans structure
iwlagn: remove knowledge of ucode image location from upper layers
iwlagn: push knowledge of ucode image lower down
iwlagn: move ucode files out of the iwl_priv structure
iwlagn: Remove dependence of iwl_priv from eeprom routines.
iwlagn: move nvm_device_type from iwl_priv to iwl_trans
Eliad Peller (4):
mac80211: use min rate as basic rate for buggy APs
mac80211: call set_wmm_default only for valid vifs
mac80211: set BSS_CHANGED_IDLE on vif reconfig
mac80211: set carrier_on for ibss vifs only while joined
Emmanuel Grumbach (3):
iwlwifi: fix unused label in iwl_send_cmd_sync
iwlwifi: remove the use of the QOS debug flag
iwlwifi: add debug information on queue stop / wake
Eyal Shapira (2):
wl12xx: fix wl12xx_scan_sched_scan_ssid_list() check that all given ssids are in filters
mac80211: add recalc PS in ieee80211_reconfig()
Franky Lin (28):
brcm80211: fmac: allow wd timer to be disabled when bus down
brcm80211: fmac: use brcmf_del_if for all net devices
brcm80211: fmac: use brcmf_add_if for all net devices
brcm80211: fmac: store brcmf_if in net device private data
brcm80211: fmac: remove state from brcmf_if in fullmac
brcm80211: fmac: remove unnecessary 4329 chip specific code
brcm80211: fmac: move chip recognition function to sdio_chip.c
brcm80211: fmac: move bus core prep code to sdio_chip.c
brcm80211: fmac: abstract chip buscore setup function
brcm80211: fmac: move core disable function to sdio_chip.c
brcm80211: fmac: disable dongle arm core in bus core setup function
brcm80211: fmac: move dongle gpio reset code to chip attach function
brcm80211: fmac: remove duplicate regiter set in chip attach path
brcm80211: fmac: chip attach code flow clean up
brcm80211: fmac: abstract chip iscoreup function
brcm80211: fmac: abstract chip core revision function
brcm80211: fmac: move chip reset core function to sdio_chip.c
brcm80211: fmac: move chip detach function to sdio_chip.c
brcm80211: fmac: move chip drive strength related code to sdio_chip.c
brcm80211: fmac: replace private SB macros with ssb_regs version
brcm80211: fmac: optimize chip core info management
brcm80211: fmac: add iscoreup function for bcm4330 chip
brcm80211: fmac: add corerev function for bcm4330 chip
brcm80211: fmac: add coredisable function for bcm4330 chip
brcm80211: fmac: add resetcore function for bcm4330 chip
brcm80211: fmac: remove id retrieve code
brcm80211: fmac: remove PCMCIA core related code
brcm80211: fmac: release bss struct returned from cfg80211_inform_bss
Gustavo F. Padovan (16):
Bluetooth: use list_for_each_entry() in hidp
Bluetooth: prioritize the interrupt channel in hidp
Bluetooth: Trasmit interrupt channel messages first
Bluetooth: Fix input device registration
Bluetooth: Remove wrong error check
Bluetooth: Uses test_and_clear_bit() when possible
Bluetooth: Delay session allocation in hidp
Bluetooth: Rename hidp_find_connection()
Bluetooth: Fix permission of enable_le param
Bluetooth: return proper error if sock_queue_rcv_skb() fails
Bluetooth: Add missing cmd_status() in mgmt
Bluetooth: Use list_for_each_entry() in mgmt
Bluetooth: Fix mgmt interaction with userspace
Bluetooth: Fix missing cmd_status in mgmt
Bluetooth: small styles clean ups to l2cap_core.c
Bluetooth: Fix hidp_get_connection()
Helmut Schaa (2):
ath: Fix NULL ptr dereference in ath_reg_apply_world_flags
mac80211: Also report the STA's TDLS flag via nl80211
Ilan Elias (3):
NFC: Update names and structs to NCI spec 1.0 d18
NFC: Removal of unused operations for NCI spec 1.0 d18
NFC: Check if NCI data flow control is used
Janusz.Dziedzic-++hxYGjEMp0AvxtiuMwx3w@public.gmane.org (1):
mac80211: uAPSD - fix IEEE80211_FCTL_MOREDATA bit setting
Javier Cardona (2):
mac80211: Avoid filling up mesh preq queue with redundant requests
mac80211: simplify mesh frame queue mapping and QoS
Jesper Juhl (1):
net, wireless, mwifiex: Fix mem leak in mwifiex_update_curr_bss_params()
Johan Hedberg (17):
Bluetooth: Fix command complete/status for discovery commands
Bluetooth: Set HCI_MGMT flag only in read_controller_info
Bluetooth: Fix mgmt response when adapter goes down or is removed
Bluetooth: Clean up logic in hci_cc_write_scan_enable
Bluetooth: Add timeout field to mgmt_set_discoverable
Bluetooth: Fix mgmt response when HCI_Write_Scan_Enable fails
Bluetooth: Convert power off mechanism to use delayed_work
Bluetooth: Remove redundant code from mgmt_block & mgmt_unblock
Bluetooth: Fix response for mgmt_start_discovery when powered off
Bluetooth: Update link key mgmt APIs to match latest spec.
Bluetooth: Add address type fields to mgmt messages that need them
Bluetooth: Pass full hci_dev struct to mgmt callbacks
Bluetooth: Move pending management command list into struct hci_dev
Bluetooth: Add missing hci_dev locking when calling mgmt functions
Bluetooth: Fix cancel_delayed_work_sync usage with locks
Bluetooth: Fix consistency with u16 integer type in mgmt pending_cmd
Bluetooth: Remove redundant hci_dev comparisons in mgmt lookups
Johannes Berg (38):
nl80211: fix HT capability attribute validation
cfg80211: allow setting TXQ parameters only in AP mode
cfg80211: fix cmp_ies
cfg80211: fix missing kernel-doc
iwlagn: update wowlan API
iwlagn: use 6 Mbps rate for no-CCK scans
mac80211: fix confusing parentheses
mac80211: exit cooked monitor RX early if there are none
nl80211: clean up genlmsg_end uses
cfg80211: annotate cfg80211_inform_bss
mac80211: preserve EOSP in QoS header
net: add wireless TX status socket option
mac80211: verify virtual interfaces in driver API
mac80211: add helper to free TX skb
mac80211: add support for control port protocol in AP mode
nl80211: allow subscribing to unexpected class3 frames
mac80211: support spurious class3 event
nl80211: advertise device AP SME
nl80211: add API to probe a client
mac80211: support client probe
cfg80211: allow registering to beacons
mac80211: report OBSS beacons
cfg80211: add event for unexpected 4addr frames
mac80211: send unexpected 4addr event
cfg80211/mac80211: allow management TX to not wait for ACK
nl80211: advertise socket TX status capability
mac80211: implement wifi TX status
mac80211: simplify scan state machine
mac80211/cfg80211: report monitor channel in wireless extensions
wireless: move ieee80211chan2mhz macro
nl80211: fix compiler warning
iwlagn: add P2P NoA to probe responses
iwlagn: fix NULL ptr deref when reprogramming sta w/o LQ
iwlagn: use per-vif AC parameters
iwlagn: explicitly program P2P QoS parameters
iwlagn: convert remain-on-channel duration to TU
iwlagn: don't always split remain-on-channel
mac80211: fix warning in ieee80211_probe_client
John W. Linville (7):
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-next
wireless: cleanup brcm80211 bits in drivers/net/wireless/Makefile
brcmsmac: fix warning in _initvars_srom_pci
libertas: release bss references and avoid warning from cfg80211_inform_bss
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Jouni Malinen (4):
mac80211_hwsim: Claim support for TDLS
ath9k: Advertise support for TDLS
ieee80211: Define cipher suite selector for WPI-SMS4
nl80211: Increase maximum NL80211_ATTR_KEY_SEQ length to 16
Julia Lawall (2):
net/mac80211/debugfs.c: use kstrtoul, etc
net/rfkill/core.c: use kstrtoul, etc
Jussi Kivilinna (1):
rndis_wlan: release BSS structures returned by cfg80211_inform_bss()
Larry Finger (1):
rtl8192cu: Add new device IDs
Luiz Augusto von Dentz (7):
Bluetooth: replace list_for_each with list_for_each_entry whenever possible
Bluetooth: set skbuffer priority based on L2CAP socket priority
Bluetooth: make use sk_priority to priritize RFCOMM packets
Bluetooth: prioritizing data over HCI
Bluetooth: handle priority change within quote
Bluetooth: recalculate priorities when channels are starving
Bluetooth: use buffer priority to mark URB_ISO_ASAP flag
Mat Martineau (9):
Bluetooth: Add BT_CHANNEL_POLICY socket option
Bluetooth: Change scope of the enable_hs module parameter
Bluetooth: Add channel policy to getsockopt/setsockopt
Bluetooth: Add AMP-related data and structures for channel signals
Bluetooth: Add signal handlers for channel creation
Bluetooth: Add definitions for L2CAP fixed channels
Bluetooth: Use symbolic values for the fixed channel map
Bluetooth: Add signal handlers for channel moves
Bluetooth: Guarantee BR-EDR device will be registered as hci0
Patrick Kelle (1):
minstrel: Remove unused function parameter in calc_rate_durations()
Paul Bolle (2):
Bluetooth: btusb: also be quiet when suspending
Bluetooth: btusb: hide more usb_submit_urb errors
Paul Fertser (1):
Bluetooth: ath3k: output firmware filename when request_firmware failed
Peter Hurley (1):
Bluetooth: hidp: safely acquire hci connection
Rafał Miłecki (2):
b43: fill ctl1 word on all newer PHYs, fix PHY errors
b43: HT-PHY: report signal to mac80211
Rajkumar Manoharan (7):
ath9k_hw: Update CCK spur mitigation for AR9462
ath9k: Add btcoex profile management support for AR9462
ath9k_hw: Updated AR9462 initval table to improve rx performance
ath9k_hw: Read and configure quick drop for AR9003
ath9k_hw: Read and configure xpa timing field
ath9k_hw: Fix channel list of CalFreqPeir for AR938x
ath9k_hw: Fix tx power settings for AR9003
Roland Vossen (14):
brcm80211: smac: removed support for SROM rev < 8
brcm80211: fmac: annotated little endian struct with _le
brmc80211: fmac: reworked next_bss()
brcm80211: fmac: changed two scan related structures
brcm80211: smac: indicate severe problems to Mac80211
brcm80211: smac: removed MPC related code
brcm80211: smac: removed MPC related variables
brcm80211: smac: removed down-on-watchdog MPC functionality
brcm80211: smac: removed down-on-rf-kill functionality
brcm80211: smac: bugfix for tx mute in brcms_b_init()
brcm80211: smac: fixed inconsistency in transmit mute
brcm80211: smac: modified Mac80211 callback interface
brcm80211: smac: mute transmit on ops_start
brcm80211: smac: changed check to confirm STA only support
Stanislav Yakovlev (1):
ipw2x00: remove unused function libipw_ratelimit_debug.
Stanislaw Gruszka (3):
mac80211: remove uneeded scan_chan variable
mac80211: remove useless brackets in ieee80211_cfg_on_oper_channel
mac80211: simplify ieee80211_work_work
Szymon Janc (3):
Bluetooth: rfcomm: Fix sleep in invalid context in rfcomm_security_cfm
Bluetooth: Increase HCI reset timeout in hci_dev_do_close
Bluetooth: Add debug print to l2cap_chan_create
Thomas Pedersen (6):
mac80211: comment allocation of mesh frames
mac80211: add HT IEs to mesh frames
mac80211: set HT capabilities for mesh peer
mac80211: allow frame aggregation for mesh
mac80211: QoS multicast frames have No Ack policy
mac80211: check if frame is really part of this BA
Todd Previte (1):
iwlwifi: Suppress noisy syslog messages when RF_KILL switch engaged
Venkataraman, Meenakshi (1):
iwlwifi: fix rate-scaling algorithm for BT combo devices
Wen-chien Jesse Sung (1):
Bluetooth: Add support for Broadcom BCM20702A0
Wey-Yi Guy (11):
iwlwifi: HW rev for 105 and 135 series
iwlwifi: two more SKUs for 6x05 series
iwlagn: check for SMPS mode
iwlwifi: remove un-supported SKUs
iwlwifi: move all mac80211 related functions to one place
iwlwifi: move more mac80211 callback function
iwlwifi: move hw_scan into _mac80211 file
iwlwifi: move station functions to mac80211
iwlwifi: Move the core suspend function to iwl-agn-lib
iwlwifi: set "echo" host command length
iwlwifi: check status before send command
Yogesh Ashok Powar (5):
mwifiex: fix ht_cap_info in ibss beacons
mwifiex: use existing helper function mwifiex_fill_cap_info
mwifiex: change return types to void
mwifiex: fix coding style
mwifiex: fix 'Smatch' warnings
arch/alpha/include/asm/socket.h | 3 +
arch/arm/include/asm/socket.h | 3 +
arch/avr32/include/asm/socket.h | 3 +
arch/cris/include/asm/socket.h | 3 +
arch/frv/include/asm/socket.h | 3 +
arch/h8300/include/asm/socket.h | 3 +
arch/ia64/include/asm/socket.h | 3 +
arch/m32r/include/asm/socket.h | 3 +
arch/m68k/include/asm/socket.h | 3 +
arch/mips/include/asm/socket.h | 3 +
arch/mn10300/include/asm/socket.h | 3 +
arch/parisc/include/asm/socket.h | 3 +
arch/powerpc/include/asm/socket.h | 3 +
arch/s390/include/asm/socket.h | 3 +
arch/sparc/include/asm/socket.h | 3 +
arch/xtensa/include/asm/socket.h | 3 +
drivers/bluetooth/ath3k.c | 15 +-
drivers/bluetooth/bfusb.c | 4 +-
drivers/bluetooth/bluecard_cs.c | 4 +-
drivers/bluetooth/bt3c_cs.c | 4 +-
drivers/bluetooth/btuart_cs.c | 4 +-
drivers/bluetooth/btusb.c | 19 +-
drivers/bluetooth/dtl1_cs.c | 4 +-
drivers/bluetooth/hci_vhci.c | 5 +-
drivers/net/wireless/Makefile | 6 +-
drivers/net/wireless/ath/ath.h | 1 +
drivers/net/wireless/ath/ath6kl/cfg80211.c | 3 +-
drivers/net/wireless/ath/ath6kl/init.c | 3 +-
drivers/net/wireless/ath/ath9k/Kconfig | 1 +
drivers/net/wireless/ath/ath9k/Makefile | 1 +
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 140 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 4 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 2 +
.../net/wireless/ath/ath9k/ar9462_2p0_initvals.h | 26 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 4 +
drivers/net/wireless/ath/ath9k/debug.c | 13 +-
drivers/net/wireless/ath/ath9k/eeprom.h | 3 +-
drivers/net/wireless/ath/ath9k/gpio.c | 7 +-
drivers/net/wireless/ath/ath9k/hw.c | 4 +-
drivers/net/wireless/ath/ath9k/hw.h | 11 +
drivers/net/wireless/ath/ath9k/init.c | 3 +
drivers/net/wireless/ath/ath9k/main.c | 12 +-
drivers/net/wireless/ath/ath9k/mci.c | 254 +++
drivers/net/wireless/ath/ath9k/mci.h | 118 ++
drivers/net/wireless/ath/ath9k/xmit.c | 5 +-
drivers/net/wireless/ath/regd.c | 2 +
drivers/net/wireless/b43/xmit.c | 15 +-
drivers/net/wireless/b43/xmit.h | 16 +-
drivers/net/wireless/brcm80211/brcmfmac/Makefile | 3 +-
drivers/net/wireless/brcm80211/brcmfmac/bcmchip.h | 7 -
drivers/net/wireless/brcm80211/brcmfmac/dhd.h | 18 +-
.../net/wireless/brcm80211/brcmfmac/dhd_common.c | 5 +-
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 301 ++---
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 709 +-------
.../net/wireless/brcm80211/brcmfmac/sdio_chip.c | 622 +++++++
.../net/wireless/brcm80211/brcmfmac/sdio_chip.h | 136 ++
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 41 +-
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.h | 9 -
drivers/net/wireless/brcm80211/brcmsmac/aiutils.h | 76 -
drivers/net/wireless/brcm80211/brcmsmac/ampdu.c | 6 +-
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 118 --
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 44 +-
drivers/net/wireless/brcm80211/brcmsmac/dma.h | 3 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 121 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.h | 2 +
drivers/net/wireless/brcm80211/brcmsmac/main.c | 687 +++-----
drivers/net/wireless/brcm80211/brcmsmac/main.h | 19 +-
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 10 +-
.../net/wireless/brcm80211/brcmsmac/phy/phy_int.h | 5 -
.../net/wireless/brcm80211/brcmsmac/phy/phy_n.c | 38 +-
drivers/net/wireless/brcm80211/brcmsmac/pmu.c | 1 +
drivers/net/wireless/brcm80211/brcmsmac/pub.h | 38 +-
drivers/net/wireless/brcm80211/brcmsmac/rate.h | 5 +-
drivers/net/wireless/brcm80211/brcmsmac/srom.c | 469 +-----
drivers/net/wireless/brcm80211/brcmsmac/srom.h | 5 -
drivers/net/wireless/brcm80211/brcmutil/utils.c | 218 +--
.../net/wireless/brcm80211/include/brcmu_utils.h | 30 +-
drivers/net/wireless/brcm80211/include/defs.h | 1 -
drivers/net/wireless/brcm80211/include/soc.h | 12 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 8 +
drivers/net/wireless/ipw2x00/libipw.h | 8 -
drivers/net/wireless/iwlwifi/Makefile | 2 +-
drivers/net/wireless/iwlwifi/iwl-2000.c | 20 -
drivers/net/wireless/iwlwifi/iwl-6000.c | 10 -
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 358 ++++
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-agn-rx.c | 49 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 13 +-
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 78 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 154 ++-
drivers/net/wireless/iwlwifi/iwl-agn.c | 1781 ++------------------
drivers/net/wireless/iwlwifi/iwl-agn.h | 31 +-
drivers/net/wireless/iwlwifi/iwl-cfg.h | 6 -
drivers/net/wireless/iwlwifi/iwl-commands.h | 27 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 307 +----
drivers/net/wireless/iwlwifi/iwl-core.h | 14 -
drivers/net/wireless/iwlwifi/iwl-csr.h | 4 +-
drivers/net/wireless/iwlwifi/iwl-debug.h | 19 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 34 +-
drivers/net/wireless/iwlwifi/iwl-devtrace.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-devtrace.h | 23 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 142 +-
drivers/net/wireless/iwlwifi/iwl-mac80211.c | 1632 ++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl-pci.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 50 +-
drivers/net/wireless/iwlwifi/iwl-sv-open.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h | 35 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 52 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 23 +-
drivers/net/wireless/iwlwifi/iwl-trans.h | 50 +-
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 15 +-
drivers/net/wireless/libertas/cfg.c | 25 +-
drivers/net/wireless/mac80211_hwsim.c | 2 +
drivers/net/wireless/mwifiex/11n_rxreorder.c | 18 +-
drivers/net/wireless/mwifiex/cfg80211.c | 4 +-
drivers/net/wireless/mwifiex/fw.h | 2 +-
drivers/net/wireless/mwifiex/init.c | 4 +-
drivers/net/wireless/mwifiex/join.c | 96 +-
drivers/net/wireless/mwifiex/pcie.c | 11 +-
drivers/net/wireless/mwifiex/scan.c | 10 +-
drivers/net/wireless/mwifiex/sdio.c | 4 +-
drivers/net/wireless/mwifiex/sta_rx.c | 12 +-
drivers/net/wireless/orinoco/scan.c | 16 +-
drivers/net/wireless/rndis_wlan.c | 23 +-
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 36 +-
drivers/net/wireless/wl12xx/scan.c | 2 +-
include/asm-generic/socket.h | 3 +
include/linux/errqueue.h | 3 +-
include/linux/ieee80211.h | 6 +
include/linux/nl80211.h | 111 ++
include/linux/skbuff.h | 19 +-
include/net/bluetooth/bluetooth.h | 29 +-
include/net/bluetooth/hci.h | 22 +
include/net/bluetooth/hci_core.h | 136 ++-
include/net/bluetooth/l2cap.h | 416 ++++-
include/net/bluetooth/mgmt.h | 47 +-
include/net/cfg80211.h | 112 ++-
include/net/ieee80211_radiotap.h | 8 -
include/net/mac80211.h | 35 +-
include/net/nfc/nci.h | 109 +-
include/net/nfc/nci_core.h | 13 +-
include/net/sock.h | 6 +
net/bluetooth/bnep/core.c | 13 +-
net/bluetooth/cmtp/core.c | 13 +-
net/bluetooth/hci_conn.c | 71 +-
net/bluetooth/hci_core.c | 399 ++++--
net/bluetooth/hci_event.c | 221 ++-
net/bluetooth/hci_sysfs.c | 40 +-
net/bluetooth/hidp/core.c | 157 +-
net/bluetooth/l2cap_core.c | 963 ++++++++---
net/bluetooth/l2cap_sock.c | 90 +-
net/bluetooth/mgmt.c | 500 +++---
net/bluetooth/rfcomm/core.c | 65 +-
net/bluetooth/rfcomm/sock.c | 2 +
net/bluetooth/rfcomm/tty.c | 45 +-
net/bluetooth/smp.c | 3 +-
net/core/skbuff.c | 20 +
net/core/sock.c | 9 +
net/mac80211/agg-rx.c | 3 +-
net/mac80211/agg-tx.c | 10 +-
net/mac80211/cfg.c | 165 ++-
net/mac80211/debugfs.c | 2 +-
net/mac80211/driver-ops.h | 68 +-
net/mac80211/ht.c | 3 +-
net/mac80211/ibss.c | 3 +
net/mac80211/ieee80211_i.h | 29 +-
net/mac80211/iface.c | 44 +-
net/mac80211/key.c | 9 +-
net/mac80211/main.c | 39 +-
net/mac80211/mesh.c | 70 +-
net/mac80211/mesh.h | 7 +
net/mac80211/mesh_hwmp.c | 52 +-
net/mac80211/mesh_pathtbl.c | 3 -
net/mac80211/mesh_plink.c | 50 +-
net/mac80211/mlme.c | 89 +-
net/mac80211/pm.c | 2 +-
net/mac80211/rc80211_minstrel.c | 7 +-
net/mac80211/rx.c | 73 +-
net/mac80211/scan.c | 199 +--
net/mac80211/sta_info.c | 8 +-
net/mac80211/sta_info.h | 8 +
net/mac80211/status.c | 87 +-
net/mac80211/tx.c | 110 ++-
net/mac80211/util.c | 126 ++-
net/mac80211/wme.c | 10 +-
net/mac80211/work.c | 46 +-
net/mac80211/wpa.c | 9 +-
net/nfc/nci/core.c | 18 +-
net/nfc/nci/data.c | 5 +-
net/nfc/nci/lib.c | 8 +-
net/nfc/nci/ntf.c | 152 +-
net/nfc/nci/rsp.c | 83 +-
net/rfkill/core.c | 4 +-
net/socket.c | 18 +
net/wireless/core.c | 4 +
net/wireless/core.h | 4 +-
net/wireless/mlme.c | 35 +-
net/wireless/nl80211.c | 419 ++++--
net/wireless/nl80211.h | 5 +
net/wireless/scan.c | 130 ++-
net/wireless/wext-compat.c | 12 +
205 files changed, 9141 insertions(+), 6576 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath9k/mci.c
create mode 100644 drivers/net/wireless/ath/ath9k/mci.h
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.h
create mode 100644 drivers/net/wireless/iwlwifi/iwl-mac80211.c
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: root_lock vs. device's TX lock
From: Dave Taht @ 2011-11-17 18:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, Linux Netdev List
In-Reply-To: <1321550786.2751.83.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, Nov 17, 2011 at 6:26 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 17 novembre 2011 à 17:34 +0100, Eric Dumazet a écrit :
>> Le jeudi 17 novembre 2011 à 08:10 -0800, Tom Herbert a écrit :
>> > From sch_direct_xmit:
>> >
>> > /* And release qdisc */
>> > spin_unlock(root_lock);
>> >
>> > HARD_TX_LOCK(dev, txq, smp_processor_id());
>> > if (!netif_tx_queue_frozen_or_stopped(txq))
>> > ret = dev_hard_start_xmit(skb, dev, txq);
>> >
>> > HARD_TX_UNLOCK(dev, txq);
>> >
>> > spin_lock(root_lock);
>> >
>> > This is a lot of lock manipulation to basically switch from one lock
>> > to another and possibly thrashing just to send a packet. I am
>> > thinking that if the there is a 1-1 correspondence between qdisc and
>> > device queue then we could actually use the device's lock as the root
>> > lock for the qdisc. So in that case, we would need to touch any locks
>> > from sch_direct_xmit (just hold root lock which is already device lock
>> > for the duration).
>> >
>> > Is there any reason why this couldn't work?
>>
>> But we have to dirty part of Qdisc anyway ?
>> (state, bstats, q, ...)
>>
>
> Also we want to permit other cpus to enqueue packets to Qdisc while our
> cpu is busy in network driver ndo_start_xmit()
>
> For complex Qdisc / tc setups (potentially touching a lot of cache
> lines), we could eventually add a small ring buffer so that the cpu
> doing the ndo_start_xmit() also queues the packets into Qdisc.
>
> This ringbuffer could use a lockless algo. (we currently use the
> secondary 'busylock' to serialize other cpus, but each cpu calls qdisc
> enqueue itself.)
I was thinking ringbuffering might also help in adding a 'grouper'
abstraction to the dequeuing side.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* Re: [PATCH net-next v6 7/9] forcedeth: implement ndo_get_stats64() API
From: Eric Dumazet @ 2011-11-17 17:47 UTC (permalink / raw)
To: David Decotigny
Cc: netdev, linux-kernel, David S. Miller, Ian Campbell, Jeff Kirsher,
Ben Hutchings, Jiri Pirko, Joe Perches, Szymon Janc,
Richard Jones, Ayaz Abdulla
In-Reply-To: <CAG88wWbiwVKUVtQxV=FzBTfaCngeGYXL9M_00NQKCgbEqic4-w@mail.gmail.com>
Le jeudi 17 novembre 2011 à 09:39 -0800, David Decotigny a écrit :
> On Wed, Nov 16, 2011 at 10:34 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > You should use the _bh variants.
>
> Oooops. It's unforgivable: the sky2 implementation you mentioned in a
> previous message was the simple and right model to follow. Grrrrrr.
> Sending a fix shortly.
>
Dont worry, we all did the exact same mistakes :)
^ permalink raw reply
* Re: [PATCH net-next v6 7/9] forcedeth: implement ndo_get_stats64() API
From: David Decotigny @ 2011-11-17 17:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, David S. Miller, Ian Campbell, Jeff Kirsher,
Ben Hutchings, Jiri Pirko, Joe Perches, Szymon Janc,
Richard Jones, Ayaz Abdulla
In-Reply-To: <1321511678.3274.30.camel@edumazet-laptop>
On Wed, Nov 16, 2011 at 10:34 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> You should use the _bh variants.
Oooops. It's unforgivable: the sky2 implementation you mentioned in a
previous message was the simple and right model to follow. Grrrrrr.
Sending a fix shortly.
Thanks!
^ permalink raw reply
* Re: Unable to flush ICMP redirect routes in kernel 3.0+
From: Eric Dumazet @ 2011-11-17 17:38 UTC (permalink / raw)
To: Flavio Leitner; +Cc: David Miller, Ivan Zahariev, netdev, Vasiliy Kulikov
In-Reply-To: <1321550302.2751.81.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le jeudi 17 novembre 2011 à 18:18 +0100, Eric Dumazet a écrit :
> Le jeudi 17 novembre 2011 à 15:01 -0200, Flavio Leitner a écrit :
>
> > Right, so the loop trying different oif and saddr isn't working at
> > all because __ip_route_output_key() will create a route in the first
> > attempt. Looks like you're right and we need the 'create' parameter
> > in __ip_route_output_key().
>
> And we have to loop on all possible keys combinations.
>
> (like code before David commit (f39925dbde77 ipv4: Cache learned
> redirect information in inetpeer.) : it had a goto do_next;
>
> I am preparing a patch.
>
Unfortunately its not enough.
For some reason, ipv4_dst_check() is not called later, so we cant call
ipv4_dst_check() and change
rt->rt_gateway = peer->redirect_learned.a4;
dst->obsolete strikes again.
^ permalink raw reply
* Re: Unable to flush ICMP redirect routes in kernel 3.0+
From: Flavio Leitner @ 2011-11-17 17:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Ivan Zahariev, netdev, Vasiliy Kulikov
In-Reply-To: <1321550302.2751.81.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, 17 Nov 2011 18:18:22 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 17 novembre 2011 à 15:01 -0200, Flavio Leitner a écrit :
>
> > Right, so the loop trying different oif and saddr isn't working at
> > all because __ip_route_output_key() will create a route in the first
> > attempt. Looks like you're right and we need the 'create' parameter
> > in __ip_route_output_key().
>
> And we have to loop on all possible keys combinations.
>
> (like code before David commit (f39925dbde77 ipv4: Cache learned
> redirect information in inetpeer.) : it had a goto do_next;
That is correct. I realize that now.
> I am preparing a patch.
thank you.
fbl
^ permalink raw reply
* Re: root_lock vs. device's TX lock
From: Eric Dumazet @ 2011-11-17 17:26 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Netdev List
In-Reply-To: <1321547698.2751.68.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le jeudi 17 novembre 2011 à 17:34 +0100, Eric Dumazet a écrit :
> Le jeudi 17 novembre 2011 à 08:10 -0800, Tom Herbert a écrit :
> > From sch_direct_xmit:
> >
> > /* And release qdisc */
> > spin_unlock(root_lock);
> >
> > HARD_TX_LOCK(dev, txq, smp_processor_id());
> > if (!netif_tx_queue_frozen_or_stopped(txq))
> > ret = dev_hard_start_xmit(skb, dev, txq);
> >
> > HARD_TX_UNLOCK(dev, txq);
> >
> > spin_lock(root_lock);
> >
> > This is a lot of lock manipulation to basically switch from one lock
> > to another and possibly thrashing just to send a packet. I am
> > thinking that if the there is a 1-1 correspondence between qdisc and
> > device queue then we could actually use the device's lock as the root
> > lock for the qdisc. So in that case, we would need to touch any locks
> > from sch_direct_xmit (just hold root lock which is already device lock
> > for the duration).
> >
> > Is there any reason why this couldn't work?
>
> But we have to dirty part of Qdisc anyway ?
> (state, bstats, q, ...)
>
Also we want to permit other cpus to enqueue packets to Qdisc while our
cpu is busy in network driver ndo_start_xmit()
For complex Qdisc / tc setups (potentially touching a lot of cache
lines), we could eventually add a small ring buffer so that the cpu
doing the ndo_start_xmit() also queues the packets into Qdisc.
This ringbuffer could use a lockless algo. (we currently use the
secondary 'busylock' to serialize other cpus, but each cpu calls qdisc
enqueue itself.)
^ permalink raw reply
* Re: Unable to flush ICMP redirect routes in kernel 3.0+
From: Eric Dumazet @ 2011-11-17 17:18 UTC (permalink / raw)
To: Flavio Leitner; +Cc: David Miller, Ivan Zahariev, netdev, Vasiliy Kulikov
In-Reply-To: <20111117150145.25e01a75@asterix.rh>
Le jeudi 17 novembre 2011 à 15:01 -0200, Flavio Leitner a écrit :
> Right, so the loop trying different oif and saddr isn't working at
> all because __ip_route_output_key() will create a route in the first
> attempt. Looks like you're right and we need the 'create' parameter
> in __ip_route_output_key().
And we have to loop on all possible keys combinations.
(like code before David commit (f39925dbde77 ipv4: Cache learned
redirect information in inetpeer.) : it had a goto do_next;
I am preparing a patch.
^ permalink raw reply
* Re: Unable to flush ICMP redirect routes in kernel 3.0+
From: Flavio Leitner @ 2011-11-17 17:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Ivan Zahariev, netdev, Vasiliy Kulikov
In-Reply-To: <1321548319.2751.70.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, 17 Nov 2011 17:45:19 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 17 novembre 2011 à 14:40 -0200, Flavio Leitner a écrit :
> > On Thu, 17 Nov 2011 17:31:50 +0100
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > > Le jeudi 17 novembre 2011 à 13:37 -0200, Flavio Leitner a écrit :
> > > > On Thu, 17 Nov 2011 15:40:20 +0100
> > > > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > >
> > > > > [PATCH] ping: dont increment ICMP_MIB_INERRORS
> > > > >
> > > > > ping module incorrectly increments ICMP_MIB_INERRORS if feeded
> > > > > with a frame not belonging to its own sockets.
> > > > >
> > > > > RFC 2011 states that ICMP_MIB_INERRORS should count "the
> > > > > number of ICMP messages which the entiry received but
> > > > > determined as having ICMP-specific errors (bad ICMP
> > > > > checksums, bad length, etc.)."
> > > > >
> > > > > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > > > > CC: Vasiliy Kulikov <segoon@openwall.com>
> > > >
> > > > Yeah, they aren't ICMP specific errors and the callers already
> > > > checked for checksum, lengths, and etc.. increasing that counter
> > > > when necessary.
> > > >
> > > > Acked-by: Flavio Leitner <fbl@redhat.com>
> > >
> > > Thanks
> > >
> > > By the way, redirects dont work at all in net-next
> >
> > Could you be more specific? It seems to be working here.
> >
> > > Probably coming from your commit 7cc9150ebe8ec0
> > > (route: fix ICMP redirect validation)
> > >
> > > Since calling __ip_route_output_key() will create the route with
> > > s = 0, l = 0 (forcing saddr and dev->ifindex) selectors...
> > >
> > > We have to add a 'create' parameter to __ip_route_output_key() so
> > > that ip_rt_redirect() doesnt create a route, only find the
> > > existing one in cache ?
> >
> > It should receive redirect after sending a packet, so the route
> > should be ready at this point.
>
> I receive the redirect, but the rt->peer is updated on a different
> route than the one used by my ping command.
>
> Its updated on the specific route (source address forced, output
> device forced), not on the wildcarded route my ping is using.
>
> So next packets are still sent on old gateway...
Right, so the loop trying different oif and saddr isn't working at
all because __ip_route_output_key() will create a route in the first
attempt. Looks like you're right and we need the 'create' parameter
in __ip_route_output_key().
thanks,
fbl
^ permalink raw reply
* Re: [PATCH 1/6] sky2: fix hang on shutdown (and other irq issues)
From: Stephen Hemminger @ 2011-11-17 17:01 UTC (permalink / raw)
To: Sven Joachim; +Cc: davem, netdev
In-Reply-To: <87r517w2z0.fsf@turtle.gmx.de>
On Thu, 17 Nov 2011 09:46:43 +0100
Sven Joachim <svenjoac@gmx.de> wrote:
> On 2011-11-17 00:42 +0100, Stephen Hemminger wrote:
>
> > There are several problems with recent change to how IRQ's are setup.
> > * synchronize_irq in sky2_shutdown would hang because there
> > was no IRQ setup.
> > * when device was set to down, some IRQ bits left enabled so a
> > hardware error would produce IRQ with no handler
> > * quick link on Optima chip set was enabled without handler
> > * suspend/resume would leave IRQ on with no handler if device
> > was down
>
> Unfortunately, this patch does not fix the hang at shutdown for me. :-(
You are probably stuck in some part of the code path in sky2_shutdown.
The best debug for this is sprinkling the code printk's. That is how I
narrowed the problem down to synchronize_irq.
^ permalink raw reply
* Re: Unable to flush ICMP redirect routes in kernel 3.0+
From: Eric Dumazet @ 2011-11-17 16:57 UTC (permalink / raw)
To: Flavio Leitner; +Cc: David Miller, Ivan Zahariev, netdev, Vasiliy Kulikov
In-Reply-To: <1321548319.2751.70.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Some traces :
$ ping -c 3 213.254.248.147
PING 213.254.248.147 (213.254.248.147) 56(84) bytes of data.
>From 192.168.20.108: icmp_seq=1 Redirect Host(New nexthop: 192.168.20.254)
2011/10/17 17:55:56.827 64 bytes from 213.254.248.147: icmp_seq=1 ttl=55 time=10.4 ms
>From 192.168.20.108: icmp_seq=2 Redirect Host(New nexthop: 192.168.20.254)
2011/10/17 17:55:57.828 64 bytes from 213.254.248.147: icmp_seq=2 ttl=55 time=9.87 ms
>From 192.168.20.108: icmp_seq=3 Redirect Host(New nexthop: 192.168.20.254)
2011/10/17 17:55:58.829 64 bytes from 213.254.248.147: icmp_seq=3 ttl=55 time=10.2 ms
--- 213.254.248.147 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 9.871/10.198/10.478/0.275 ms
$ ip ro list cache match 213.254.248.147
213.254.248.147 from 192.168.20.110 via 192.168.20.108 dev vlan.103
cache ipid 0x7187
213.254.248.147 from 192.168.20.110 via 192.168.20.254 dev vlan.103
cache <redirected> ipid 0x7187
213.254.248.147 via 192.168.20.108 dev vlan.103 src 192.168.20.110
cache
$ ip ro get 213.254.248.147
213.254.248.147 via 192.168.20.108 dev vlan.103 src 192.168.20.110
cache
^ permalink raw reply
* Re: Unable to flush ICMP redirect routes in kernel 3.0+
From: Vasiliy Kulikov @ 2011-11-17 16:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Flavio Leitner, David Miller, Ivan Zahariev, netdev
In-Reply-To: <1321540820.2751.47.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, Nov 17, 2011 at 15:40 +0100, Eric Dumazet wrote:
> [PATCH] ping: dont increment ICMP_MIB_INERRORS
>
> ping module incorrectly increments ICMP_MIB_INERRORS if feeded with a
> frame not belonging to its own sockets.
>
> RFC 2011 states that ICMP_MIB_INERRORS should count "the number of ICMP
> messages which the entiry received but determined as having
> ICMP-specific errors (bad ICMP checksums, bad length, etc.)."
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Vasiliy Kulikov <segoon@openwall.com>
Thanks,
> ---
> net/ipv4/ping.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
> index a06f73f..43d4c3b 100644
> --- a/net/ipv4/ping.c
> +++ b/net/ipv4/ping.c
> @@ -339,7 +339,6 @@ void ping_err(struct sk_buff *skb, u32 info)
> sk = ping_v4_lookup(net, iph->daddr, iph->saddr,
> ntohs(icmph->un.echo.id), skb->dev->ifindex);
> if (sk == NULL) {
> - ICMP_INC_STATS_BH(net, ICMP_MIB_INERRORS);
> pr_debug("no socket, dropping\n");
> return; /* No socket for error */
> }
> @@ -679,7 +678,6 @@ static int ping_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> pr_debug("ping_queue_rcv_skb(sk=%p,sk->num=%d,skb=%p)\n",
> inet_sk(sk), inet_sk(sk)->inet_num, skb);
> if (sock_queue_rcv_skb(sk, skb) < 0) {
> - ICMP_INC_STATS_BH(sock_net(sk), ICMP_MIB_INERRORS);
> kfree_skb(skb);
> pr_debug("ping_queue_rcv_skb -> failed\n");
> return -1;
>
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: Unable to flush ICMP redirect routes in kernel 3.0+
From: Eric Dumazet @ 2011-11-17 16:45 UTC (permalink / raw)
To: Flavio Leitner; +Cc: David Miller, Ivan Zahariev, netdev, Vasiliy Kulikov
In-Reply-To: <20111117144038.61b0525b@asterix.rh>
Le jeudi 17 novembre 2011 à 14:40 -0200, Flavio Leitner a écrit :
> On Thu, 17 Nov 2011 17:31:50 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Le jeudi 17 novembre 2011 à 13:37 -0200, Flavio Leitner a écrit :
> > > On Thu, 17 Nov 2011 15:40:20 +0100
> > > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > >
> > > > [PATCH] ping: dont increment ICMP_MIB_INERRORS
> > > >
> > > > ping module incorrectly increments ICMP_MIB_INERRORS if feeded
> > > > with a frame not belonging to its own sockets.
> > > >
> > > > RFC 2011 states that ICMP_MIB_INERRORS should count "the number of
> > > > ICMP messages which the entiry received but determined as having
> > > > ICMP-specific errors (bad ICMP checksums, bad length, etc.)."
> > > >
> > > > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > > > CC: Vasiliy Kulikov <segoon@openwall.com>
> > >
> > > Yeah, they aren't ICMP specific errors and the callers already
> > > checked for checksum, lengths, and etc.. increasing that counter
> > > when necessary.
> > >
> > > Acked-by: Flavio Leitner <fbl@redhat.com>
> >
> > Thanks
> >
> > By the way, redirects dont work at all in net-next
>
> Could you be more specific? It seems to be working here.
>
> > Probably coming from your commit 7cc9150ebe8ec0
> > (route: fix ICMP redirect validation)
> >
> > Since calling __ip_route_output_key() will create the route with s =
> > 0, l = 0 (forcing saddr and dev->ifindex) selectors...
> >
> > We have to add a 'create' parameter to __ip_route_output_key() so that
> > ip_rt_redirect() doesnt create a route, only find the existing one in
> > cache ?
>
> It should receive redirect after sending a packet, so the route
> should be ready at this point.
I receive the redirect, but the rt->peer is updated on a different route
than the one used by my ping command.
Its updated on the specific route (source address forced, output device
forced), not on the wildcarded route my ping is using.
So next packets are still sent on old gateway...
^ permalink raw reply
* Re: Unable to flush ICMP redirect routes in kernel 3.0+
From: Flavio Leitner @ 2011-11-17 16:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Ivan Zahariev, netdev, Vasiliy Kulikov
In-Reply-To: <1321547510.2751.66.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, 17 Nov 2011 17:31:50 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 17 novembre 2011 à 13:37 -0200, Flavio Leitner a écrit :
> > On Thu, 17 Nov 2011 15:40:20 +0100
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > > [PATCH] ping: dont increment ICMP_MIB_INERRORS
> > >
> > > ping module incorrectly increments ICMP_MIB_INERRORS if feeded
> > > with a frame not belonging to its own sockets.
> > >
> > > RFC 2011 states that ICMP_MIB_INERRORS should count "the number of
> > > ICMP messages which the entiry received but determined as having
> > > ICMP-specific errors (bad ICMP checksums, bad length, etc.)."
> > >
> > > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > > CC: Vasiliy Kulikov <segoon@openwall.com>
> >
> > Yeah, they aren't ICMP specific errors and the callers already
> > checked for checksum, lengths, and etc.. increasing that counter
> > when necessary.
> >
> > Acked-by: Flavio Leitner <fbl@redhat.com>
>
> Thanks
>
> By the way, redirects dont work at all in net-next
Could you be more specific? It seems to be working here.
> Probably coming from your commit 7cc9150ebe8ec0
> (route: fix ICMP redirect validation)
>
> Since calling __ip_route_output_key() will create the route with s =
> 0, l = 0 (forcing saddr and dev->ifindex) selectors...
>
> We have to add a 'create' parameter to __ip_route_output_key() so that
> ip_rt_redirect() doesnt create a route, only find the existing one in
> cache ?
It should receive redirect after sending a packet, so the route
should be ready at this point.
fbl
^ permalink raw reply
* Re: root_lock vs. device's TX lock
From: Eric Dumazet @ 2011-11-17 16:34 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Netdev List
In-Reply-To: <CA+mtBx8sHDprEct3zgGXXKEESK6i0FYnFS-_z35FOyVQjS9R4Q@mail.gmail.com>
Le jeudi 17 novembre 2011 à 08:10 -0800, Tom Herbert a écrit :
> From sch_direct_xmit:
>
> /* And release qdisc */
> spin_unlock(root_lock);
>
> HARD_TX_LOCK(dev, txq, smp_processor_id());
> if (!netif_tx_queue_frozen_or_stopped(txq))
> ret = dev_hard_start_xmit(skb, dev, txq);
>
> HARD_TX_UNLOCK(dev, txq);
>
> spin_lock(root_lock);
>
> This is a lot of lock manipulation to basically switch from one lock
> to another and possibly thrashing just to send a packet. I am
> thinking that if the there is a 1-1 correspondence between qdisc and
> device queue then we could actually use the device's lock as the root
> lock for the qdisc. So in that case, we would need to touch any locks
> from sch_direct_xmit (just hold root lock which is already device lock
> for the duration).
>
> Is there any reason why this couldn't work?
But we have to dirty part of Qdisc anyway ?
(state, bstats, q, ...)
^ permalink raw reply
* [patch net-next] team: replace kmalloc+memcpy by kmemdup
From: Jiri Pirko @ 2011-11-17 16:32 UTC (permalink / raw)
To: netdev
Cc: davem, eric.dumazet, bhutchings, shemminger, andy, fbl, jzupka,
ivecera
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/team/team.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index c48ef19..064155d 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -104,19 +104,15 @@ int team_options_register(struct team *team,
if (!dst_opts)
return -ENOMEM;
for (i = 0; i < option_count; i++, option++) {
- struct team_option *dst_opt;
-
if (__team_find_option(team, option->name)) {
err = -EEXIST;
goto rollback;
}
- dst_opt = kmalloc(sizeof(*option), GFP_KERNEL);
- if (!dst_opt) {
+ dst_opts[i] = kmemdup(option, sizeof(*option), GFP_KERNEL);
+ if (!dst_opts[i]) {
err = -ENOMEM;
goto rollback;
}
- memcpy(dst_opt, option, sizeof(*option));
- dst_opts[i] = dst_opt;
}
for (i = 0; i < option_count; i++)
--
1.7.6
^ permalink raw reply related
* Re: Unable to flush ICMP redirect routes in kernel 3.0+
From: Eric Dumazet @ 2011-11-17 16:31 UTC (permalink / raw)
To: Flavio Leitner; +Cc: David Miller, Ivan Zahariev, netdev, Vasiliy Kulikov
In-Reply-To: <20111117133724.59684d28@asterix.rh>
Le jeudi 17 novembre 2011 à 13:37 -0200, Flavio Leitner a écrit :
> On Thu, 17 Nov 2011 15:40:20 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > [PATCH] ping: dont increment ICMP_MIB_INERRORS
> >
> > ping module incorrectly increments ICMP_MIB_INERRORS if feeded with a
> > frame not belonging to its own sockets.
> >
> > RFC 2011 states that ICMP_MIB_INERRORS should count "the number of
> > ICMP messages which the entiry received but determined as having
> > ICMP-specific errors (bad ICMP checksums, bad length, etc.)."
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > CC: Vasiliy Kulikov <segoon@openwall.com>
>
> Yeah, they aren't ICMP specific errors and the callers already
> checked for checksum, lengths, and etc.. increasing that counter
> when necessary.
>
> Acked-by: Flavio Leitner <fbl@redhat.com>
Thanks
By the way, redirects dont work at all in net-next
Probably coming from your commit 7cc9150ebe8ec0
(route: fix ICMP redirect validation)
Since calling __ip_route_output_key() will create the route with s = 0,
l = 0 (forcing saddr and dev->ifindex) selectors...
We have to add a 'create' parameter to __ip_route_output_key() so that
ip_rt_redirect() doesnt create a route, only find the existing one in
cache ?
^ permalink raw reply
* root_lock vs. device's TX lock
From: Tom Herbert @ 2011-11-17 16:10 UTC (permalink / raw)
To: Linux Netdev List
>From sch_direct_xmit:
/* And release qdisc */
spin_unlock(root_lock);
HARD_TX_LOCK(dev, txq, smp_processor_id());
if (!netif_tx_queue_frozen_or_stopped(txq))
ret = dev_hard_start_xmit(skb, dev, txq);
HARD_TX_UNLOCK(dev, txq);
spin_lock(root_lock);
This is a lot of lock manipulation to basically switch from one lock
to another and possibly thrashing just to send a packet. I am
thinking that if the there is a 1-1 correspondence between qdisc and
device queue then we could actually use the device's lock as the root
lock for the qdisc. So in that case, we would need to touch any locks
from sch_direct_xmit (just hold root lock which is already device lock
for the duration).
Is there any reason why this couldn't work?
^ 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