* Re: [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Troy Kisky @ 2011-09-19 22:39 UTC (permalink / raw)
To: Shawn Guo; +Cc: netdev, David S. Miller, linux-arm-kernel, patches
In-Reply-To: <1316346852-17090-4-git-send-email-shawn.guo@linaro.org>
On 9/18/2011 4:54 AM, Shawn Guo wrote:
> With the unnecessary 1 bit left-shift on fep->phy_speed during the
> calculation, the phy_speed always runs at the half frequency of the
> optimal one 2.5 MHz.
>
> The patch removes that 1 bit left-shift to get the optimal phy_speed.
>
> Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
> ---
> drivers/net/fec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 5ef0e34..04206e4 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> /*
> * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
> */
> - fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000)<< 1;
> + fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
>
> fep->mii_bus = mdiobus_alloc();
Do you need to round up to an even value? Is the hardware documentation
wrong?
Does this need a quirk? What boards has this been verified to fix?
Thanks
Troy
^ permalink raw reply
* [PATCH] intel: Convert <FOO>_LENGTH_OF_ADDRESS to ETH_ALEN
From: Joe Perches @ 2011-09-19 22:28 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <20110919143629.00007675@unknown>
Use the normal #defines not module specific ones.
Signed-off-by: Joe Perches <joe@perches.com>
---
Here are the other, not ixgb uses of LENGTH_OF_ADDRESS
converted to ETH_ALEN. Compile tested allyesconfig only.
drivers/net/ethernet/intel/e1000/e1000_hw.h | 1 -
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 8 +++-----
drivers/net/ethernet/intel/ixgbevf/defines.h | 1 -
drivers/net/ethernet/intel/ixgbevf/vf.c | 4 ++--
5 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.h b/drivers/net/ethernet/intel/e1000/e1000_hw.h
index 5c9a840..cf7e3c0 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_hw.h
+++ b/drivers/net/ethernet/intel/e1000/e1000_hw.h
@@ -448,7 +448,6 @@ void e1000_io_write(struct e1000_hw *hw, unsigned long port, u32 value);
#define E1000_DEV_ID_INTEL_CE4100_GBE 0x2E6E
#define NODE_ADDRESS_SIZE 6
-#define ETH_LENGTH_OF_ADDRESS 6
/* MAC decode size is 128K - This is the size of BAR0 */
#define MAC_DECODE_SIZE (128 * 1024)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index d99d01e..29e092c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -363,7 +363,7 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
/* reply to reset with ack and vf mac address */
msgbuf[0] = IXGBE_VF_RESET | IXGBE_VT_MSGTYPE_ACK;
- memcpy(new_mac, vf_mac, IXGBE_ETH_LENGTH_OF_ADDRESS);
+ memcpy(new_mac, vf_mac, ETH_ALEN);
/*
* Piggyback the multicast filter type so VF can compute the
* correct vectors
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 9f618ee..ef34606 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -1699,8 +1699,6 @@ enum {
#define IXGBE_NVM_POLL_WRITE 1 /* Flag for polling for write complete */
#define IXGBE_NVM_POLL_READ 0 /* Flag for polling for read complete */
-#define IXGBE_ETH_LENGTH_OF_ADDRESS 6
-
#define IXGBE_EEPROM_PAGE_SIZE_MAX 128
#define IXGBE_EEPROM_RD_BUFFER_MAX_COUNT 512 /* EEPROM words # read in burst */
#define IXGBE_EEPROM_WR_BUFFER_MAX_COUNT 256 /* EEPROM words # wr in burst */
@@ -2737,9 +2735,9 @@ struct ixgbe_eeprom_info {
struct ixgbe_mac_info {
struct ixgbe_mac_operations ops;
enum ixgbe_mac_type type;
- u8 addr[IXGBE_ETH_LENGTH_OF_ADDRESS];
- u8 perm_addr[IXGBE_ETH_LENGTH_OF_ADDRESS];
- u8 san_addr[IXGBE_ETH_LENGTH_OF_ADDRESS];
+ u8 addr[ETH_ALEN];
+ u8 perm_addr[ETH_ALEN];
+ u8 san_addr[ETH_ALEN];
/* prefix for World Wide Node Name (WWNN) */
u16 wwnn_prefix;
/* prefix for World Wide Port Name (WWPN) */
diff --git a/drivers/net/ethernet/intel/ixgbevf/defines.h b/drivers/net/ethernet/intel/ixgbevf/defines.h
index 78abb6f..2eb89cb 100644
--- a/drivers/net/ethernet/intel/ixgbevf/defines.h
+++ b/drivers/net/ethernet/intel/ixgbevf/defines.h
@@ -35,7 +35,6 @@
#define IXGBE_VF_IRQ_CLEAR_MASK 7
#define IXGBE_VF_MAX_TX_QUEUES 1
#define IXGBE_VF_MAX_RX_QUEUES 1
-#define IXGBE_ETH_LENGTH_OF_ADDRESS 6
/* Link speed */
typedef u32 ixgbe_link_speed;
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index aa3682e..21533e3 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -108,7 +108,7 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw *hw)
if (msgbuf[0] != (IXGBE_VF_RESET | IXGBE_VT_MSGTYPE_ACK))
return IXGBE_ERR_INVALID_MAC_ADDR;
- memcpy(hw->mac.perm_addr, addr, IXGBE_ETH_LENGTH_OF_ADDRESS);
+ memcpy(hw->mac.perm_addr, addr, ETH_ALEN);
hw->mac.mc_filter_type = msgbuf[IXGBE_VF_MC_TYPE_WORD];
return 0;
@@ -211,7 +211,7 @@ static s32 ixgbevf_mta_vector(struct ixgbe_hw *hw, u8 *mc_addr)
**/
static s32 ixgbevf_get_mac_addr_vf(struct ixgbe_hw *hw, u8 *mac_addr)
{
- memcpy(mac_addr, hw->mac.perm_addr, IXGBE_ETH_LENGTH_OF_ADDRESS);
+ memcpy(mac_addr, hw->mac.perm_addr, ETH_ALEN);
return 0;
}
^ permalink raw reply related
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: Alexander Duyck @ 2011-09-19 22:27 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <20110919.170033.344802441047363137.davem@davemloft.net>
On 09/19/2011 02:00 PM, David Miller wrote:
> From: Alexander Duyck<alexander.h.duyck@intel.com>
> Date: Mon, 19 Sep 2011 09:32:18 -0700
>> The fact is ixgbe has been using this parameter this way for over 2
>> years now and the main goal of this patch was just to synchronize how
>> things work on igb and ixgbe.
>>
>> Our hardware doesn't have a mechanism for firing an interrupt after X
>> number of frames so instead we simply have modified things so that we
>> will only process X number of frames and then fire another
>> interrupt/poll if needed. As such we aren't that far out of
>> compliance with the meaning of how this parameter is supposed to be
>> used.
> All I can say is this was a huge mistake you therefore need to revert
> the IXGBE change, these ethtool settings are not for changing NAPI or
> software interrupt behavior.
>
> And if you guys plan to be difficult on this and refuse to remove the
> IXGBE bits, I'm letting you guys know ahead of time that I'll do it
> for you.
>
> If the hardware can't support this facility, neither should these
> ethtool hooks, because the whole point is to avoid hardware interrupts
> from firing using these parameters.
>
> Propose new mechanisms to control NAPI behavior if you want.
I'll remove the ixgbe code if that is what you want. It may be a month
or so before I can get to it though since I am slammed with work so if
you are in a hurry for it you might want to work with Jeff Kirsher to
have the code removed.
As far as this current patch goes I honestly don't have the time to add
or rewrite yet another ethtool interface so I will probably just see
about dropping the ethtool portion of this patch and update the
description in order to make it acceptable.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Tim Chen @ 2011-09-19 21:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, zheng.z.yan, yanzheng, netdev, sfr, jirislaby,
sedat.dilek, alex.shi, Valdis.Kletnieks
In-Reply-To: <1316447547.2539.34.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 2011-09-19 at 17:52 +0200, Eric Dumazet wrote:
> Since commit 7361c36c5224 (af_unix: Allow credentials to work across
> user and pid namespaces) af_unix performance dropped a lot.
>
> This is because we now take a reference on pid and cred in each write(),
> and release them in read(), usually done from another process,
> eventually from another cpu. This triggers false sharing.
>
> # Events: 154K cycles
> #
> # Overhead Command Shared Object Symbol
> # ........ ....... .................. .........................
> #
> 10.40% hackbench [kernel.kallsyms] [k] put_pid
> 8.60% hackbench [kernel.kallsyms] [k] unix_stream_recvmsg
> 7.87% hackbench [kernel.kallsyms] [k] unix_stream_sendmsg
> 6.11% hackbench [kernel.kallsyms] [k] do_raw_spin_lock
> 4.95% hackbench [kernel.kallsyms] [k] unix_scm_to_skb
> 4.87% hackbench [kernel.kallsyms] [k] pid_nr_ns
> 4.34% hackbench [kernel.kallsyms] [k] cred_to_ucred
> 2.39% hackbench [kernel.kallsyms] [k] unix_destruct_scm
> 2.24% hackbench [kernel.kallsyms] [k] sub_preempt_count
> 1.75% hackbench [kernel.kallsyms] [k] fget_light
> 1.51% hackbench [kernel.kallsyms] [k]
> __mutex_lock_interruptible_slowpath
> 1.42% hackbench [kernel.kallsyms] [k] sock_alloc_send_pskb
>
>
> This patch includes SCM_CREDENTIALS information in a af_unix message/skb
> only if requested by the sender, [man 7 unix for details how to include
> ancillary data using sendmsg() system call]
>
> Note: This might break buggy applications that expected SCM_CREDENTIAL
> from an unaware write() system call, and receiver not using SO_PASSCRED
> socket option.
>
> If SOCK_PASSCRED is set on source or destination socket, we still
> include credentials for mere write() syscalls.
>
> Performance boost in hackbench : more than 50% gain on a 16 thread
> machine (2 quad-core cpus, 2 threads per core)
>
> hackbench 20 thread 2000
>
> 4.228 sec instead of 9.102 sec
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
Do we have to worry about the case where peer socket changes its flag
to SOCK_PASSCRED while packets are in flight? If there isn't such
pathological use case, the patch looks fine to me.
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
^ permalink raw reply
* Re: [net-next 01/13] ixgb: eliminate checkstack warnings
From: Jesse Brandeburg @ 2011-09-19 21:36 UTC (permalink / raw)
To: Joe Perches
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <1316249007.1610.13.camel@Joe-Laptop>
On Sat, 17 Sep 2011 01:43:26 -0700
Joe Perches <joe@perches.com> wrote:
> On Sat, 2011-09-17 at 01:04 -0700, Jeff Kirsher wrote:
> > From: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > Really trivial fix, use kzalloc/kree instead of stack space.
>
> Some more trivialities...
>
> > diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
> > b/drivers/net/ethernet/intel/ixgb/ixgb_main.c\
> []
> > @@ -1120,8 +1120,12 @@ ixgb_set_multi(struct net_device *netdev)
> > rctl |= IXGB_RCTL_MPE;
> > IXGB_WRITE_REG(hw, RCTL, rctl);
> > } else {
> > - u8 mta[IXGB_MAX_NUM_MULTICAST_ADDRESSES *
> > - IXGB_ETH_LENGTH_OF_ADDRESS];
> > + u8 *mta = kzalloc(IXGB_MAX_NUM_MULTICAST_ADDRESSES
> > *
> > + IXGB_ETH_LENGTH_OF_ADDRESS,
> > GFP_KERNEL);
>
> This doesn't need to be kzalloc as every byte is overwritten.
> It should be kmalloc.
done, V2 on its way
> Maybe delete the #define IXGB_ETH_LENGTH_OF_ADDRESS and
> sed 's/\bIXGB_ETH_LENGTH_OF_ADDRESS\b/ETH_ALEN/g' ?
done
> Perhaps this loop could be clearer without the multiply:
>
> i = 0;
> netdev_for_each_mc_addr(ha, netdev)
> memcpy(&mta[i++ * IXGB_ETH_LENGTH_OF_ADDRESS],
> ha->addr, IXGB_ETH_LENGTH_OF_ADDRESS);
>
> Perhaps:
>
> u8 *addr = mta;
> netdev_for_each_mc_addr(ha, netdev) {
> memcpy(addr, ha->addr, ETH_ALEN);
> addr += ETH_ALEN;
> }
done, but because of the nature of the changes being code flow, I'm
going to retest through our lab. V2 will hopefully be at the list
shortly.
Thanks for the feedback,
Jesse
^ permalink raw reply
* Re: pull request: wireless-next 2011-09-19
From: David Miller @ 2011-09-19 21:11 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20110919203639.GF2608@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 19 Sep 2011 16:36:39 -0400
> Here is another big batch of updates intended for 3.2 -- still
> clearing-out the backlog...
>
> This round includes lots of updates to ath9k, b43, iwlagn, and rt2x00.
> Some cleanups go to mac80211, along with a number of mesh-mode fixes
> from Javier.
>
> Please let me know if there are problems!
What about the iwl build failure reported by Eric Dumazet?
If that's not handled here, I want that fixed before we add even
more regressions :-)
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Eric Dumazet @ 2011-09-19 21:03 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <1316465182.2455.10.camel@edumazet-laptop>
Le lundi 19 septembre 2011 à 22:46 +0200, Eric Dumazet a écrit :
> Le lundi 19 septembre 2011 à 13:39 -0700, Maciej Żenczykowski a écrit :
> > [ 90.544012] the existing dependency chain (in reverse order) is:
> > [ 90.544012]
> > [ 90.544012] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
> > [ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
> > [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> > [ 90.544012] [<ffffffff81430d66>] _raw_spin_lock_bh+0x36/0x45
> > [ 90.544012] [<ffffffff813d9659>] rt_dst_release+0x4a/0x8d
rt_dst_release() again...
> > [ 90.544012] [<ffffffff813bee34>] dst_release+0x5d/0x66
> > [ 90.544012] [<ffffffff813af24e>] skb_release_head_state+0x1f/0xa5
> > [ 90.544012] [<ffffffff813aefec>] __kfree_skb+0x16/0x87
> > [ 90.544012] [<ffffffff813af101>] kfree_skb+0x72/0x7a
> > [ 90.544012] [<ffffffff813c06f9>] __neigh_event_send+0x126/0x176
> >
> Hmm
>
> What exact kernel version is it ?
>
>
Just to say what I already said to Murali raja Muniraju one week ago :
To my knowledge, no linux pristine linux kernel has this bug.
dst_release() is lockless.
So could you explain why its so important we add this 'bugfix' if it
only applies to a Google kernel ?
Anything I missed from my previous analysis ?
Thanks !
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 21:00 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: bhutchings, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <4E776E92.6090303@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Mon, 19 Sep 2011 09:32:18 -0700
> The fact is ixgbe has been using this parameter this way for over 2
> years now and the main goal of this patch was just to synchronize how
> things work on igb and ixgbe.
>
> Our hardware doesn't have a mechanism for firing an interrupt after X
> number of frames so instead we simply have modified things so that we
> will only process X number of frames and then fire another
> interrupt/poll if needed. As such we aren't that far out of
> compliance with the meaning of how this parameter is supposed to be
> used.
All I can say is this was a huge mistake you therefore need to revert
the IXGBE change, these ethtool settings are not for changing NAPI or
software interrupt behavior.
And if you guys plan to be difficult on this and refuse to remove the
IXGBE bits, I'm letting you guys know ahead of time that I'll do it
for you.
If the hardware can't support this facility, neither should these
ethtool hooks, because the whole point is to avoid hardware interrupts
from firing using these parameters.
Propose new mechanisms to control NAPI behavior if you want.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 20:57 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: alexander.h.duyck, netdev, gospo
In-Reply-To: <1316246677-8830-12-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 17 Sep 2011 01:04:35 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change is meant to make the NAPI budget limits for transmit
> adjustable. By doing this it is possible to tune the value for optimal
> performance with applications such as routing.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
As Ben and I have mentioned, this change is not acceptable.
Ethtool settings for "hardware interrupt" coalescing and mitigation
should have no effect on NAPI behavior.
^ permalink raw reply
* Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
From: David Miller @ 2011-09-19 20:56 UTC (permalink / raw)
To: bhutchings; +Cc: alexander.h.duyck, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <1316448352.2764.27.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 19 Sep 2011 17:05:52 +0100
> But tx_max_coalesced_frames_irq is not supposed to be a work limit (and
> such a work limit doesn't seem useful in the absence of NAPI). As I
> understand it, it is supposed to be an alternate moderation value for
> the hardware to use if a frame is sent while the IRQ handler is running.
Exactly, the ethtool settings modify what the hardware interrupt mechanisms
do, ragardless of whether those hardware interrupts trigger NAPI or not.
And this is precisely what we want, because optimal behavior of NAPI
absoulutely depends upon having the interrupt moderated in hardware
at least a little bit.
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Eric Dumazet @ 2011-09-19 20:46 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <CANP3RGdxYg0Utfyrqfwoj+ojfCD+ZYJTa91nzPSdWBznZWKHaA@mail.gmail.com>
Le lundi 19 septembre 2011 à 13:39 -0700, Maciej Żenczykowski a écrit :
> The first hunk was for consistency - to always free in exit path. The
> second hunk is where the lockdep bug is.
>
> LOCKDEP gives the following (it's pretty rare):
>
> [ 90.543085] =======================================================
> [ 90.544012] [ INFO: possible circular locking dependency detected ]
> [ 90.544012] 2.6.34-smp-DEV #70
> [ 90.544012] -------------------------------------------------------
> [ 90.544012] swapper/0 is trying to acquire lock:
> [ 90.544012] (&tbl->lock){++--..}, at: [<ffffffff813c106d>]
> neigh_lookup+0x42/0xbf
> [ 90.544012]
> [ 90.544012] but task is already holding lock:
> [ 90.544012] (&(&rt_hash_locks[i])->rlock){+.-...}, at:
> [<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
> [ 90.544012]
> [ 90.544012] which lock already depends on the new lock.
> [ 90.544012]
> [ 90.544012]
> [ 90.544012] the existing dependency chain (in reverse order) is:
> [ 90.544012]
> [ 90.544012] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
> [ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff81430d66>] _raw_spin_lock_bh+0x36/0x45
> [ 90.544012] [<ffffffff813d9659>] rt_dst_release+0x4a/0x8d
> [ 90.544012] [<ffffffff813bee34>] dst_release+0x5d/0x66
> [ 90.544012] [<ffffffff813af24e>] skb_release_head_state+0x1f/0xa5
> [ 90.544012] [<ffffffff813aefec>] __kfree_skb+0x16/0x87
> [ 90.544012] [<ffffffff813af101>] kfree_skb+0x72/0x7a
> [ 90.544012] [<ffffffff813c06f9>] __neigh_event_send+0x126/0x176
> [ 90.544012] [<ffffffff813c2c1b>] neigh_resolve_output+0x7f/0x267
> [ 90.544012] [<ffffffff813e3057>] ip_finish_output2+0x1f2/0x221
> [ 90.544012] [<ffffffff813e30ea>] ip_finish_output+0x64/0x66
> [ 90.544012] [<ffffffff813e3200>] NF_HOOK_COND.clone.1+0x41/0x45
> [ 90.544012] [<ffffffff813e3277>] ip_output+0x73/0x75
> [ 90.544012] [<ffffffff813e1524>] dst_output+0x10/0x12
> [ 90.544012] [<ffffffff813e349f>] ip_local_out+0x23/0x27
> [ 90.544012] [<ffffffff813e378a>] ip_push_pending_frames+0x2e7/0x348
> [ 90.544012] [<ffffffff81401a13>] udp_push_pending_frames+0x2dc/0x35c
> [ 90.544012] [<ffffffff8140314e>] udp_sendmsg+0x628/0x763
> [ 90.544012] [<ffffffff81409933>] inet_sendmsg+0x58/0x61
> [ 90.544012] [<ffffffff813a726f>] __sock_sendmsg+0x5e/0x69
> [ 90.544012] [<ffffffff813a7737>] sock_sendmsg+0xa8/0xc1
> [ 90.544012] [<ffffffff813a79d9>] sys_sendmsg+0x1da/0x241
> [ 90.544012] [<ffffffff813cb482>] compat_sys_sendmsg+0x14/0x16
> [ 90.544012] [<ffffffff813cc081>] compat_sys_socketcall+0x13b/0x16c
> [ 90.544012] [<ffffffff81059687>] sysenter_dispatch+0x7/0x2c
> [ 90.544012]
> [ 90.544012] -> #1 (&n->lock){++--..}:
> [ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff81430e81>] _raw_write_lock+0x31/0x40
> [ 90.544012] [<ffffffff813c16fb>] neigh_periodic_work+0xae/0x196
> [ 90.544012] [<ffffffff8108a8ca>] worker_thread+0x1fb/0x2f1
> [ 90.544012] [<ffffffff8108e099>] kthread+0x7f/0x87
> [ 90.544012] [<ffffffff81032a94>] kernel_thread_helper+0x4/0x10
> [ 90.544012]
> [ 90.544012] -> #0 (&tbl->lock){++--..}:
> [ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
> [ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff81405067>]
> __neigh_lookup_errno.clone.0+0x24/0x40
> [ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
> [ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
> [ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
> [ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
> [ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
> [ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
> [ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
> [ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
> [ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
> [ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
> [ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
> [ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
> [ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
> [ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
> [ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
> [ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
> [ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
> [ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
> [ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
> [ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
> [ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
> [ 90.544012]
> [ 90.544012] other info that might help us debug this:
> [ 90.544012]
> [ 90.544012] 3 locks held by swapper/0:
> [ 90.544012] #0: (&n->timer){+.-...}, at: [<ffffffff810807e8>]
> run_timer_softirq+0x187/0x2e3
> [ 90.544012] #1: (slock-AF_INET){+.-...}, at: [<ffffffff814063d3>]
> icmp_xmit_lock+0x35/0x47
> [ 90.544012] #2: (&(&rt_hash_locks[i])->rlock){+.-...}, at:
> [<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
> [ 90.544012]
> [ 90.544012] stack backtrace:
> [ 90.544012] Pid: 0, comm: swapper Not tainted 2.6.34-smp-DEV #70
> [ 90.544012] Call Trace:
> [ 90.544012] <IRQ> [<ffffffff810a39c0>] print_circular_bug+0xa8/0xb7
> [ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
> [ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
> [ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
> [ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
> [ 90.544012] [<ffffffff81405067>] __neigh_lookup_errno.clone.0+0x24/0x40
> [ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
> [ 90.544012] [<ffffffff813db663>] ? rt_intern_hash+0xf2/0x3ad
> [ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
> [ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
> [ 90.544012] [<ffffffff81078f49>] ? _local_bh_enable_ip+0xc1/0xc7
> [ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
> [ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
> [ 90.544012] [<ffffffff813c2800>] ? neigh_event_ns+0x2f/0xa2
> [ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
> [ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
> [ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
> [ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
> [ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
> [ 90.544012] [<ffffffff810807e8>] ? run_timer_softirq+0x187/0x2e3
> [ 90.544012] [<ffffffff8109158d>] ? __run_hrtimer+0xf4/0x132
> [ 90.544012] [<ffffffff813c2873>] ? neigh_timer_handler+0x0/0x27f
> [ 90.544012] [<ffffffff8107908d>] ? __do_softirq+0x76/0x1cb
> [ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
> [ 90.544012] [<ffffffff8109f74a>] ? tick_program_event+0x2a/0x2c
> [ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
> [ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
> [ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
> [ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
> [ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
> [ 90.544012] <EOI> [<ffffffff81039700>] ? mwait_idle+0x85/0x92
> [ 90.544012] [<ffffffff810396f7>] ? mwait_idle+0x7c/0x92
> [ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
> [ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
> [ 90.544012] [<ffffffff8142207c>] ? rest_init+0x0/0xca
> [ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
> [ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
> [ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
>
> At some point in the past of the lifetime of this kernel we grabbed
> exactly the following 3 locks in the following order (where the first
> 2 were still held while we grabbed the 3rd):
> (&tbl->lock){++--..} => (&n->lock){++--..} =>
> (&(&rt_hash_locks[i])->rlock){+.-...}
>
> Now, we have grabbed the first three (are still holding them and are
> trying to grab the fourth) of these locks in this order:
> (&n->timer){+.-...} => (slock-AF_INET){+.-...} =>
> (&(&rt_hash_locks[i])->rlock){+.-...} => (&tbl->lock){++--..}
>
> We're complaining that this 4th lock is being grabbed after the 3rd,
> when previously it was the 1st before the 3rd - we've apparently
> reversed lock ordering...
Hmm
What exact kernel version is it ?
^ permalink raw reply
* Re: pull request: wireless-next 2011-09-19
From: John W. Linville @ 2011-09-19 20:48 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110919203639.GF2608-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Oops -- fat-fingered the linux-wireless email address...
On Mon, Sep 19, 2011 at 04:36:39PM -0400, John W. Linville wrote:
> David,
>
> Here is another big batch of updates intended for 3.2 -- still
> clearing-out the backlog...
>
> This round includes lots of updates to ath9k, b43, iwlagn, and rt2x00.
> Some cleanups go to mac80211, along with a number of mesh-mode fixes
> from Javier.
>
> Please let me know if there are problems!
>
> Thanks,
>
> John
>
> ---
>
> The following changes since commit 765cf9976e937f1cfe9159bf4534967c8bf8eb6d:
>
> tcp: md5: remove one indirection level in tcp_md5sig_pool (2011-09-17 01:15:46 -0400)
>
> are available in the git repository at:
> ssh://infradead/~/public_git/wireless-next.git for-davem
>
> Andres Salomon (1):
> libertas: prioritize usb8388_olpc.bin firmware on OLPC machines
>
> Arik Nemtsov (3):
> wl12xx: allow 11a AP-mode for wl127x devices
> mac80211: add flag to indicate HW only Tx-agg setup support
> mac80211: add ssid config to bss information in AP-mode
>
> Bill Jordan (1):
> ath9k: ath9k_hw_set_txpowerlimit sets previous txpower
>
> Christian Lamparter (1):
> minstrel_ht: fix Open BA session request floods
>
> Dan Carpenter (3):
> mac80211: handle allocation failures in mesh_pathtbl_init()
> iwlwifi: fix double assign in iwl_start_tx_ba_trans_ready()
> iwlwifi: signedness bug in iwl_trans_pcie_tx_agg_alloc()
>
> Eliad Peller (5):
> wl12xx: initialize rate_set on band rates initialization
> wl12xx: increase psm_entry_retries
> wl12xx: enter psm only after station role was started
> nl80211/cfg80211: add WIPHY_FLAG_AP_UAPSD flag
> nl80211/cfg80211/mac80211: fix wme docs
>
> Emmanuel Grumbach (6):
> iwlagn: merge iwl_pci_down and iwl_pci_remove
> iwlagn: remove priv dereferences from the transport layer
> iwlagn: clean up of transport layer
> iwlagn: move traffic_log back to upper layer
> iwlagn: iwl-trans.c can't dereference iwl_priv any more
> iwlagn: fix compilation when debug flags is unset
>
> Felix Fietkau (27):
> ath9k_hw: do not apply the 2.4 ghz ack timeout workaround to cts
> mac80211: retry sending failed BAR frames later instead of tearing down aggr
> ath9k_hw: drop an unused column in AR5008-AR9002 initvals
> ath9k_hw: fix the last register write for ar5416 addac
> ath9k: fix checks for first subframe delimiter padding
> mac80211: make ieee80211_send_bar available for drivers
> ath9k: eliminate common->{rx,tx}_chainmask
> ath9k: move a few functions around
> ath9k: always call ath_reset from workqueue context
> ath9k: merge reset related functions
> ath9k: implement .get_antenna and .set_antenna
> ath9k: fix enabling interrupts after a hardware error interrupt
> ath9k: make beacon timer initialization more reliable
> ath9k: ensure that rx is not enabled during a reset
> ath9k: remove ATH_TX_XRETRY and BUF_XRETRY flags
> ath9k: reduce the number of functions that access the tx descriptor
> ath9k: move ath_buf_set_rate to remove a forward declaration
> ath9k: call ath9k_hw_set_desc_link for beacon descriptors
> ath9k_hw: do not recalculate the descriptor checksum in ar9003_hw_fill_txdesc
> ath9k_hw: add a new API for setting tx descriptors
> ath9k: use the new API for setting tx descriptors
> ath9k_hw: remove the old tx descriptor API
> ath9k: optimize ath9k_ps_restore
> ath9k: remove a redundant check in ath_tx_form_aggr
> ath9k: optimize ath_tx_rc_status usage
> ath9k: do not insert padding into tx buffers on AR9380+
> mac80211: fix endian issues and comments for BAR failure handling
>
> Guy Eilam (1):
> wl12xx: use 2 spare TX blocks for GEM cipher
>
> Helmut Schaa (12):
> rt2x00: Minor optimizazion in txdone path
> rt2x00: Add LED_CFG register description
> rt2x00: Remove incorrect led blink
> rt2x00: Update some TX descriptor
> rt2x00: Avoid unnecessary uncached
> rt2x00: Move bssidx calculation into its own function
> rt2x00: Introduce sta_add/remove callbacks
> rt2x00: Add WCID to crypto struct
> rt2x00: Add WCID to HT TX descriptor
> rt2x00: Make use of sta_add/remove callbacks in rt2800
> rt2x00: Forbid aggregation for STAs not programmed into the hw
> rt2x00: Use the available helper functions to initialize the WCID table
>
> Javier Cardona (12):
> mac80211: Defer tranmission of mesh path errors
> mac80211: Fix RCU pointer dereference in mesh_path_discard_frame()
> mac80211: Remove mesh paths when an interface is removed
> mac80211: Improve mpath state locking
> mac80211: Remove redundant mesh path expiration checks
> mac80211: Don't iterate twice over all mpaths when once in sufficient
> mac80211: Consolidate {mesh,mpp}_path_flush into one function
> mac80211: Consolidate mesh path duplicated functions
> mac80211: Stop forwarding mesh traffic when tx queues are full
> mac80211: Start implementing QoS support for mesh interfaces
> mac80211: Mesh data frames must have the QoS header
> mac80211: Mark all mesh stations as QoS capable
>
> Joe Perches (3):
> mac80211: Remove unnecessary OOM logging messages
> rfkill: Remove unnecessary OOM logging messages
> wireless: Remove unnecessary OOM logging messages
>
> Johannes Berg (2):
> mac80211: further optimise buffer expiry timer
> cfg80211: verify format of uAPSD information
>
> John W. Linville (2):
> Merge branch 'for-linville' of git://github.com/lucacoelho/wl12xx
> Merge branch 'master' of ssh://infradead/~/public_git/wireless-next into for-davem
>
> Kalle Valo (1):
> MAINTAINERS: update ath6kl
>
> Luciano Coelho (4):
> wl12xx: add support for multiple SSIDs in sched_scan
> wl12xx: use SCAN_SSID_TYPE_PUBLIC when using the wildcard in sched_scan
> nl80211/cfg80211: add match filtering for sched_scan
> Merge branch 'wl12xx-next' into for-linville
>
> Mohammed Shafi Shajakhan (2):
> ath9k: enable LED pin for AR946/8x chipsets
> ath9k: Fix PS wrappers and enabling LED
>
> Pavel Roskin (1):
> cfg80211: print bandwidth in chan_reg_rule_print_dbg()
>
> Rafał Miłecki (20):
> b43: LCN-PHY: add R/W ops for PHY and radio
> b43: LCN-PHY: implement more PHY ops before radio init
> b43: LCN-PHY: prepare functions for channel switching
> ssb: use u16 for storing board rev
> bcma: extract some basic info about board from SPROM
> b43: LCN-PHY: implement saving and restoring PHY & radio configuration
> b43: LCN-PHY: minor fixes
> b43: LCN-PHY: put tables functions in correct file
> b43: LCN-PHY: rewrite 0x7 table at the end of init
> b43: LCN-PHY: upload additional 0x7 table
> b43: LCN-PHY: rename functions, get rid of magic names
> b43: LCN-PHY: add conditions for few operations
> b43: N-PHY: implement enabling TX power control
> b43: drop Copyright for not really copyrightable info
> b43: add my copyrights and myself as the module author
> b43: LCN-PHY: load TX gain table on init
> b43: N-PHY: use helper for checking IPA
> b43: N-PHY: replace some hacks with nice tables ops
> b43: N-PHY: split workarounds into per-PHY-ver functions
> b43: N-PHY: implement few random missing ops
>
> Rajkumar Manoharan (6):
> ath9k_hw: Fix rx latency of 11a mode
> mac80211: stop tx before doing hw config and rate update
> ath9k: Take the samples in unassociated state
> ath9k: Move cycle conters under cc_lock
> ath9k_hw: Fix magnitude/phase average in TxIQ Calibration
> ath9k_hw: Do full chip reset on 11A channels for AR9003
>
> Randy Dunlap (1):
> wireless: fix kernel-doc warning in net/cfg80211.h
>
> Senthil Balasubramanian (4):
> ath9k_hw: Add initvals and register definitions for AR946/8x chipsets.
> ath9k_hw: Split tx/rx gain table initval handling
> ath9k_hw: Add support for AR946/8x chipsets.
> ath9k_hw: move register definitions to header files
>
> Shahar Levi (1):
> mac80211: Update device channel in case of HW channel switch supported
>
> Sven Neumann (2):
> cfg80211: hold reg_mutex when updating regulatory
> cfg80211: reorder code to obsolete forward declaration
>
> Thomas Pedersen (1):
> mac80211: check if mesh frame is in RMC after decrypt
>
> Vivek Natarajan (1):
> cfg80211/nl80211: Indicate roaming feature capability to userspace.
>
> Wey-Yi Guy (4):
> iwlagn: only perform necessary calibration at init time
> iwlagn: disply queue read/write pointer when stuck
> iwlagn: enable 11n support for "_d" sku
> iwlagn: remove lines from the wrong place
>
> Yogesh Ashok Powar (2):
> mwl8k: Set hardware flag IEEE80211_HW_AP_LINK_PS
> mwifiex: replace kmalloc & memcpy sequence with kmemdup
>
> zero.lin (1):
> rt2x00: Add new chipset support
>
> MAINTAINERS | 14 +-
> drivers/bcma/sprom.c | 9 +
> drivers/net/wireless/ath/ath.h | 3 -
> drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 131 +-
> drivers/net/wireless/ath/ath9k/ar9001_initvals.h | 266 +-
> drivers/net/wireless/ath/ath9k/ar9002_hw.c | 48 +-
> drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 3403 ++++++++++----------
> drivers/net/wireless/ath/ath9k/ar9002_mac.c | 257 +-
> drivers/net/wireless/ath/ath9k/ar9003_calib.c | 17 +-
> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 117 +-
> drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 3 +-
> drivers/net/wireless/ath/ath9k/ar9003_hw.c | 581 +++-
> drivers/net/wireless/ath/ath9k/ar9003_mac.c | 331 +--
> drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 15 +-
> drivers/net/wireless/ath/ath9k/ar9003_phy.c | 10 +
> drivers/net/wireless/ath/ath9k/ar9003_phy.h | 100 +-
> .../net/wireless/ath/ath9k/ar9480_1p0_initvals.h | 1833 +++++++++++
> .../net/wireless/ath/ath9k/ar9480_2p0_initvals.h | 1928 +++++++++++
> drivers/net/wireless/ath/ath9k/ath9k.h | 14 +-
> drivers/net/wireless/ath/ath9k/beacon.c | 56 +-
> drivers/net/wireless/ath/ath9k/debug.c | 41 +-
> drivers/net/wireless/ath/ath9k/debug.h | 6 +-
> drivers/net/wireless/ath/ath9k/gpio.c | 2 +
> drivers/net/wireless/ath/ath9k/htc_drv_init.c | 7 +-
> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 +-
> drivers/net/wireless/ath/ath9k/hw-ops.h | 58 +-
> drivers/net/wireless/ath/ath9k/hw.c | 102 +-
> drivers/net/wireless/ath/ath9k/hw.h | 28 +-
> drivers/net/wireless/ath/ath9k/init.c | 42 +-
> drivers/net/wireless/ath/ath9k/mac.c | 12 -
> drivers/net/wireless/ath/ath9k/mac.h | 42 +-
> drivers/net/wireless/ath/ath9k/main.c | 535 ++--
> drivers/net/wireless/ath/ath9k/pci.c | 5 +-
> drivers/net/wireless/ath/ath9k/recv.c | 7 +-
> drivers/net/wireless/ath/ath9k/reg.h | 62 +-
> drivers/net/wireless/ath/ath9k/xmit.c | 607 ++--
> drivers/net/wireless/b43/b43.h | 2 +
> drivers/net/wireless/b43/bus.c | 2 +
> drivers/net/wireless/b43/main.c | 3 +
> drivers/net/wireless/b43/phy_ht.c | 2 +
> drivers/net/wireless/b43/phy_lcn.c | 288 ++-
> drivers/net/wireless/b43/phy_n.c | 543 ++--
> drivers/net/wireless/b43/phy_n.h | 4 +
> drivers/net/wireless/b43/radio_2055.c | 1 +
> drivers/net/wireless/b43/radio_2056.c | 2 +
> drivers/net/wireless/b43/radio_2056.h | 26 -
> drivers/net/wireless/b43/radio_2059.c | 2 +
> drivers/net/wireless/b43/tables_nphy.c | 1 +
> drivers/net/wireless/b43/tables_phy_ht.c | 2 +
> drivers/net/wireless/b43/tables_phy_lcn.c | 255 ++-
> drivers/net/wireless/b43/tables_phy_lcn.h | 2 +
> drivers/net/wireless/iwlwifi/iwl-2000.c | 1 +
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 2 +-
> drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 4 +-
> drivers/net/wireless/iwlwifi/iwl-agn-tt.h | 1 -
> drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 2 +-
> drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 5 +-
> drivers/net/wireless/iwlwifi/iwl-agn.c | 10 +-
> drivers/net/wireless/iwlwifi/iwl-agn.h | 2 -
> drivers/net/wireless/iwlwifi/iwl-commands.h | 7 +-
> drivers/net/wireless/iwlwifi/iwl-core.c | 19 +-
> drivers/net/wireless/iwlwifi/iwl-core.h | 22 -
> drivers/net/wireless/iwlwifi/iwl-csr.h | 18 +
> drivers/net/wireless/iwlwifi/iwl-debugfs.c | 85 +
> drivers/net/wireless/iwlwifi/iwl-dev.h | 202 +--
> drivers/net/wireless/iwlwifi/iwl-helpers.h | 23 -
> drivers/net/wireless/iwlwifi/iwl-pci.c | 18 +-
> drivers/net/wireless/iwlwifi/iwl-rx.c | 83 +-
> drivers/net/wireless/iwlwifi/iwl-shared.h | 52 +
> drivers/net/wireless/iwlwifi/iwl-sta.c | 4 +-
> drivers/net/wireless/iwlwifi/iwl-sv-open.c | 1 +
> drivers/net/wireless/iwlwifi/iwl-trans-int-pcie.h | 110 +-
> drivers/net/wireless/iwlwifi/iwl-trans-rx-pcie.c | 45 +-
> drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c | 130 +-
> drivers/net/wireless/iwlwifi/iwl-trans.c | 402 +--
> drivers/net/wireless/iwlwifi/iwl-trans.h | 66 +-
> drivers/net/wireless/libertas/if_usb.c | 21 +
> drivers/net/wireless/mwifiex/join.c | 3 +-
> drivers/net/wireless/mwifiex/scan.c | 6 +-
> drivers/net/wireless/mwifiex/sta_ioctl.c | 9 +-
> drivers/net/wireless/mwl8k.c | 8 +
> drivers/net/wireless/rt2x00/rt2800.h | 3 +
> drivers/net/wireless/rt2x00/rt2800lib.c | 191 +-
> drivers/net/wireless/rt2x00/rt2800lib.h | 5 +-
> drivers/net/wireless/rt2x00/rt2800pci.c | 15 +-
> drivers/net/wireless/rt2x00/rt2800usb.c | 7 +-
> drivers/net/wireless/rt2x00/rt2x00.h | 30 +
> drivers/net/wireless/rt2x00/rt2x00dev.c | 21 +
> drivers/net/wireless/rt2x00/rt2x00mac.c | 50 +-
> drivers/net/wireless/rt2x00/rt2x00queue.c | 7 +-
> drivers/net/wireless/rt2x00/rt2x00queue.h | 5 +-
> drivers/net/wireless/wl12xx/boot.c | 4 +-
> drivers/net/wireless/wl12xx/main.c | 50 +-
> drivers/net/wireless/wl12xx/scan.c | 66 +-
> drivers/net/wireless/wl12xx/tx.c | 8 +-
> drivers/net/wireless/wl12xx/tx.h | 1 +
> drivers/net/wireless/wl12xx/wl12xx.h | 3 +
> include/linux/ieee80211.h | 2 +
> include/linux/nl80211.h | 57 +-
> include/linux/ssb/ssb.h | 2 +-
> include/net/cfg80211.h | 31 +
> include/net/mac80211.h | 29 +
> net/mac80211/agg-rx.c | 19 +-
> net/mac80211/agg-tx.c | 42 +-
> net/mac80211/cfg.c | 21 +-
> net/mac80211/debugfs.c | 5 +
> net/mac80211/debugfs_netdev.c | 3 +
> net/mac80211/ht.c | 6 +-
> net/mac80211/ieee80211_i.h | 3 +-
> net/mac80211/iface.c | 6 +
> net/mac80211/mesh.c | 8 +-
> net/mac80211/mesh.h | 6 +-
> net/mac80211/mesh_hwmp.c | 31 +-
> net/mac80211/mesh_pathtbl.c | 192 +-
> net/mac80211/mesh_plink.c | 2 +-
> net/mac80211/mlme.c | 36 +-
> net/mac80211/rc80211_minstrel_ht.c | 3 +-
> net/mac80211/rx.c | 35 +-
> net/mac80211/spectmgmt.c | 6 +-
> net/mac80211/sta_info.c | 10 +-
> net/mac80211/sta_info.h | 5 +
> net/mac80211/status.c | 53 +-
> net/mac80211/tx.c | 26 +-
> net/mac80211/util.c | 13 +-
> net/mac80211/wme.c | 16 +-
> net/mac80211/wme.h | 3 +-
> net/mac80211/work.c | 6 +-
> net/rfkill/rfkill-regulator.c | 1 -
> net/wireless/core.c | 2 +-
> net/wireless/core.h | 2 -
> net/wireless/lib80211_crypt_ccmp.c | 2 -
> net/wireless/lib80211_crypt_tkip.c | 4 -
> net/wireless/lib80211_crypt_wep.c | 4 -
> net/wireless/nl80211.c | 73 +-
> net/wireless/reg.c | 33 +-
> net/wireless/reg.h | 2 +
> net/wireless/util.c | 5 +-
> 137 files changed, 9864 insertions(+), 4598 deletions(-)
> create mode 100644 drivers/net/wireless/ath/ath9k/ar9480_1p0_initvals.h
> create mode 100644 drivers/net/wireless/ath/ath9k/ar9480_2p0_initvals.h
>
> Omnibus patch is available here:
>
> http://bombadil.infradead.org/~linville/wireless-next-2011-09-19.patch.gz
>
> --
> John W. Linville Someday the world will need a hero, and you
> linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
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
* pull request: wireless-next 2011-09-19
From: John W. Linville @ 2011-09-19 20:36 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
David,
Here is another big batch of updates intended for 3.2 -- still
clearing-out the backlog...
This round includes lots of updates to ath9k, b43, iwlagn, and rt2x00.
Some cleanups go to mac80211, along with a number of mesh-mode fixes
from Javier.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 765cf9976e937f1cfe9159bf4534967c8bf8eb6d:
tcp: md5: remove one indirection level in tcp_md5sig_pool (2011-09-17 01:15:46 -0400)
are available in the git repository at:
ssh://infradead/~/public_git/wireless-next.git for-davem
Andres Salomon (1):
libertas: prioritize usb8388_olpc.bin firmware on OLPC machines
Arik Nemtsov (3):
wl12xx: allow 11a AP-mode for wl127x devices
mac80211: add flag to indicate HW only Tx-agg setup support
mac80211: add ssid config to bss information in AP-mode
Bill Jordan (1):
ath9k: ath9k_hw_set_txpowerlimit sets previous txpower
Christian Lamparter (1):
minstrel_ht: fix Open BA session request floods
Dan Carpenter (3):
mac80211: handle allocation failures in mesh_pathtbl_init()
iwlwifi: fix double assign in iwl_start_tx_ba_trans_ready()
iwlwifi: signedness bug in iwl_trans_pcie_tx_agg_alloc()
Eliad Peller (5):
wl12xx: initialize rate_set on band rates initialization
wl12xx: increase psm_entry_retries
wl12xx: enter psm only after station role was started
nl80211/cfg80211: add WIPHY_FLAG_AP_UAPSD flag
nl80211/cfg80211/mac80211: fix wme docs
Emmanuel Grumbach (6):
iwlagn: merge iwl_pci_down and iwl_pci_remove
iwlagn: remove priv dereferences from the transport layer
iwlagn: clean up of transport layer
iwlagn: move traffic_log back to upper layer
iwlagn: iwl-trans.c can't dereference iwl_priv any more
iwlagn: fix compilation when debug flags is unset
Felix Fietkau (27):
ath9k_hw: do not apply the 2.4 ghz ack timeout workaround to cts
mac80211: retry sending failed BAR frames later instead of tearing down aggr
ath9k_hw: drop an unused column in AR5008-AR9002 initvals
ath9k_hw: fix the last register write for ar5416 addac
ath9k: fix checks for first subframe delimiter padding
mac80211: make ieee80211_send_bar available for drivers
ath9k: eliminate common->{rx,tx}_chainmask
ath9k: move a few functions around
ath9k: always call ath_reset from workqueue context
ath9k: merge reset related functions
ath9k: implement .get_antenna and .set_antenna
ath9k: fix enabling interrupts after a hardware error interrupt
ath9k: make beacon timer initialization more reliable
ath9k: ensure that rx is not enabled during a reset
ath9k: remove ATH_TX_XRETRY and BUF_XRETRY flags
ath9k: reduce the number of functions that access the tx descriptor
ath9k: move ath_buf_set_rate to remove a forward declaration
ath9k: call ath9k_hw_set_desc_link for beacon descriptors
ath9k_hw: do not recalculate the descriptor checksum in ar9003_hw_fill_txdesc
ath9k_hw: add a new API for setting tx descriptors
ath9k: use the new API for setting tx descriptors
ath9k_hw: remove the old tx descriptor API
ath9k: optimize ath9k_ps_restore
ath9k: remove a redundant check in ath_tx_form_aggr
ath9k: optimize ath_tx_rc_status usage
ath9k: do not insert padding into tx buffers on AR9380+
mac80211: fix endian issues and comments for BAR failure handling
Guy Eilam (1):
wl12xx: use 2 spare TX blocks for GEM cipher
Helmut Schaa (12):
rt2x00: Minor optimizazion in txdone path
rt2x00: Add LED_CFG register description
rt2x00: Remove incorrect led blink
rt2x00: Update some TX descriptor
rt2x00: Avoid unnecessary uncached
rt2x00: Move bssidx calculation into its own function
rt2x00: Introduce sta_add/remove callbacks
rt2x00: Add WCID to crypto struct
rt2x00: Add WCID to HT TX descriptor
rt2x00: Make use of sta_add/remove callbacks in rt2800
rt2x00: Forbid aggregation for STAs not programmed into the hw
rt2x00: Use the available helper functions to initialize the WCID table
Javier Cardona (12):
mac80211: Defer tranmission of mesh path errors
mac80211: Fix RCU pointer dereference in mesh_path_discard_frame()
mac80211: Remove mesh paths when an interface is removed
mac80211: Improve mpath state locking
mac80211: Remove redundant mesh path expiration checks
mac80211: Don't iterate twice over all mpaths when once in sufficient
mac80211: Consolidate {mesh,mpp}_path_flush into one function
mac80211: Consolidate mesh path duplicated functions
mac80211: Stop forwarding mesh traffic when tx queues are full
mac80211: Start implementing QoS support for mesh interfaces
mac80211: Mesh data frames must have the QoS header
mac80211: Mark all mesh stations as QoS capable
Joe Perches (3):
mac80211: Remove unnecessary OOM logging messages
rfkill: Remove unnecessary OOM logging messages
wireless: Remove unnecessary OOM logging messages
Johannes Berg (2):
mac80211: further optimise buffer expiry timer
cfg80211: verify format of uAPSD information
John W. Linville (2):
Merge branch 'for-linville' of git://github.com/lucacoelho/wl12xx
Merge branch 'master' of ssh://infradead/~/public_git/wireless-next into for-davem
Kalle Valo (1):
MAINTAINERS: update ath6kl
Luciano Coelho (4):
wl12xx: add support for multiple SSIDs in sched_scan
wl12xx: use SCAN_SSID_TYPE_PUBLIC when using the wildcard in sched_scan
nl80211/cfg80211: add match filtering for sched_scan
Merge branch 'wl12xx-next' into for-linville
Mohammed Shafi Shajakhan (2):
ath9k: enable LED pin for AR946/8x chipsets
ath9k: Fix PS wrappers and enabling LED
Pavel Roskin (1):
cfg80211: print bandwidth in chan_reg_rule_print_dbg()
Rafał Miłecki (20):
b43: LCN-PHY: add R/W ops for PHY and radio
b43: LCN-PHY: implement more PHY ops before radio init
b43: LCN-PHY: prepare functions for channel switching
ssb: use u16 for storing board rev
bcma: extract some basic info about board from SPROM
b43: LCN-PHY: implement saving and restoring PHY & radio configuration
b43: LCN-PHY: minor fixes
b43: LCN-PHY: put tables functions in correct file
b43: LCN-PHY: rewrite 0x7 table at the end of init
b43: LCN-PHY: upload additional 0x7 table
b43: LCN-PHY: rename functions, get rid of magic names
b43: LCN-PHY: add conditions for few operations
b43: N-PHY: implement enabling TX power control
b43: drop Copyright for not really copyrightable info
b43: add my copyrights and myself as the module author
b43: LCN-PHY: load TX gain table on init
b43: N-PHY: use helper for checking IPA
b43: N-PHY: replace some hacks with nice tables ops
b43: N-PHY: split workarounds into per-PHY-ver functions
b43: N-PHY: implement few random missing ops
Rajkumar Manoharan (6):
ath9k_hw: Fix rx latency of 11a mode
mac80211: stop tx before doing hw config and rate update
ath9k: Take the samples in unassociated state
ath9k: Move cycle conters under cc_lock
ath9k_hw: Fix magnitude/phase average in TxIQ Calibration
ath9k_hw: Do full chip reset on 11A channels for AR9003
Randy Dunlap (1):
wireless: fix kernel-doc warning in net/cfg80211.h
Senthil Balasubramanian (4):
ath9k_hw: Add initvals and register definitions for AR946/8x chipsets.
ath9k_hw: Split tx/rx gain table initval handling
ath9k_hw: Add support for AR946/8x chipsets.
ath9k_hw: move register definitions to header files
Shahar Levi (1):
mac80211: Update device channel in case of HW channel switch supported
Sven Neumann (2):
cfg80211: hold reg_mutex when updating regulatory
cfg80211: reorder code to obsolete forward declaration
Thomas Pedersen (1):
mac80211: check if mesh frame is in RMC after decrypt
Vivek Natarajan (1):
cfg80211/nl80211: Indicate roaming feature capability to userspace.
Wey-Yi Guy (4):
iwlagn: only perform necessary calibration at init time
iwlagn: disply queue read/write pointer when stuck
iwlagn: enable 11n support for "_d" sku
iwlagn: remove lines from the wrong place
Yogesh Ashok Powar (2):
mwl8k: Set hardware flag IEEE80211_HW_AP_LINK_PS
mwifiex: replace kmalloc & memcpy sequence with kmemdup
zero.lin (1):
rt2x00: Add new chipset support
MAINTAINERS | 14 +-
drivers/bcma/sprom.c | 9 +
drivers/net/wireless/ath/ath.h | 3 -
drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 131 +-
drivers/net/wireless/ath/ath9k/ar9001_initvals.h | 266 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 48 +-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 3403 ++++++++++----------
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 257 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 17 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 117 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 3 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 581 +++-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 331 +--
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 15 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 10 +
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 100 +-
.../net/wireless/ath/ath9k/ar9480_1p0_initvals.h | 1833 +++++++++++
.../net/wireless/ath/ath9k/ar9480_2p0_initvals.h | 1928 +++++++++++
drivers/net/wireless/ath/ath9k/ath9k.h | 14 +-
drivers/net/wireless/ath/ath9k/beacon.c | 56 +-
drivers/net/wireless/ath/ath9k/debug.c | 41 +-
drivers/net/wireless/ath/ath9k/debug.h | 6 +-
drivers/net/wireless/ath/ath9k/gpio.c | 2 +
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 7 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 58 +-
drivers/net/wireless/ath/ath9k/hw.c | 102 +-
drivers/net/wireless/ath/ath9k/hw.h | 28 +-
drivers/net/wireless/ath/ath9k/init.c | 42 +-
drivers/net/wireless/ath/ath9k/mac.c | 12 -
drivers/net/wireless/ath/ath9k/mac.h | 42 +-
drivers/net/wireless/ath/ath9k/main.c | 535 ++--
drivers/net/wireless/ath/ath9k/pci.c | 5 +-
drivers/net/wireless/ath/ath9k/recv.c | 7 +-
drivers/net/wireless/ath/ath9k/reg.h | 62 +-
drivers/net/wireless/ath/ath9k/xmit.c | 607 ++--
drivers/net/wireless/b43/b43.h | 2 +
drivers/net/wireless/b43/bus.c | 2 +
drivers/net/wireless/b43/main.c | 3 +
drivers/net/wireless/b43/phy_ht.c | 2 +
drivers/net/wireless/b43/phy_lcn.c | 288 ++-
drivers/net/wireless/b43/phy_n.c | 543 ++--
drivers/net/wireless/b43/phy_n.h | 4 +
drivers/net/wireless/b43/radio_2055.c | 1 +
drivers/net/wireless/b43/radio_2056.c | 2 +
drivers/net/wireless/b43/radio_2056.h | 26 -
drivers/net/wireless/b43/radio_2059.c | 2 +
drivers/net/wireless/b43/tables_nphy.c | 1 +
drivers/net/wireless/b43/tables_phy_ht.c | 2 +
drivers/net/wireless/b43/tables_phy_lcn.c | 255 ++-
drivers/net/wireless/b43/tables_phy_lcn.h | 2 +
drivers/net/wireless/iwlwifi/iwl-2000.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn-tt.h | 1 -
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 2 -
drivers/net/wireless/iwlwifi/iwl-commands.h | 7 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 19 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 22 -
drivers/net/wireless/iwlwifi/iwl-csr.h | 18 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 85 +
drivers/net/wireless/iwlwifi/iwl-dev.h | 202 +--
drivers/net/wireless/iwlwifi/iwl-helpers.h | 23 -
drivers/net/wireless/iwlwifi/iwl-pci.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 83 +-
drivers/net/wireless/iwlwifi/iwl-shared.h | 52 +
drivers/net/wireless/iwlwifi/iwl-sta.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-sv-open.c | 1 +
drivers/net/wireless/iwlwifi/iwl-trans-int-pcie.h | 110 +-
drivers/net/wireless/iwlwifi/iwl-trans-rx-pcie.c | 45 +-
drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c | 130 +-
drivers/net/wireless/iwlwifi/iwl-trans.c | 402 +--
drivers/net/wireless/iwlwifi/iwl-trans.h | 66 +-
drivers/net/wireless/libertas/if_usb.c | 21 +
drivers/net/wireless/mwifiex/join.c | 3 +-
drivers/net/wireless/mwifiex/scan.c | 6 +-
drivers/net/wireless/mwifiex/sta_ioctl.c | 9 +-
drivers/net/wireless/mwl8k.c | 8 +
drivers/net/wireless/rt2x00/rt2800.h | 3 +
drivers/net/wireless/rt2x00/rt2800lib.c | 191 +-
drivers/net/wireless/rt2x00/rt2800lib.h | 5 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 15 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 7 +-
drivers/net/wireless/rt2x00/rt2x00.h | 30 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 21 +
drivers/net/wireless/rt2x00/rt2x00mac.c | 50 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 7 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 5 +-
drivers/net/wireless/wl12xx/boot.c | 4 +-
drivers/net/wireless/wl12xx/main.c | 50 +-
drivers/net/wireless/wl12xx/scan.c | 66 +-
drivers/net/wireless/wl12xx/tx.c | 8 +-
drivers/net/wireless/wl12xx/tx.h | 1 +
drivers/net/wireless/wl12xx/wl12xx.h | 3 +
include/linux/ieee80211.h | 2 +
include/linux/nl80211.h | 57 +-
include/linux/ssb/ssb.h | 2 +-
include/net/cfg80211.h | 31 +
include/net/mac80211.h | 29 +
net/mac80211/agg-rx.c | 19 +-
net/mac80211/agg-tx.c | 42 +-
net/mac80211/cfg.c | 21 +-
net/mac80211/debugfs.c | 5 +
net/mac80211/debugfs_netdev.c | 3 +
net/mac80211/ht.c | 6 +-
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/iface.c | 6 +
net/mac80211/mesh.c | 8 +-
net/mac80211/mesh.h | 6 +-
net/mac80211/mesh_hwmp.c | 31 +-
net/mac80211/mesh_pathtbl.c | 192 +-
net/mac80211/mesh_plink.c | 2 +-
net/mac80211/mlme.c | 36 +-
net/mac80211/rc80211_minstrel_ht.c | 3 +-
net/mac80211/rx.c | 35 +-
net/mac80211/spectmgmt.c | 6 +-
net/mac80211/sta_info.c | 10 +-
net/mac80211/sta_info.h | 5 +
net/mac80211/status.c | 53 +-
net/mac80211/tx.c | 26 +-
net/mac80211/util.c | 13 +-
net/mac80211/wme.c | 16 +-
net/mac80211/wme.h | 3 +-
net/mac80211/work.c | 6 +-
net/rfkill/rfkill-regulator.c | 1 -
net/wireless/core.c | 2 +-
net/wireless/core.h | 2 -
net/wireless/lib80211_crypt_ccmp.c | 2 -
net/wireless/lib80211_crypt_tkip.c | 4 -
net/wireless/lib80211_crypt_wep.c | 4 -
net/wireless/nl80211.c | 73 +-
net/wireless/reg.c | 33 +-
net/wireless/reg.h | 2 +
net/wireless/util.c | 5 +-
137 files changed, 9864 insertions(+), 4598 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath9k/ar9480_1p0_initvals.h
create mode 100644 drivers/net/wireless/ath/ath9k/ar9480_2p0_initvals.h
Omnibus patch is available here:
http://bombadil.infradead.org/~linville/wireless-next-2011-09-19.patch.gz
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Maciej Żenczykowski @ 2011-09-19 20:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev, MuraliRaja Muniraju
In-Reply-To: <1316461375.2455.4.camel@edumazet-laptop>
The first hunk was for consistency - to always free in exit path. The
second hunk is where the lockdep bug is.
LOCKDEP gives the following (it's pretty rare):
[ 90.543085] =======================================================
[ 90.544012] [ INFO: possible circular locking dependency detected ]
[ 90.544012] 2.6.34-smp-DEV #70
[ 90.544012] -------------------------------------------------------
[ 90.544012] swapper/0 is trying to acquire lock:
[ 90.544012] (&tbl->lock){++--..}, at: [<ffffffff813c106d>]
neigh_lookup+0x42/0xbf
[ 90.544012]
[ 90.544012] but task is already holding lock:
[ 90.544012] (&(&rt_hash_locks[i])->rlock){+.-...}, at:
[<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
[ 90.544012]
[ 90.544012] which lock already depends on the new lock.
[ 90.544012]
[ 90.544012]
[ 90.544012] the existing dependency chain (in reverse order) is:
[ 90.544012]
[ 90.544012] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
[ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
[ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
[ 90.544012] [<ffffffff81430d66>] _raw_spin_lock_bh+0x36/0x45
[ 90.544012] [<ffffffff813d9659>] rt_dst_release+0x4a/0x8d
[ 90.544012] [<ffffffff813bee34>] dst_release+0x5d/0x66
[ 90.544012] [<ffffffff813af24e>] skb_release_head_state+0x1f/0xa5
[ 90.544012] [<ffffffff813aefec>] __kfree_skb+0x16/0x87
[ 90.544012] [<ffffffff813af101>] kfree_skb+0x72/0x7a
[ 90.544012] [<ffffffff813c06f9>] __neigh_event_send+0x126/0x176
[ 90.544012] [<ffffffff813c2c1b>] neigh_resolve_output+0x7f/0x267
[ 90.544012] [<ffffffff813e3057>] ip_finish_output2+0x1f2/0x221
[ 90.544012] [<ffffffff813e30ea>] ip_finish_output+0x64/0x66
[ 90.544012] [<ffffffff813e3200>] NF_HOOK_COND.clone.1+0x41/0x45
[ 90.544012] [<ffffffff813e3277>] ip_output+0x73/0x75
[ 90.544012] [<ffffffff813e1524>] dst_output+0x10/0x12
[ 90.544012] [<ffffffff813e349f>] ip_local_out+0x23/0x27
[ 90.544012] [<ffffffff813e378a>] ip_push_pending_frames+0x2e7/0x348
[ 90.544012] [<ffffffff81401a13>] udp_push_pending_frames+0x2dc/0x35c
[ 90.544012] [<ffffffff8140314e>] udp_sendmsg+0x628/0x763
[ 90.544012] [<ffffffff81409933>] inet_sendmsg+0x58/0x61
[ 90.544012] [<ffffffff813a726f>] __sock_sendmsg+0x5e/0x69
[ 90.544012] [<ffffffff813a7737>] sock_sendmsg+0xa8/0xc1
[ 90.544012] [<ffffffff813a79d9>] sys_sendmsg+0x1da/0x241
[ 90.544012] [<ffffffff813cb482>] compat_sys_sendmsg+0x14/0x16
[ 90.544012] [<ffffffff813cc081>] compat_sys_socketcall+0x13b/0x16c
[ 90.544012] [<ffffffff81059687>] sysenter_dispatch+0x7/0x2c
[ 90.544012]
[ 90.544012] -> #1 (&n->lock){++--..}:
[ 90.544012] [<ffffffff810a4910>] __lock_acquire+0xb3b/0xcda
[ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
[ 90.544012] [<ffffffff81430e81>] _raw_write_lock+0x31/0x40
[ 90.544012] [<ffffffff813c16fb>] neigh_periodic_work+0xae/0x196
[ 90.544012] [<ffffffff8108a8ca>] worker_thread+0x1fb/0x2f1
[ 90.544012] [<ffffffff8108e099>] kthread+0x7f/0x87
[ 90.544012] [<ffffffff81032a94>] kernel_thread_helper+0x4/0x10
[ 90.544012]
[ 90.544012] -> #0 (&tbl->lock){++--..}:
[ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
[ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
[ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
[ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff81405067>]
__neigh_lookup_errno.clone.0+0x24/0x40
[ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
[ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
[ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
[ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
[ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
[ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
[ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
[ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
[ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
[ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
[ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
[ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
[ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
[ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
[ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
[ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
[ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
[ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
[ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
[ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
[ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
[ 90.544012]
[ 90.544012] other info that might help us debug this:
[ 90.544012]
[ 90.544012] 3 locks held by swapper/0:
[ 90.544012] #0: (&n->timer){+.-...}, at: [<ffffffff810807e8>]
run_timer_softirq+0x187/0x2e3
[ 90.544012] #1: (slock-AF_INET){+.-...}, at: [<ffffffff814063d3>]
icmp_xmit_lock+0x35/0x47
[ 90.544012] #2: (&(&rt_hash_locks[i])->rlock){+.-...}, at:
[<ffffffff813db663>] rt_intern_hash+0xf2/0x3ad
[ 90.544012]
[ 90.544012] stack backtrace:
[ 90.544012] Pid: 0, comm: swapper Not tainted 2.6.34-smp-DEV #70
[ 90.544012] Call Trace:
[ 90.544012] <IRQ> [<ffffffff810a39c0>] print_circular_bug+0xa8/0xb7
[ 90.544012] [<ffffffff810a47ba>] __lock_acquire+0x9e5/0xcda
[ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff810a4b72>] lock_acquire+0xc3/0xe9
[ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff81430ffa>] _raw_read_lock_bh+0x39/0x48
[ 90.544012] [<ffffffff813c106d>] ? neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff813c106d>] neigh_lookup+0x42/0xbf
[ 90.544012] [<ffffffff81405067>] __neigh_lookup_errno.clone.0+0x24/0x40
[ 90.544012] [<ffffffff814054b2>] arp_bind_neighbour+0x4c/0x65
[ 90.544012] [<ffffffff813db663>] ? rt_intern_hash+0xf2/0x3ad
[ 90.544012] [<ffffffff813db815>] rt_intern_hash+0x2a4/0x3ad
[ 90.544012] [<ffffffff813dc054>] ip_route_output_slow+0x6ec/0x739
[ 90.544012] [<ffffffff81078f49>] ? _local_bh_enable_ip+0xc1/0xc7
[ 90.544012] [<ffffffff813dc574>] __ip_route_output_key+0x1bd/0x1c9
[ 90.544012] [<ffffffff81406f45>] icmp_send+0x2bf/0x3ca
[ 90.544012] [<ffffffff813c2800>] ? neigh_event_ns+0x2f/0xa2
[ 90.544012] [<ffffffff813d9739>] ipv4_link_failure+0x22/0x5c
[ 90.544012] [<ffffffff81404acd>] arp_error_report+0x31/0x3d
[ 90.544012] [<ffffffff813c1172>] neigh_invalidate+0x88/0xa3
[ 90.544012] [<ffffffff813c2a1b>] neigh_timer_handler+0x1a8/0x27f
[ 90.544012] [<ffffffff8108087a>] run_timer_softirq+0x219/0x2e3
[ 90.544012] [<ffffffff810807e8>] ? run_timer_softirq+0x187/0x2e3
[ 90.544012] [<ffffffff8109158d>] ? __run_hrtimer+0xf4/0x132
[ 90.544012] [<ffffffff813c2873>] ? neigh_timer_handler+0x0/0x27f
[ 90.544012] [<ffffffff8107908d>] ? __do_softirq+0x76/0x1cb
[ 90.544012] [<ffffffff8107910e>] __do_softirq+0xf7/0x1cb
[ 90.544012] [<ffffffff8109f74a>] ? tick_program_event+0x2a/0x2c
[ 90.544012] [<ffffffff81032b8c>] call_softirq+0x1c/0x3e
[ 90.544012] [<ffffffff81034615>] do_softirq+0x3d/0x85
[ 90.544012] [<ffffffff81078d49>] irq_exit+0x4a/0x8c
[ 90.544012] [<ffffffff8143708c>] smp_apic_timer_interrupt+0x99/0xa7
[ 90.544012] [<ffffffff81032653>] apic_timer_interrupt+0x13/0x20
[ 90.544012] <EOI> [<ffffffff81039700>] ? mwait_idle+0x85/0x92
[ 90.544012] [<ffffffff810396f7>] ? mwait_idle+0x7c/0x92
[ 90.544012] [<ffffffff81030d92>] cpu_idle+0x5c/0x79
[ 90.544012] [<ffffffff8142213f>] rest_init+0xc3/0xca
[ 90.544012] [<ffffffff8142207c>] ? rest_init+0x0/0xca
[ 90.544012] [<ffffffff81b47d77>] start_kernel+0x3e2/0x3ed
[ 90.544012] [<ffffffff81b4729f>] x86_64_start_reservations+0xaf/0xb3
[ 90.544012] [<ffffffff81b47393>] x86_64_start_kernel+0xf0/0xf7
At some point in the past of the lifetime of this kernel we grabbed
exactly the following 3 locks in the following order (where the first
2 were still held while we grabbed the 3rd):
(&tbl->lock){++--..} => (&n->lock){++--..} =>
(&(&rt_hash_locks[i])->rlock){+.-...}
Now, we have grabbed the first three (are still holding them and are
trying to grab the fourth) of these locks in this order:
(&n->timer){+.-...} => (slock-AF_INET){+.-...} =>
(&(&rt_hash_locks[i])->rlock){+.-...} => (&tbl->lock){++--..}
We're complaining that this 4th lock is being grabbed after the 3rd,
when previously it was the 1st before the 3rd - we've apparently
reversed lock ordering...
^ permalink raw reply
* Final Notice.
From: NOTICE @ 2011-09-19 20:07 UTC (permalink / raw)
Your e-Mail id have won 1,000,000 pounds in the microsoft promo, kindly fill the below details for claims
Names.
Address.
Sex.
Age.
Tel.
Occupation.
+44 7010 039 925
Thank you for your full corporation.
Andrew Scott.
^ permalink raw reply
* Re: [PATCH] net: fix lockdep issue in __neigh_event_send
From: Eric Dumazet @ 2011-09-19 19:42 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Maciej Żenczykowski, David S. Miller, netdev,
MuraliRaja Muniraju
In-Reply-To: <1316459578-23413-1-git-send-email-zenczykowski@gmail.com>
Le lundi 19 septembre 2011 à 12:12 -0700, Maciej Żenczykowski a écrit :
> From: Maciej Żenczykowski <maze@google.com>
>
> skb's should be freed once neigh->lock is no longer held.
>
> Google-Bug-Id: 4561441
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> CC: MuraliRaja Muniraju <muralira@google.com>
> ---
> net/core/neighbour.c net/core/neighbour.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 4002261..53d034a 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -949,6 +949,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
> {
> int rc;
> bool immediate_probe = false;
> + struct sk_buff *buff_to_free = NULL;
>
> write_lock_bh(&neigh->lock);
>
> @@ -969,10 +970,10 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
> } else {
> neigh->nud_state = NUD_FAILED;
> neigh->updated = jiffies;
> - write_unlock_bh(&neigh->lock);
>
> - kfree_skb(skb);
I dont understand, here we call kfree_skb() while no lock is held.
> - return 1;
> + buff_to_free = skb;
> + rc = 1;
> + goto out_unlock_bh;
> }
> } else if (neigh->nud_state & NUD_STALE) {
> NEIGH_PRINTK2("neigh %p is delayed.\n", neigh);
> @@ -986,9 +987,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
> if (skb) {
> if (skb_queue_len(&neigh->arp_queue) >=
> neigh->parms->queue_len) {
> - struct sk_buff *buff;
> - buff = __skb_dequeue(&neigh->arp_queue);
> - kfree_skb(buff);
> + buff_to_free = __skb_dequeue(&neigh->arp_queue);
> NEIGH_CACHE_STAT_INC(neigh->tbl, unres_discards);
> }
> skb_dst_force(skb);
> @@ -1002,6 +1001,7 @@ out_unlock_bh:
> else
> write_unlock(&neigh->lock);
> local_bh_enable();
> + kfree_skb(buff_to_free);
> return rc;
> }
> EXPORT_SYMBOL(__neigh_event_send);
Could you give us the lockdep report please ?
Thanks !
^ permalink raw reply
* [PATCH] net: fix lockdep issue in __neigh_event_send
From: Maciej Żenczykowski @ 2011-09-19 19:12 UTC (permalink / raw)
To: Maciej Żenczykowski, David S. Miller
Cc: netdev, Maciej Żenczykowski, MuraliRaja Muniraju
From: Maciej Żenczykowski <maze@google.com>
skb's should be freed once neigh->lock is no longer held.
Google-Bug-Id: 4561441
Signed-off-by: Maciej Żenczykowski <maze@google.com>
CC: MuraliRaja Muniraju <muralira@google.com>
---
net/core/neighbour.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 4002261..53d034a 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -949,6 +949,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
{
int rc;
bool immediate_probe = false;
+ struct sk_buff *buff_to_free = NULL;
write_lock_bh(&neigh->lock);
@@ -969,10 +970,10 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
} else {
neigh->nud_state = NUD_FAILED;
neigh->updated = jiffies;
- write_unlock_bh(&neigh->lock);
- kfree_skb(skb);
- return 1;
+ buff_to_free = skb;
+ rc = 1;
+ goto out_unlock_bh;
}
} else if (neigh->nud_state & NUD_STALE) {
NEIGH_PRINTK2("neigh %p is delayed.\n", neigh);
@@ -986,9 +987,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
if (skb) {
if (skb_queue_len(&neigh->arp_queue) >=
neigh->parms->queue_len) {
- struct sk_buff *buff;
- buff = __skb_dequeue(&neigh->arp_queue);
- kfree_skb(buff);
+ buff_to_free = __skb_dequeue(&neigh->arp_queue);
NEIGH_CACHE_STAT_INC(neigh->tbl, unres_discards);
}
skb_dst_force(skb);
@@ -1002,6 +1001,7 @@ out_unlock_bh:
else
write_unlock(&neigh->lock);
local_bh_enable();
+ kfree_skb(buff_to_free);
return rc;
}
EXPORT_SYMBOL(__neigh_event_send);
--
1.7.3.1
^ permalink raw reply related
* [PATCH 0/2] netxen: Fixes
From: Rajesh Borundia @ 2011-09-19 18:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ameen Rahman, Sony Chacko
Please Apply it to net-next tree.
Thanks
Rajesh
^ permalink raw reply
* [PATCH net-next 2/2] netxen: Add pcie workaround
From: Rajesh Borundia @ 2011-09-19 18:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ameen Rahman, Sony Chacko
In-Reply-To: <1316458192-8691-1-git-send-email-rajesh.borundia@qlogic.com>
o A performance drop was seen with firmware loaded
from flash. This workaround fixes it.
o Updated driver version to 4.0.77
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic.h | 4 +-
.../net/ethernet/qlogic/netxen/netxen_nic_main.c | 63 +++++++++++++++++++-
2 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
index 196b660..a876dff 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
@@ -53,8 +53,8 @@
#define _NETXEN_NIC_LINUX_MAJOR 4
#define _NETXEN_NIC_LINUX_MINOR 0
-#define _NETXEN_NIC_LINUX_SUBVERSION 76
-#define NETXEN_NIC_LINUX_VERSIONID "4.0.76"
+#define _NETXEN_NIC_LINUX_SUBVERSION 77
+#define NETXEN_NIC_LINUX_VERSIONID "4.0.77"
#define NETXEN_VERSION_CODE(a, b, c) (((a) << 24) + ((b) << 16) + (c))
#define _major(v) (((v) >> 24) & 0xff)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
index de18e47..82626d6 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
@@ -400,6 +400,63 @@ static void netxen_set_port_mode(struct netxen_adapter *adapter)
}
}
+#define PCI_CAP_ID_GEN 0x10
+
+static void netxen_pcie_strap_init(struct netxen_adapter *adapter)
+{
+ u32 pdevfuncsave;
+ u32 c8c9value = 0;
+ u32 chicken = 0;
+ u32 control = 0;
+ int i, pos;
+ struct pci_dev *pdev;
+
+ pdev = adapter->pdev;
+
+ chicken = NXRD32(adapter, NETXEN_PCIE_REG(PCIE_CHICKEN3));
+ /* clear chicken3.25:24 */
+ chicken &= 0xFCFFFFFF;
+ /*
+ * if gen1 and B0, set F1020 - if gen 2, do nothing
+ * if gen2 set to F1000
+ */
+ pos = pci_find_capability(pdev, PCI_CAP_ID_GEN);
+ if (pos == 0xC0) {
+ pci_read_config_dword(pdev, pos + 0x10, &control);
+ if ((control & 0x000F0000) != 0x00020000) {
+ /* set chicken3.24 if gen1 */
+ chicken |= 0x01000000;
+ }
+ dev_info(&adapter->pdev->dev, "Gen2 strapping detected\n");
+ c8c9value = 0xF1000;
+ } else {
+ /* set chicken3.24 if gen1 */
+ chicken |= 0x01000000;
+ dev_info(&adapter->pdev->dev, "Gen1 strapping detected\n");
+ if (adapter->ahw.revision_id == NX_P3_B0)
+ c8c9value = 0xF1020;
+ else
+ c8c9value = 0;
+ }
+
+ NXWR32(adapter, NETXEN_PCIE_REG(PCIE_CHICKEN3), chicken);
+
+ if (!c8c9value)
+ return;
+
+ pdevfuncsave = pdev->devfn;
+ if (pdevfuncsave & 0x07)
+ return;
+
+ for (i = 0; i < 8; i++) {
+ pci_read_config_dword(pdev, pos + 8, &control);
+ pci_read_config_dword(pdev, pos + 8, &control);
+ pci_write_config_dword(pdev, pos + 8, c8c9value);
+ pdev->devfn++;
+ }
+ pdev->devfn = pdevfuncsave;
+}
+
static void netxen_set_msix_bit(struct pci_dev *pdev, int enable)
{
u32 control;
@@ -867,7 +924,7 @@ netxen_start_firmware(struct netxen_adapter *adapter)
if (err < 0)
goto err_out;
if (err == 0)
- goto wait_init;
+ goto pcie_strap_init;
if (first_boot != 0x55555555) {
NXWR32(adapter, CRB_CMDPEG_STATE, 0);
@@ -910,6 +967,10 @@ netxen_start_firmware(struct netxen_adapter *adapter)
| (_NETXEN_NIC_LINUX_SUBVERSION);
NXWR32(adapter, CRB_DRIVER_VERSION, val);
+pcie_strap_init:
+ if (NX_IS_REVISION_P3(adapter->ahw.revision_id))
+ netxen_pcie_strap_init(adapter);
+
wait_init:
/* Handshake with the card before we register the devices. */
err = netxen_phantom_init(adapter, NETXEN_NIC_PEG_TUNE);
--
1.6.3.3
^ permalink raw reply related
* [PATCH net-next 1/2] netxen: Fix vhdr_len in case of non vlan packets.
From: Rajesh Borundia @ 2011-09-19 18:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ameen Rahman, Sony Chacko
In-Reply-To: <1316458192-8691-1-git-send-email-rajesh.borundia@qlogic.com>
o Set vlan header length to zero.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
.../net/ethernet/qlogic/netxen/netxen_nic_init.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
index d6c6357..a8259cc 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
@@ -1620,7 +1620,7 @@ netxen_process_lro(struct netxen_adapter *adapter,
int index;
u16 lro_length, length, data_offset;
u32 seq_number;
- u8 vhdr_len;
+ u8 vhdr_len = 0;
if (unlikely(ring > adapter->max_rds_rings))
return NULL;
--
1.6.3.3
^ permalink raw reply related
* GET BACK TO ME
From: Ma Guang Lu @ 2011-09-19 17:14 UTC (permalink / raw)
I am Ma Guang Lu,I have a business of $17.3M for you.Reply with personal
details for info.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [PATCH v3 04/11] SUNRPC: parametrize svc creation calls with portmapper flag
From: Jeff Layton @ 2011-09-19 18:11 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pavel Emelianov, neilb-l3A5Bk7waGM@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <4E7762D4.7090404-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On Mon, 19 Sep 2011 19:42:12 +0400
Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> 19.09.2011 19:07, Jeff Layton пишет:
> > On Mon, 19 Sep 2011 18:51:31 +0400
> > Stanislav Kinsbursky<skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> >
> >> 19.09.2011 18:08, Jeff Layton пишет:
> >>> On Tue, 13 Sep 2011 22:13:51 +0400
> >>> Stanislav Kinsbursky<skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> >>>
> >>>> This new flag ("setup_rpcbind) will be used to detect, that new service will
> >>>> send portmapper register calls. For such services we will create rpcbind
> >>>> clients and remove all stale portmap registrations.
> >>>> Also, svc_rpcb_cleanup() will be set as sv_shutdown callback for such services
> >>>> in case of this field wasn't initialized earlier. This will allow to destroy
> >>>> rpcbind clients when no other users of them left.
> >>>>
> >>>> Signed-off-by: Stanislav Kinsbursky<skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> >>>>
> >>>> ---
> >>>> include/linux/sunrpc/svc.h | 2 ++
> >>>> net/sunrpc/svc.c | 21 ++++++++++++++-------
> >>>> 2 files changed, 16 insertions(+), 7 deletions(-)
> >>>>
> >>>> diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
> >>>> index 223588a..528952a 100644
> >>>> --- a/include/linux/sunrpc/svc.h
> >>>> +++ b/include/linux/sunrpc/svc.h
> >>>> @@ -402,11 +402,13 @@ struct svc_procedure {
> >>>> * Function prototypes.
> >>>> */
> >>>> struct svc_serv *svc_create(struct svc_program *, unsigned int,
> >>>> + int setup_rpcbind,
> >>> ^^^
> >>> Instead of adding this parameter, why not
> >>> base this on the vs_hidden flag in the
> >>> svc_version? IOW, have a function that looks at
> >>> all the svc_versions for a particular
> >>> svc_program, and returns "true" if any of them
> >>> have vs_hidden unset? The mechanism you're
> >>> proposing here has the potential to be out of
> >>> sync with the vs_hidden flag.
> >>>
> >>
> >> Could you, please, clarify me this vs_hidden flag?
> >> I understand, that it's used to avoid portmap registration.
> >> But as I see, it's set only for nfs_callback_version1. But this svc_version is a
> >> part of nfs4_callback_program with nfs_callback_version4, which is not hidden.
> >> Does this flag is missed here? If not, how we can return "true" from your
> >> proposed function if any of them have vs_hidden unset?
> >>
> >> Also sockets for this program are created with SVC_SOCK_ANONYMOUS flag and we
> >> will not register any of this program versions with portmapper.
> >> Thus, from my pow, this vs_hidden flag affects only svc_unregister. And only
> >> nfs_callback_version1. This looks really strange.
> >>
> >> I.e. if we use this flag only for passing through this versions during
> >> svc_(un)register, and we actually also want to pass through
> >> nfs_callback_version4 as well (but just missed this vs_hidden flag for it), then
> >> with current patch-set we can move this flag from (vs_hidden) svc_version to
> >> svc_program and check it during svc_create instead of my home-brew
> >> "setup_rpcbind" variable.
> >>
> >
> > Agreed. The current situation is a mess, which is why I suggested a
> > cleanup and overhaul before you do this...
> >
> > The vs_hidden flag is intended to show that a particular program
> > version should not be registered with (or unregistered from) the
> > portmapper. Unfortunately, nothing looks at vs_hidden during
> > registration time, only when unregistering (as you mention).
> >
> > It's quite possible that several svc_versions declared in the kernel do
> > not have this set correctly. One thing that would be good is to audit
> > each of those.
> >
> > We currently rely on SVC_SOCK_ANONYMOUS for registration, but that
> > wasn't its original intent. It's was just convenient to use it there
> > too.
> >
> > SVC_SOCK_ANONYMOUS was (as best I can tell) originally intended for use
> > on temporary sockets that we establish on receive. So for
> > instance...when a client connects to nfsd, we need to create a new
> > socket for nfsd, but obviously we don't want to register that socket
> > with the portmapper (since nfsd should already be registered there).
> > SVC_SOCK_ANONYMOUS ensures that that socket is not registered.
> >
> > The whole scheme could probably use a fundamental re-think. I'm not
> > sure I have a great idea to propose in lieu of it, but I think adding
> > yet another flag here is probably not the best way to go.
> >
>
> Ok, thank you, Jeff.
> It looks like no mentions about portmapper are present in RFC's for NFS versions
> 4.* after a brief look.
> This SVC_SOCK_ANONYMOUS is understandable and can't be removed with this
> patch-set from my pow.
> But now I strongly believe, that we can move this vs_hidden flag from
> svc_version to svc_program structure and set it for both NFSv4.* programs.
> Hope, someone else will confirm of refute this statement.
>
The problem is nfsd. In principle, there's no real reason we have to
register NFSv4 with the portmapper at all. One could envision a
setup where a v4-only server doesn't need to run rpcbind at all. Making
it per-program may hamstring you from doing that later.
It think it would be a good thing to keep it per-version, and it's
trivial to write a routine to do what I've described. svc_creates only
happen rarely.
Just walk the pg_vers array for the program and look at each vs_hidden
value. Return true when you hit one that has vs_hidden unset. Return
false if none do. Then use that return value to replace your new flag
in this patch.
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* Mutual Benefit
From: Ma Guang Lu @ 2011-09-19 17:09 UTC (permalink / raw)
I am Ma Guang Lu,I have a business of $17.3M for you.Reply with personal
details for info.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [PATCH] tcp: fix validation of D-SACK
From: Jan Ceuleers @ 2011-09-19 17:29 UTC (permalink / raw)
To: David Miller; +Cc: zheng.z.yan, netdev, eric.dumazet
In-Reply-To: <20110918.223744.2195272571175354579.davem@davemloft.net>
On 09/19/2011 04:37 AM, David Miller wrote:
>> D-SACK is allowed to reside below snd_una. But the corresponding check
>> in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo.
>>
>> Signed-off-by: Zheng Yan<zheng.z.yan@intel.com>
>> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
> Applied, thanks.
Dave,
Have you also queued it up for stable as per Eric's remark that this was
introduced in 2.6.24?
Sorry if this is implied in your workflow.
Thanks, Jan
^ permalink raw reply
* RE: URGENT WITH DETAILS
From: DR. ABEL GREG @ 2011-09-19 16:06 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 37 bytes --]
READ CAREFULLY THE ATTACHED FILE....
[-- Attachment #2: UNITED NATION.txt --]
[-- Type: application/octet-stream, Size: 3100 bytes --]
United Nation Fraud and Money Laundering Oversight Dept
Investigation/ Monitoring/ Resolve and Consult Unit
Attn: Beneficiary,
I am Abel Greg (Fsc, Mni) United Nation representative for African Economic Crimes, Scam and Money Laundering.
I write to address you on the account of petitions addressed to the United Nation Security Council by both the government of United State of America, France, Britain re-enacting an expose to the colossal magnitude of scam, deceit and money laundering cartel ring prevalent with countries such as Gambia, Nigeria, Ghana, Benin Republic, England, Spain and United State of America. It was on account of this that United Nation deployed its African Commission on Economic Crimes to wade into this ugly trend.
Our Investigation revealed that this scam has been for a very long time but assumed global dimension in the last fifteen years. In response to these petitions to the UN, we have been engaged with the Nigeria government in the last five months, discussing the implication of this ugly payment scam in Nigeria. The high powered delegation from the UN has achieved remarkable progress in our discussion with the Federal government of Nigeria.
We are first in Nigeria because our investigation revealed that this payment scam fraud originated from Nigeria. Need not be reminded that this same scam issue formed the fulcon of the discussion between President Goodluck Jonathan of Nigeria and his United State counterpart Barrack Obama during the visit of the former between April and June 2010 as President Jonathan visited twice. He openly asked the American government to assist Nigeria in calming this ugly vice.
In the last five months our team have worked assiduously with the cooperation of the Nigeria government to reach a compromise considering that this well documented payment claim scam is a systemic method through which the highly placed Nigeria officials use in fleeing money using their proxies to make contact to you. In our candid resolution with the government of the Federal Republic of Nigeria, it was well noted that most of the victims spent enormous amount of money in this scam, therefore should be adequately compensated. Presently we have started the payment of the compensation for victims as agreed between the UN and the government of Nigeria. This commission is paying out the sum of $5.2M to all the victimized beneficiaries.
But this payment will be release to you via an ATM Visa Card which has to go through American Bankers Association Banking Network registration that will enable you access the Visa Card in your country. This registration has to be done before the Visa Card will be dispatch to your address. Contact this office with the bellow particulars urgently.
1). Your Names.......
2). Your Address.....
3). Your Direct Phone Number for accurate vetting.
4). Your ID Card / Occupation
Contact us immediately.
Dr. Abel Greg (Fsc, Mni)
United Nation representative
African Economic Crimes, Scam and Money Laundering
Email: unitednationsrep@live.com
^ 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