* Re: [Pv-drivers] vmxnet3 driver broken since 3.0?
From: Dmitry Torokhov @ 2011-12-12 17:42 UTC (permalink / raw)
To: chetan loke; +Cc: pv-drivers, sandr8, zbiggy, netdev
In-Reply-To: <CAAsGZS7QL1vQwoq7k2RX_LWeqgE4x5+00NSrRYbCu8vQoGh1Hg@mail.gmail.com>
On Mon, Dec 12, 2011 at 12:09:33PM -0500, chetan loke wrote:
> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Alessandro Salvatori
> > Sent: December 12, 2011 2:55 AM
> > To: Zbigniew Luszpinski
> > Cc: netdev@vger.kernel.org
> > Subject: Re: vmxnet3 driver broken since 3.0?
> >
> > I guess this is the change that was introduced in 3.0 and that breaks vmxnet3:
> >
> > commit 55513fb4281464e97aa1ff2b9c906ca5aed917c5
> > Author: Tom Herbert <therbert@google.com>
> > Date: Mon Oct 18 17:55:58 2010 +0000
> >
> > net: fail alloc_netdev_mq if queue count < 1
> >
> > In alloc_netdev_mq fail if requested queue_count < 1.
> >
> > Signed-off-by: Tom Herbert <therbert@google.com>
> > Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 04972a4..f44d29a 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -5511,6 +5511,12 @@ struct net_device *alloc_netdev_mq(int
> > sizeof_priv, const char *name,
> >
> > BUG_ON(strlen(name) >= sizeof(dev->name));
> >
> > + if (queue_count < 1) {
> > + pr_err("alloc_netdev: Unable to allocate device "
> > + "with zero queues.\n");
> > + return NULL;
> > + }
> > +
> > alloc_size = sizeof(struct net_device);
> > if (sizeof_priv) {
> > /* ensure 32-byte alignment of private area */
> >
> > thanks!
> > -Alessandro-
>
Hmm, apparently patch from https://lkml.org/lkml/2011/11/16/387 is not
in mailine yet... I am going to forward it to Linus/Andrew.
Thanks,
Dmitry
^ permalink raw reply
* Re: [PATCH] kref: add function for reading kref value
From: Daniel Baluta @ 2011-12-12 17:46 UTC (permalink / raw)
To: Greg KH; +Cc: Eric Dumazet, linux-kernel, netdev, adobriyan
In-Reply-To: <20111212173344.GA10162@kroah.com>
On Mon, Dec 12, 2011 at 7:33 PM, Greg KH <greg@kroah.com> wrote:
> On Mon, Dec 12, 2011 at 06:42:59PM +0200, Daniel Baluta wrote:
>> On Mon, Dec 12, 2011 at 5:41 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > Le lundi 12 décembre 2011 ŕ 17:39 +0200, Daniel Baluta a écrit :
>> >
>> >> Ok, for the moment it seems to be a bad idea. But my intention is
>> >> to integrate kref to networking code, and then to write a general
>> >> debugging tool for refs.
>> >>
>> >> Tracking down reference count problems is hard, and this tool can
>> >> really help everyone.
>> >
>> > I dont think kref will help you that much, because its used everywhere.
>> >
>> > Adding a general debugging tool will provide too much noise.
>> >
>> > Instead, we (network dev) add debugging points where we want.
>>
>> Yes, but you have to do this each time you start debugging, for a
>> particular referenced counted object.
>>
>> We must find a clever solution to avoid the noise. (e.g use
>> /proc, /sysfs, /debugfs options to trigger dumping info for
>> some/all objects with a certain state).
>
> Then use the dynamic debug infrastructure, which is there to help you
> try to handle this type of debugging on-the-fly.
>
> But again, it's not a kref issue, sorry.
I see. Thanks.
One last remark: Should we encourage people
to use kref implementation, instead of making
their own ?
What are the chances of accepting changes with
respect to this?
Just a few examples:
neighbour.h
295:#define neigh_hold(n) atomic_inc(&(n)->refcnt)
addrconf.h
219:static inline void in6_dev_hold(struct inet6_dev *idev)
Daniel.
^ permalink raw reply
* Re: [PATCH] kref: add function for reading kref value
From: Eric Dumazet @ 2011-12-12 17:57 UTC (permalink / raw)
To: Daniel Baluta; +Cc: Greg KH, linux-kernel, netdev, adobriyan
In-Reply-To: <CAEnQRZDFvD3BTJs45hvP8LVCF_SNrYZyxxiiGXXP+koFfaYAdQ@mail.gmail.com>
Le lundi 12 décembre 2011 à 19:46 +0200, Daniel Baluta a écrit :
> On Mon, Dec 12, 2011 at 7:33 PM, Greg KH <greg@kroah.com> wrote:
> > On Mon, Dec 12, 2011 at 06:42:59PM +0200, Daniel Baluta wrote:
> >> On Mon, Dec 12, 2011 at 5:41 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> > Le lundi 12 décembre 2011 ŕ 17:39 +0200, Daniel Baluta a écrit :
> >> >
> >> >> Ok, for the moment it seems to be a bad idea. But my intention is
> >> >> to integrate kref to networking code, and then to write a general
> >> >> debugging tool for refs.
> >> >>
> >> >> Tracking down reference count problems is hard, and this tool can
> >> >> really help everyone.
> >> >
> >> > I dont think kref will help you that much, because its used everywhere.
> >> >
> >> > Adding a general debugging tool will provide too much noise.
> >> >
> >> > Instead, we (network dev) add debugging points where we want.
> >>
> >> Yes, but you have to do this each time you start debugging, for a
> >> particular referenced counted object.
> >>
> >> We must find a clever solution to avoid the noise. (e.g use
> >> /proc, /sysfs, /debugfs options to trigger dumping info for
> >> some/all objects with a certain state).
> >
> > Then use the dynamic debug infrastructure, which is there to help you
> > try to handle this type of debugging on-the-fly.
> >
> > But again, it's not a kref issue, sorry.
>
> I see. Thanks.
>
> One last remark: Should we encourage people
> to use kref implementation, instead of making
> their own ?
>
> What are the chances of accepting changes with
> respect to this?
>
> Just a few examples:
>
> neighbour.h
> 295:#define neigh_hold(n) atomic_inc(&(n)->refcnt)
>
> addrconf.h
> 219:static inline void in6_dev_hold(struct inet6_dev *idev)
>
I dont know how to say this Daniel.
I dont think kref added layer is helping this. Just say no.
Since we convert about all network stack to RCU, we need much better api
than kref is offering.
(atomic_..._not_zero for example)
^ permalink raw reply
* [PATCH] SUNRPC: make SUNPRC clients list per network namespace context
From: Stanislav Kinsbursky @ 2011-12-12 18:11 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
This patch moves static SUNRPC clients list and it's lock to sunrpc_net
structure.
Currently this list is used only for debug purposes. But later it will be used
also for selecting clients by networks namespace on PipeFS mount/umount events.
Per-network namespace lists will this fater and simplier.
Note: client list is taken from current network namespace context in
rpc_show_tasks(). This will be changed with making SUNRPC sysctl's per network
namespace context.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/clnt.c | 24 ++++++++++++++----------
net/sunrpc/netns.h | 3 +++
net/sunrpc/sunrpc_syms.c | 3 +++
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index f0268ea..c87f7c8 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -38,6 +38,7 @@
#include <linux/sunrpc/bc_xprt.h>
#include "sunrpc.h"
+#include "netns.h"
#ifdef RPC_DEBUG
# define RPCDBG_FACILITY RPCDBG_CALL
@@ -50,8 +51,6 @@
/*
* All RPC clients are linked into this list
*/
-static LIST_HEAD(all_clients);
-static DEFINE_SPINLOCK(rpc_client_lock);
static DECLARE_WAIT_QUEUE_HEAD(destroy_wait);
@@ -81,16 +80,20 @@ static int rpc_ping(struct rpc_clnt *clnt);
static void rpc_register_client(struct rpc_clnt *clnt)
{
- spin_lock(&rpc_client_lock);
- list_add(&clnt->cl_clients, &all_clients);
- spin_unlock(&rpc_client_lock);
+ struct sunrpc_net *sn = net_generic(clnt->cl_xprt->xprt_net, sunrpc_net_id);
+
+ spin_lock(&sn->rpc_client_lock);
+ list_add(&clnt->cl_clients, &sn->all_clients);
+ spin_unlock(&sn->rpc_client_lock);
}
static void rpc_unregister_client(struct rpc_clnt *clnt)
{
- spin_lock(&rpc_client_lock);
+ struct sunrpc_net *sn = net_generic(clnt->cl_xprt->xprt_net, sunrpc_net_id);
+
+ spin_lock(&sn->rpc_client_lock);
list_del(&clnt->cl_clients);
- spin_unlock(&rpc_client_lock);
+ spin_unlock(&sn->rpc_client_lock);
}
static int
@@ -1857,9 +1860,10 @@ void rpc_show_tasks(void)
struct rpc_clnt *clnt;
struct rpc_task *task;
int header = 0;
+ struct sunrpc_net *sn = net_generic(current->nsproxy->net_ns, sunrpc_net_id);
- spin_lock(&rpc_client_lock);
- list_for_each_entry(clnt, &all_clients, cl_clients) {
+ spin_lock(&sn->rpc_client_lock);
+ list_for_each_entry(clnt, &sn->all_clients, cl_clients) {
spin_lock(&clnt->cl_lock);
list_for_each_entry(task, &clnt->cl_tasks, tk_task) {
if (!header) {
@@ -1870,6 +1874,6 @@ void rpc_show_tasks(void)
}
spin_unlock(&clnt->cl_lock);
}
- spin_unlock(&rpc_client_lock);
+ spin_unlock(&sn->rpc_client_lock);
}
#endif
diff --git a/net/sunrpc/netns.h b/net/sunrpc/netns.h
index d013bf2..6010c46 100644
--- a/net/sunrpc/netns.h
+++ b/net/sunrpc/netns.h
@@ -9,6 +9,9 @@ struct cache_detail;
struct sunrpc_net {
struct proc_dir_entry *proc_net_rpc;
struct cache_detail *ip_map_cache;
+
+ struct list_head all_clients;
+ spinlock_t rpc_client_lock;
};
extern int sunrpc_net_id;
diff --git a/net/sunrpc/sunrpc_syms.c b/net/sunrpc/sunrpc_syms.c
index 8ec9778..e57aa10 100644
--- a/net/sunrpc/sunrpc_syms.c
+++ b/net/sunrpc/sunrpc_syms.c
@@ -29,6 +29,7 @@ int sunrpc_net_id;
static __net_init int sunrpc_init_net(struct net *net)
{
int err;
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
err = rpc_proc_init(net);
if (err)
@@ -38,6 +39,8 @@ static __net_init int sunrpc_init_net(struct net *net)
if (err)
goto err_ipmap;
+ INIT_LIST_HEAD(&sn->all_clients);
+ spin_lock_init(&sn->rpc_client_lock);
return 0;
err_ipmap:
^ permalink raw reply related
* Re: [PATCH] kref: add function for reading kref value
From: Greg KH @ 2011-12-12 18:33 UTC (permalink / raw)
To: Daniel Baluta; +Cc: Eric Dumazet, linux-kernel, netdev, adobriyan
In-Reply-To: <CAEnQRZDFvD3BTJs45hvP8LVCF_SNrYZyxxiiGXXP+koFfaYAdQ@mail.gmail.com>
On Mon, Dec 12, 2011 at 07:46:33PM +0200, Daniel Baluta wrote:
> On Mon, Dec 12, 2011 at 7:33 PM, Greg KH <greg@kroah.com> wrote:
> > On Mon, Dec 12, 2011 at 06:42:59PM +0200, Daniel Baluta wrote:
> >> On Mon, Dec 12, 2011 at 5:41 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> > Le lundi 12 décembre 2011 ŕ 17:39 +0200, Daniel Baluta a écrit :
> >> >
> >> >> Ok, for the moment it seems to be a bad idea. But my intention is
> >> >> to integrate kref to networking code, and then to write a general
> >> >> debugging tool for refs.
> >> >>
> >> >> Tracking down reference count problems is hard, and this tool can
> >> >> really help everyone.
> >> >
> >> > I dont think kref will help you that much, because its used everywhere.
> >> >
> >> > Adding a general debugging tool will provide too much noise.
> >> >
> >> > Instead, we (network dev) add debugging points where we want.
> >>
> >> Yes, but you have to do this each time you start debugging, for a
> >> particular referenced counted object.
> >>
> >> We must find a clever solution to avoid the noise. (e.g use
> >> /proc, /sysfs, /debugfs options to trigger dumping info for
> >> some/all objects with a certain state).
> >
> > Then use the dynamic debug infrastructure, which is there to help you
> > try to handle this type of debugging on-the-fly.
> >
> > But again, it's not a kref issue, sorry.
>
> I see. Thanks.
>
> One last remark: Should we encourage people
> to use kref implementation, instead of making
> their own ?
Yes, where possible.
But, as the network developers keep pointing out, this is not a place
for a kref.
thanks,
greg k-h
^ permalink raw reply
* pull request: wireless-next 2011-12-12
From: John W. Linville @ 2011-12-12 19:35 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 18226 bytes --]
commit f2abba4921b945a6f8aca36fcba634c22797ba78
Dave,
This is the latest round of wireless updates intended for 3.3.
This includes big refactoring activities in bluetooth and wl12xx.
Beyond that, there is with the usual level of activity around ath9k
and iwlwifi as well as a variety of other patches here and there. One
highlight is the introduction of HT operations for IBSS in mac80211.
Please let me know if there are problems!
John
---
The following changes since commit dfd56b8b38fff3586f36232db58e1e9f7885a605:
net: use IS_ENABLED(CONFIG_IPV6) (2011-12-11 18:25:16 -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 (2):
nl80211: Parse channel type attribute in an ibss join request
mac80211: Add HT operation modes for IBSS
Andre Guedes (4):
Bluetooth: Rename mgmt_inquiry_failed()
Bluetooth: mgmt_stop_discovery_failed()
Bluetooth: Add dev_flags to struct hci_dev
Bluetooth: LE Set Scan Parameter Command
Andrei Emeltchenko (10):
Bluetooth: Move scope of kernel parameter enable_hs
Bluetooth: Do not set HCI_RAW when HS enabled
Bluetooth: Allow to set AMP type for virtual HCI
Bluetooth: making enable_hs independent from L2CAP
Bluetooth: Use queue in the device list
Bluetooth: Add HCI Read Flow Control Mode function
Bluetooth: remove old code
Bluetooth: Correct version check in hci_setup
Bluetooth: Remove magic bluetooth version numbers
Bluetooth: trivial: correct check for LMP version
Arik Nemtsov (5):
wl12xx: keep beacon-filtering enabled during STA operation
wl12xx: configure probe-resp template according to notification
wl12xx: indicate probe-resp offloading support
wl12xx: avoid bail out when probe-resp is not set by mac80211
wl12xx: leave IV calculation to HW for CCMP
Ben Greear (1):
mac80211: Remove WARN_ON in apply-ht-override logic.
Bing Zhao (1):
Bluetooth: btmrvl: support Marvell Bluetooth device SD8797
Brian Gix (9):
Bluetooth: Add HCI defines for User Passkey entry
Bluetooth: Add MGMT opcodes for Passkey Entry
Bluetooth: Add MGMT event for Passkey Entry
Bluetooth: User Pairing Response restructuring
Bluetooth: Differentiate LE User Pairing Responses
Bluetooth: Add User Passkey Response handling
Bluetooth: Add HCI User Passkey Req Evt handling
Bluetooth: Cleanup blkcipher on SMP termination
Bluetooth: Centralize SMP pairing failure handling
Cong Wang (1):
btusb: fix a memory leak in btusb_send_frame()
David Herrmann (2):
Bluetooth: cmtp: Fix module reference
Bluetooth: bnep: Fix module reference
Don Fry (4):
iwlwifi: rename iwl-agn-ucode as iwl-ucode
iwlwifi: replace iwl_priv reference with iwl_trans for ucode.
iwlwifi: move ucode_type from iwl_priv to iwl_shared
iwlwifi: move ucode notification from iwl_priv to iwl_shared
Eliad Peller (69):
wl12xx: replace wl->mac_addr with vif->addr
wl12xx: start reworking the init sequence
wl12xx: define wl12xx_vif
wl12xx: move rate_set into wlvif
wl12xx: move basic_rate into wlvif
wl12xx: replace wl->bssid with vif->bss_conf.bssid
wl12xx: move bss_type into wlvif
wl12xx: remove set_bss_type field
wl12xx: move p2p into wlvif
wl12xx: move ssid and ssid_len into wlvif
wl12xx: move probereq into wlvif
wl12xx: move aid into wlvif
wl12xx: move role_id into wlvif
wl12xx: move dev_role_id into wlvif
wl12xx: move sta_hlid into wlvif
wl12xx: move ap_global_hlid and ap_bcast_hlid into wlvif
wl12xx: move session_counter into wlvif
wl12xx: move some logic into wl12xx_init_vif_data
wl12xx: move dev_hlid into wlvif
wl12xx: move beacon_int into wlvif
wl12xx: move default_key into wlvif
wl12xx: move pspoll_work into wlvif
wl12xx: move ps_compl into wlvif
wl12xx: move ps_poll_failures and psm_entry_retry into wlvif
wl12xx: move rssi_thold and last_rssi_event into wlvif
wl12xx: move ba fields into wlvif
wl12xx: move ap_hlid_map into wlvif.ap
wl12xx: move recorded_ap_keys into wlvif
wl12xx: refactor fw init into a new function
wl12xx: move last_tx_hlid into wlvif
wl12xx: unify STA and AP tx_queue mechanism
wl12xx: move some functions from remove_interface() to stop()
wl12xx: move bitrate_masks into wlvif
wl12xx: add vifs list
wl12xx: support multiple vifs in the tx path
wl12xx: configure sleep_policy according to active roles
wl12xx: make event handling support multirole
wl12xx: move tx_security_seq into wlvif
wl12xx: rearm rx streaming per vif
wl12xx: make WL1271_FLAG_STA_ASSOCIATED flag per-vif
wl12xx: make WL1271_FLAG_IBSS_JOINED flag per-vif
wl12xx: make WL1271_FLAG_AP_STARTED flag per-vif
wl12xx: make WL1271_FLAG_PSM flag per-vif
wl12xx: make WL1271_FLAG_STA_STATE_SENT flag per-vif
wl12xx: make WL1271_FLAG_RX_STREAMING_STARTED flag per-vif
wl12xx: make WL1271_FLAG_IF_INITIALIZED per-vif
wl12xx: make WL1271_FLAG_PSPOLL_FAILURE flag per-vif
wl12xx: make WL1271_FLAG_CS_PROGRESS flag per-vif
wl12xx: add band field to wlvif
wl12xx: add channel field to wlvif
wl12xx: add power_level field to wlvif
wl12xx: make op_config configure all vifs
wl12xx: replace all remaining wl->vif references
wl12xx: call stop() on recovery
wl12xx: use dynamic rate policies
wl12xx: add elp wakeup/sleep calls to add_interface
wl12xx: use round-robin policy for tx
wl12xx: handle injected packets
wl12xx: couple role_start_dev with roc
wl12xx: reconfigure rate policies on set_bitrate_mask
wl12xx: add vifs_state debugfs key
wl12xx: clear wl->vif on remove_interface
wl12xx: use p2p rate index when the skb has the NO_CCK flag
wl12xx: handle idle changes per-interface
wl12xx: init CMD_TEMPL_KLV to sizeof(ieee80211_qos_hdr)
wl12xx: don't explicitly check for unjoined ibss
wl12xx: fix testmode test/interrogate commands
wl12xx: remove redundant commands from plt init
wl12xx: send testmode reply in wl1271_tm_cmd_interrogate
Eyal Shapira (2):
wl12xx: fix SDIO suspend/resume
wl12xx: minor fix in sched_scan_ssid_list
Felipe Balbi (8):
wl12xx: add an sdio glue struct to keep wl and device side-by-side
wl12xx: add an spi glue struct to keep wl and device side-by-side
wl12xx: add a platform device to the sdio module
wl12xx: add a platform device to the spi module
wl12xx: add platform driver to the core module
wl12xx: move common init code from bus modules to main
wl12xx: mark some symbols static
wl12xx: drop unneeded plat_dev
Felix Fietkau (4):
ath9k: always issue a full hw reset after waking up from full-sleep mode
ath9k: rework power state handling
ath9k: only drop packets in drv_flush when asked to
ath9k: cancel all workqueue activity when going idle
Gustavo F. Padovan (5):
Bluetooth: Rename l2cap_check_security()
Bluetooth: Allow L2CAP to increase the security level
Bluetooth: Only set ack_timer if we didn't send and ack
Bluetooth: Add user readable debug for state changes
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth
Guy Eilam (1):
wl12xx: set scan probe requests rate according to the no_cck flag
Hsu, Kenny (3):
iwlwifi: add tm commands for sram reading by dumpit
iwlwifi: add generic chunk size of tm dumpit packet
iwlwifi: add WOWLAN uCode loading support by testmode
Johan Hedberg (10):
Bluetooth: Add public/random LE address information to mgmt messages
Bluetooth: Fix deadlock with mgmt_pair_device
Bluetooth: Add proper response to mgmt_remove_keys command
Bluetooth: Add status parameter to mgmt_disconnect response
Bluetooth: Add address type to mgmt_pair_device
Bluetooth: Fix mgmt_pair_device imediate error responses
Bluetooth: Return success instead of EALREADY for mgmt commands
Bluetooth: Create a unique mgmt error code hierarchy
Bluetooth: Add missing cmd_complete for mgmt_load_link_keys
Bluetooth: Pass all message parameters to mgmt_start_discovery
Johannes Berg (7):
iwlagn: remove TX_REPLY_LIMIT debug
iwlagn: remove HC_DUMP debug
iwlagn: remove MACDUMP debug
iwlagn: make debug levels more readable
mac80211: fix retransmit
mac80211: accept public action frames with mismatched BSSID
wireless: disable wext sysfs by default
John W. Linville (3):
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-next
wl12xx: silence tx_attr uninitialized warning in wl1271_tx_fill_hdr
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Kenny Hsu (1):
iwlwifi: add range checking in tm sram read command
Larry Finger (1):
rtl8192c: Do not log firmware load message unless actually done
Luciano Coelho (10):
wl12xx: remove sdio_test module
wl12xx: move debugging definitions to a separate file
wl12xx: sdio: use dev_dbg instead of wl1271_debug
wl12xx: spi: use dev_err instead of wl1271_error
wl12xx: use the same plat dev name for both SPI and SDIO
wl12xx: change blocksize alignment quirk to negative
wl12xx: use the same SDIO block size for all different chips
wl12xx: increase firmware upload chunk size
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into wl12xx-next
Merge branch 'wl12xx-next' into for-linville
Mohammed Shafi Shajakhan (2):
ath9k_hw: sync to latest AR9462 INI
ath9k: clarify max_streams for AR9462
Nikolay Martynov (5):
ath9k: trivial: cosmetic fix in calibration debug log
ath9k: change calibration debug log to output all calibration types
ath9k: use config.enable_ani to check if ani should be performed
ath9k: enable ANI for ar9100 chips
iwlwifi regression in 20111205 merge
Pontus Fuchs (3):
wl12xx: Validate FEM index from ini file and FW
wl12xx: Check buffer bound when processing nvs data
wl12xx: Print nvs/fw file name if loading fails.
Rafał Miłecki (1):
bcma: pci: use fixed windows when possible
Shahar Lev (1):
wl12xx: remove warning message during IBSS Tx
Simon Wunderlich (1):
mac80211: handle protection mode, RIFS and ADDBA for HT IBSS
Szymon Janc (5):
Bluetooth: Fix possible NULL pointer derefence in l2cap code
Bluetooth: Simplify l2cap_add_to_srej_queue
Bluetooth: Refactor loop in l2cap_retransmit_one_frame
Bluetooth: Simplify __l2cap_global_chan_by_addr
Bluetooth: Fix some checkpatch.pl errors and warnings
Thomas Meyer (2):
rt2x00: Use kcalloc instead of kzalloc to allocate array
iwlegacy: Use kcalloc instead of kzalloc to allocate array
Wey-Yi Guy (2):
iwlwifi: declare static for iwl_sram_cleanup function
iwlwifi: Rename file name from iwl-sv-open.c to iwl-testmode.c
Documentation/feature-removal-schedule.txt | 3 +-
drivers/bcma/host_pci.c | 32 +-
drivers/bluetooth/Kconfig | 6 +-
drivers/bluetooth/btmrvl_sdio.c | 15 +-
drivers/bluetooth/btusb.c | 3 +-
drivers/bluetooth/hci_vhci.c | 8 +
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 2 +-
.../net/wireless/ath/ath9k/ar9462_2p0_initvals.h | 42 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 5 +-
drivers/net/wireless/ath/ath9k/hw.c | 6 +-
drivers/net/wireless/ath/ath9k/hw.h | 1 -
drivers/net/wireless/ath/ath9k/init.c | 2 +
drivers/net/wireless/ath/ath9k/main.c | 204 +--
drivers/net/wireless/ath/ath9k/pci.c | 21 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
drivers/net/wireless/iwlegacy/common.c | 5 +-
drivers/net/wireless/iwlwifi/Makefile | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 51 -
drivers/net/wireless/iwlwifi/iwl-agn-rx.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 20 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 15 +-
drivers/net/wireless/iwlwifi/iwl-debug.h | 62 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 41 +-
drivers/net/wireless/iwlwifi/iwl-mac80211.c | 15 +-
drivers/net/wireless/iwlwifi/iwl-shared.h | 76 +
.../iwlwifi/{iwl-sv-open.c => iwl-testmode.c} | 162 ++-
drivers/net/wireless/iwlwifi/iwl-testmode.h | 34 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-trans.h | 7 -
.../iwlwifi/{iwl-agn-ucode.c => iwl-ucode.c} | 163 ++-
drivers/net/wireless/rt2x00/rt2x00dev.c | 4 +-
drivers/net/wireless/rtlwifi/rtl8192c/fw_common.c | 2 +-
drivers/net/wireless/wl12xx/Kconfig | 10 -
drivers/net/wireless/wl12xx/Makefile | 3 -
drivers/net/wireless/wl12xx/acx.c | 146 +-
drivers/net/wireless/wl12xx/acx.h | 83 +-
drivers/net/wireless/wl12xx/boot.c | 15 +
drivers/net/wireless/wl12xx/cmd.c | 368 +++--
drivers/net/wireless/wl12xx/cmd.h | 50 +-
drivers/net/wireless/wl12xx/conf.h | 4 +
drivers/net/wireless/wl12xx/debug.h | 101 +
drivers/net/wireless/wl12xx/debugfs.c | 141 ++-
drivers/net/wireless/wl12xx/event.c | 214 ++-
drivers/net/wireless/wl12xx/event.h | 3 -
drivers/net/wireless/wl12xx/init.c | 458 +++---
drivers/net/wireless/wl12xx/init.h | 7 +-
drivers/net/wireless/wl12xx/io.c | 12 +-
drivers/net/wireless/wl12xx/io.h | 23 +-
drivers/net/wireless/wl12xx/main.c | 1967 +++++++++++--------
drivers/net/wireless/wl12xx/ps.c | 56 +-
drivers/net/wireless/wl12xx/ps.h | 9 +-
drivers/net/wireless/wl12xx/reg.h | 2 +-
drivers/net/wireless/wl12xx/rx.c | 34 +-
drivers/net/wireless/wl12xx/scan.c | 102 +-
drivers/net/wireless/wl12xx/scan.h | 8 +-
drivers/net/wireless/wl12xx/sdio.c | 259 ++--
drivers/net/wireless/wl12xx/sdio_test.c | 543 ------
drivers/net/wireless/wl12xx/spi.c | 214 +--
drivers/net/wireless/wl12xx/testmode.c | 76 +-
drivers/net/wireless/wl12xx/tx.c | 373 +++--
drivers/net/wireless/wl12xx/tx.h | 11 +-
drivers/net/wireless/wl12xx/wl12xx.h | 377 ++--
drivers/net/wireless/wl12xx/wl12xx_80211.h | 5 -
drivers/net/wireless/wl12xx/wl12xx_platform_data.c | 4 +-
include/linux/ieee80211.h | 17 +
include/linux/nl80211.h | 2 +
include/linux/wl12xx.h | 5 +-
include/net/bluetooth/bluetooth.h | 5 +
include/net/bluetooth/hci.h | 38 +
include/net/bluetooth/hci_core.h | 28 +-
include/net/bluetooth/l2cap.h | 2 +-
include/net/bluetooth/mgmt.h | 49 +-
include/net/cfg80211.h | 11 +
net/bluetooth/bnep/core.c | 8 +-
net/bluetooth/cmtp/core.c | 5 +-
net/bluetooth/hci_conn.c | 2 +-
net/bluetooth/hci_core.c | 31 +-
net/bluetooth/hci_event.c | 152 ++-
net/bluetooth/l2cap_core.c | 101 +-
net/bluetooth/l2cap_sock.c | 16 +-
net/bluetooth/mgmt.c | 660 +++++--
net/bluetooth/smp.c | 32 +-
net/mac80211/agg-rx.c | 2 +
net/mac80211/agg-tx.c | 26 +-
net/mac80211/ht.c | 6 +-
net/mac80211/ibss.c | 101 +-
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/main.c | 3 +-
net/mac80211/rx.c | 16 +-
net/mac80211/tx.c | 5 +-
net/mac80211/util.c | 5 +
net/wireless/Kconfig | 7 +-
net/wireless/chan.c | 12 +-
net/wireless/nl80211.c | 32 +-
98 files changed, 4642 insertions(+), 3476 deletions(-)
rename drivers/net/wireless/iwlwifi/{iwl-sv-open.c => iwl-testmode.c} (83%)
rename drivers/net/wireless/iwlwifi/{iwl-agn-ucode.c => iwl-ucode.c} (81%)
create mode 100644 drivers/net/wireless/wl12xx/debug.h
delete mode 100644 drivers/net/wireless/wl12xx/sdio_test.c
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: BCM43224 hanging [3.2.0-rc4-00248-gb835c0f] (was: BCM43224: 00:00:00:00:00:00 address (3.2.0-rc3-00099-g883381d))
From: Nico Schottelius @ 2011-12-12 18:16 UTC (permalink / raw)
To: Nico Schottelius, Arend van Spriel, LKML, netdev, b43-dev,
Greg KH
In-Reply-To: <20111207190821.GA1775@schottelius.org>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
Update:
It seems AFTER one or more (not yet sure how many
are needed) successful suspend & resume
cycles brcmsmac actually works. Pretty interesting,
because usually wlan drivers stop working after supend...
Attached is the dmesg output of a currently working
system!
Let me know whether we can debug this issue somehow
/ you need more information to do so.
Cheers,
Nico
--
PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
[-- Attachment #2: dmesg.xz --]
[-- Type: application/octet-stream, Size: 20672 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] tcp: fix spurious undos in CA_Open
From: Neal Cardwell @ 2011-12-12 19:40 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David Miller, Netdev, nanditad, Yuchung Cheng, therbert
In-Reply-To: <alpine.DEB.2.00.1112121359470.15137@wel-95.cs.helsinki.fi>
On Mon, Dec 12, 2011 at 7:05 AM, Ilpo Järvinen
<ilpo.jarvinen@helsinki.fi> wrote:
> On Mon, 28 Nov 2011, Neal Cardwell wrote:
>
>> On Sun, Nov 27, 2011 at 6:58 PM, David Miller <davem@davemloft.net> wrote:
>>
>> >> Also, one (serious) word of caution! This change, by its extending of
>> >> CA_Open state, is somewhat similar to what I made FRTO years ago, and
>> >> managed to introduces subtle breaking to the state machine. Please check
>> >> that the problem similar to what was fixed by
>> >> a1c1f281b84a751fdb5ff919da3b09df7297619f does not reappear (possibly in
>> >> some other form causing spurious undos). ...To me it seems that
>> >> tcp_packet_delayed might be similarly confused after the given patch.
>> >
>> > Neil, please look into this so we can have any such issues fixed
>> > in time for the next merge window.
>>
>> Absolutely. I will look into the areas that Ilpo mentioned.
>
> Unfortunately nothing has happened? So I finally had to come up something
> myself. ...Compile tested only.
Sorry for the radio silence, but I have been looking at this. So far
it's been a time-consuming process, as we've uncovered a number of
pre-existing issues in tcp_packet_delayed that seem like quite serious
bugs:
1) tcp_packet_delayed implicitly assumes, but does not verify, that
the ACK in question (whose ECR field precedes retrans_stamp) covers
all retransmitted segments. So if we retransmit segments 1 and 2, and
then get an ACK for 1 that has an ECR indicating it was for the
original copy of segment 1, then we undo, even in cases where segment
2 really was lost and needed to be retransmitted.
2) tcp_packet_delayed implicitly assumes that if we retransmit a
packet that was truly lost then any ACK for the retransmitted instance
of that packet will echo the timestamp field in the retransmitted
packet. But if the receiver is implementing delayed ACKs and correctly
implements timestamps per RFC 1323, then the receiver will be obeying
this clause: "Thus, when delayed ACKs are in use, the receiver should
reply with the TSval field from the earliest unacknowledged segment."
Thus tcp_packet_delayed can cause spurious undos in the following
circumstances:
- send segment 1 with tsval 10
- receiver is doing delayed ACKs and does not ACK 1 but sets TS.Recent to 10
- send segment 2 with tsval 20
- segment 2 is lost in transit
- RTO, retransmit segment 2 with tsval 30
- receiver sends delayed ACK for packets 1 and 2 with TS.Recent of 10
- sender receives ACK for packet 2 with tsecho of 10, lower than 30,
and thinks RTO was spurious
For better or worse, both of these bugs appear to be inherited from
the Eifel Detection Algorithm RFC (RFC 3522).
In any case, we've been working on coming up with a solution for these issues.
> --
> [PATCH 1/1] tcp: fix spurious undos in CA_Open
>
> There's a landmine in tcp_packet_delayed. In CA_Open the
> retrans_stamp is very eagerly cleared which falsely triggers
> packet-delayed detection. Therefore this code cannot be used
> in CA_Open if the retrans_stamp was already cleared.
>
> This became issue once DSACK detection was extended to happen
> in CA_Open state too (f698204bd0b, tcp: allow undo from
> reordered DSACKs). Essentially the whole congestion control
> is disabled because the undos now always restore the previous
> window. I wonder if this was already in production... ...at
> least the Internet didn't melt ;-).
I'm pretty sure this commit is unnecessary. It seems like a NOP. Note
that tcp_may_undo and tcp_packet_delayed are never called in state
TCP_CA_Open. tcp_may_undo is only called from tcp_try_undo_recovery,
tcp_try_undo_partial, and tcp_try_undo_loss, and to call any of these
functions you must be in either TCP_CA_Loss or TCP_CA_Recovery. Only
tcp_try_undo_dsack is called from TCP_CA_Open, but it makes no
reference to retrans_stamp.
Please let me know if I'm missing something, or if there's a specific
scenario you're concerned about.
thanks,
neal
^ permalink raw reply
* Re: pull request: wireless-next 2011-12-12
From: David Miller @ 2011-12-12 21:11 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111212193521.GB9508@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 12 Dec 2011 14:35:21 -0500
> This is the latest round of wireless updates intended for 3.3.
> This includes big refactoring activities in bluetooth and wl12xx.
> Beyond that, there is with the usual level of activity around ath9k
> and iwlwifi as well as a variety of other patches here and there. One
> highlight is the introduction of HT operations for IBSS in mac80211.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* [PATCH] net: do not pass vlan pkts to real dev pkt handler also
From: Vasu Dev @ 2011-12-12 22:19 UTC (permalink / raw)
To: netdev; +Cc: jpirko, devel
The orig_dev has to be updated before going another round
for vlan pkts, otherwise currently unmodified real orig_dev
causes vlan pkt delivered to real orig_dev also.
The fcoe stack doesn't expects its vlan pkts on real dev
and it causes crash in fcoe stack.
This wasn't issue untill __netif_receive_skb recursive calling
was removed with this commit 0dfe178, so this patch restores
orig_dev uses as it was prior to that commit but still w/o
recursive calling to __netif_receive_skb.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
---
net/core/dev.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index f494675..adbcd7a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3222,9 +3222,10 @@ ncls:
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = NULL;
}
- if (vlan_do_receive(&skb, !rx_handler))
+ if (vlan_do_receive(&skb, !rx_handler)) {
+ orig_dev = skb->dev;
goto another_round;
- else if (unlikely(!skb))
+ } else if (unlikely(!skb))
goto out;
}
^ permalink raw reply related
* Re: [PATCH RESEND] sctp: fix incorrect overflow check on autoclose
From: Vladislav Yasevich @ 2011-12-12 22:18 UTC (permalink / raw)
To: Xi Wang
Cc: netdev, linux-sctp, Andrew Morton, Andrei Pelinescu-Onciul,
David S. Miller
In-Reply-To: <8EEC521A-CA38-4CE9-BCFD-BA6FC9A85D18@gmail.com>
On 12/09/2011 01:04 PM, Xi Wang wrote:
> On Dec 9, 2011, at 12:38 PM, Vladislav Yasevich wrote:
>> I think this should be u32 since that's what sp->autoclose is.
>
> Do you mean something like this?
>
> min_t(u32, sp->autoclose, MAX_SCHEDULE_TIMEOUT / HZ)
>
> On 64-bit platform this would limit autoclose for no good
> reason to
>
> (u32)(MAX_SCHEDULE_TIMEOUT / HZ),
>
> which is basically 0x978d4fdf (assuming HZ is 250). I guess the
> intention was to allow autoclose to be any u32 on 64-bit platform.
>
Hm.. this is a bit strange. This makes it so that on 32 bit platforms
we have one upper bound for autoclose and on 64 we have another even though
the type is platform dependent. This could be considered a regression by
applications.
In addition this would result in confusion to user since the values
between setsockopt() and getsockopt() for autoclose would be different.
Looking at the latest spec, it actually looks like we are completely
mis-interpreting autoclose. It's supposed to be in seconds.
For now, I'd suggest to make this consistent between 32 and 64 bits.
Having inconsistent values seems strange.
As a next set the api needs to be fixed to accept seconds as
argument.
-vlad
^ permalink raw reply
* Re: [PATCH] net: do not pass vlan pkts to real dev pkt handler also
From: Jiri Pirko @ 2011-12-12 22:56 UTC (permalink / raw)
To: Vasu Dev; +Cc: netdev, devel, eric.dumazet
In-Reply-To: <20111212221923.5356.43629.stgit@vifc.jf.intel.com>
Mon, Dec 12, 2011 at 11:19:23PM CET, vasu.dev@intel.com wrote:
>The orig_dev has to be updated before going another round
>for vlan pkts, otherwise currently unmodified real orig_dev
>causes vlan pkt delivered to real orig_dev also.
>
>The fcoe stack doesn't expects its vlan pkts on real dev
>and it causes crash in fcoe stack.
Could you please provide more info on where exactly it would crash and
why?
Thanks.
Jirka
>
>This wasn't issue untill __netif_receive_skb recursive calling
>was removed with this commit 0dfe178, so this patch restores
>orig_dev uses as it was prior to that commit but still w/o
>recursive calling to __netif_receive_skb.
>
>Signed-off-by: Vasu Dev <vasu.dev@intel.com>
>---
>
> net/core/dev.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/net/core/dev.c b/net/core/dev.c
>index f494675..adbcd7a 100644
>--- a/net/core/dev.c
>+++ b/net/core/dev.c
>@@ -3222,9 +3222,10 @@ ncls:
> ret = deliver_skb(skb, pt_prev, orig_dev);
> pt_prev = NULL;
> }
>- if (vlan_do_receive(&skb, !rx_handler))
>+ if (vlan_do_receive(&skb, !rx_handler)) {
>+ orig_dev = skb->dev;
> goto another_round;
>- else if (unlikely(!skb))
>+ } else if (unlikely(!skb))
> goto out;
> }
>
>
^ permalink raw reply
* Re: [Pv-drivers] vmxnet3 driver broken since 3.0?
From: Alessandro Salvatori @ 2011-12-12 23:29 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: chetan loke, pv-drivers, zbiggy, netdev
In-Reply-To: <20111212174244.GA31005@dtor-ws.eng.vmware.com>
can you please make sure this also goes into linux-stable for 3.0.x and 3.1.x?
thanks!
-Alessandro-
Here i am, A young man,
A crashing computer program,
Here is a pen, write out my name...
(from: The Servant - Orchestra)
On Mon, Dec 12, 2011 at 09:42, Dmitry Torokhov <dtor@vmware.com> wrote:
> On Mon, Dec 12, 2011 at 12:09:33PM -0500, chetan loke wrote:
>> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Alessandro Salvatori
>> > Sent: December 12, 2011 2:55 AM
>> > To: Zbigniew Luszpinski
>> > Cc: netdev@vger.kernel.org
>> > Subject: Re: vmxnet3 driver broken since 3.0?
>> >
>> > I guess this is the change that was introduced in 3.0 and that breaks vmxnet3:
>> >
>> > commit 55513fb4281464e97aa1ff2b9c906ca5aed917c5
>> > Author: Tom Herbert <therbert@google.com>
>> > Date: Mon Oct 18 17:55:58 2010 +0000
>> >
>> > net: fail alloc_netdev_mq if queue count < 1
>> >
>> > In alloc_netdev_mq fail if requested queue_count < 1.
>> >
>> > Signed-off-by: Tom Herbert <therbert@google.com>
>> > Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>> > Signed-off-by: David S. Miller <davem@davemloft.net>
>> >
>> > diff --git a/net/core/dev.c b/net/core/dev.c
>> > index 04972a4..f44d29a 100644
>> > --- a/net/core/dev.c
>> > +++ b/net/core/dev.c
>> > @@ -5511,6 +5511,12 @@ struct net_device *alloc_netdev_mq(int
>> > sizeof_priv, const char *name,
>> >
>> > BUG_ON(strlen(name) >= sizeof(dev->name));
>> >
>> > + if (queue_count < 1) {
>> > + pr_err("alloc_netdev: Unable to allocate device "
>> > + "with zero queues.\n");
>> > + return NULL;
>> > + }
>> > +
>> > alloc_size = sizeof(struct net_device);
>> > if (sizeof_priv) {
>> > /* ensure 32-byte alignment of private area */
>> >
>> > thanks!
>> > -Alessandro-
>>
>
> Hmm, apparently patch from https://lkml.org/lkml/2011/11/16/387 is not
> in mailine yet... I am going to forward it to Linus/Andrew.
>
> Thanks,
> Dmitry
>
^ permalink raw reply
* Re: [PATCH] ipv6: Fix for adding multicast route for loopback device automatically.
From: David Miller @ 2011-12-12 23:49 UTC (permalink / raw)
To: lw; +Cc: netdev, yoshfuji
In-Reply-To: <4EE00BAD.3010409@cn.fujitsu.com>
From: Li Wei <lw@cn.fujitsu.com>
Date: Thu, 08 Dec 2011 08:58:21 +0800
> The problem is that the resulting routing table depends on the sequence
> of interface's initialization and in some situation, that would block all
> muticast packets. Suppose there are two interfaces on my computer
> (lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
> table(for multicast) would be
>
> # ip -6 route show | grep ff00::
> unreachable ff00::/8 dev lo metric 256 error -101
> ff00::/8 dev eth0 metric 256
>
> When sending multicasting packets, routing subsystem will return the first
> route entry which with a error set to -101(ENETUNREACH).
>
> I know the kernel will set the default ipv6 address for 'lo' when it is up
> and won't set the default multicast route for it, but there is no reason to
> stop 'init' program from setting address for 'lo', and that is exactly what
> systemd did.
Ok, I added this more detailed explanation to the commit message and
applied your patch.
Probably it is a good idea to explain things completely, with all details
and examples, in the commit message from the beginning :-)
^ permalink raw reply
* Re: [PATCH] ipip, sit: copy parms.name after register_netdevice
From: David Miller @ 2011-12-12 23:51 UTC (permalink / raw)
To: artisdom; +Cc: jpirko, jwboyer, netdev, linux-kernel
In-Reply-To: <20111208104619.GA20150@ted-OptiPlex-380>
From: Ted Feng <artisdom@gmail.com>
Date: Thu, 8 Dec 2011 18:46:21 +0800
> From: Ted Feng <artisdom@gmail.com>
>
> Same fix as 731abb9cb2 for ipip and sit tunnel.
> Commit 1c5cae815d removed an explicit call to dev_alloc_name in
> ipip_tunnel_locate and ipip6_tunnel_locate, because register_netdevice
> will now create a valid name, however the tunnel keeps a copy of the
> name in the private parms structure. Fix this by copying the name back
> after register_netdevice has successfully returned.
>
> This shows up if you do a simple tunnel add, followed by a tunnel show:
>
> $ sudo ip tunnel add mode ipip remote 10.2.20.211
> $ ip tunnel
> tunl0: ip/ip remote any local any ttl inherit nopmtudisc
> tunl%d: ip/ip remote 10.2.20.211 local any ttl inherit
> $ sudo ip tunnel add mode sit remote 10.2.20.212
> $ ip tunnel
> sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16
> sit%d: ioctl 89f8 failed: No such device
> sit%d: ipv6/ip remote 10.2.20.212 local any ttl inherit
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Ted Feng <artisdom@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] netem: add cell concept to simulate special MAC behavior
From: David Miller @ 2011-12-13 0:01 UTC (permalink / raw)
To: hagen; +Cc: netdev, eric.dumazet, shemminger, fw
In-Reply-To: <1323562314-14033-1-git-send-email-hagen@jauu.net>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Sun, 11 Dec 2011 01:11:54 +0100
> @@ -568,6 +585,12 @@ static void get_rate(struct Qdisc *sch, const struct nlattr *attr)
> const struct tc_netem_rate *r = nla_data(attr);
>
> q->rate = r->rate;
> + q->packet_overhead = r->packet_overhead;
> + q->cell_size = r->cell_size;
> + if (q->cell_size)
> + q->cell_size_reciprocal = reciprocal_value(q->cell_size);
> + q->cell_overhead = r->cell_overhead;
> }
>
> static int get_loss_clg(struct Qdisc *sch, const struct nlattr *attr)
This patch is corrupted. The hunk header here says there should be 6 lines
of content before the change and 12 lines afterwards, but there are only 11
lines of content afterwards.
Please fix this up and resubmit.
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: use IS_ENABLED(CONFIG_IPV6)
From: Joe Perches @ 2011-12-13 0:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1323593575.4016.38.camel@edumazet-laptop>
On Sun, 2011-12-11 at 09:52 +0100, Eric Dumazet wrote:
> Le samedi 10 décembre 2011 à 16:51 -0800, Joe Perches a écrit :
> > On Sat, 2011-12-10 at 23:29 +0100, Eric Dumazet wrote:
> > > Le samedi 10 décembre 2011 à 14:00 -0800, Joe Perches a écrit :
> > > Are you sure this is equivalent ?
> > I believe so.
> You didnt answer my question or you dont understand your change.
> I wonder why.
I believe "I believe so" is an answer.
Perhaps not a good or in this case perhaps
even an answer with an incorrect result,
but still an answer...
> Point was : IPV6 compiled as a module, and _this_ driver compiled
> staticaly.
> Did you tried this combination ?
No, though I will try it this week.
cheers, Joe
^ permalink raw reply
* Re: [PATCH v9 0/9] Request for inclusion: per-cgroup tcp memory pressure controls
From: David Miller @ 2011-12-13 0:07 UTC (permalink / raw)
To: glommer
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, gthelen,
netdev, linux-mm, kirill, avagin, devel, eric.dumazet, cgroups
In-Reply-To: <1323676029-5890-1-git-send-email-glommer@parallels.com>
From: Glauber Costa <glommer@parallels.com>
Date: Mon, 12 Dec 2011 11:47:00 +0400
> This series fixes all the few comments raised in the last round,
> and seem to have acquired consensus from the memcg side.
>
> Dave, do you think it is acceptable now from the networking PoV?
> In case positive, would you prefer merging this trough your tree,
> or acking this so a cgroup maintainer can do it?
All applied to net-next, thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] sch_gred: should not use GFP_KERNEL while holding a spinlock
From: David Miller @ 2011-12-13 0:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1323682973.2948.12.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 12 Dec 2011 10:42:53 +0100
> gred_change_vq() is called under sch_tree_lock(sch).
>
> This means a spinlock is held, and we are not allowed to sleep in this
> context.
>
> We might pre-allocate memory using GFP_KERNEL before taking spinlock,
> but this is not suitable for stable material.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: pull request: batman-adv 2011-12-12
From: David Miller @ 2011-12-13 0:28 UTC (permalink / raw)
To: lindner_marek; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1323689516-24427-1-git-send-email-lindner_marek@yahoo.de>
From: Marek Lindner <lindner_marek@yahoo.de>
Date: Mon, 12 Dec 2011 19:31:44 +0800
> here comes the next batch I'd like to get the pulled into net-next-2.6/3.3.
> We have a couple of minor fixes for unregister_netdevice(), compat flags,
> return value checks and a readme update. Plus the regression fix from Dan
> that addresses a bug introduced with the previous batch. Security
> researcher Paul Kot checked our kernelland / user space communication and
> found a subtle bug which would make batman-adv write to memory locations
> it should not write to. However, he did not find a way to exploit this
> bug, therefore we classified it as "non-critical". Please let us know if
> that is not ok with you.
All pulled into net-next, thanks.
^ permalink raw reply
* [PATCH] netem: add cell concept to simulate special MAC behavior
From: Hagen Paul Pfeifer @ 2011-12-13 0:30 UTC (permalink / raw)
To: netdev; +Cc: davem, Hagen Paul Pfeifer, Florian Westphal
In-Reply-To: <20111212.190132.2127710068935598402.davem@davemloft.net>
This extension can be used to simulate special link layer
characteristics. Simulate because packet data is not modified, only the
calculation base is changed to delay a packet based on the original
packet size and artificial cell information.
packet_overhead can be used to simulate a link layer header compression
scheme (e.g. set packet_overhead to -20) or with a positive
packet_overhead value an additional MAC header can be simulated. It is
also possible to "replace" the 14 byte Ethernet header with something
else.
cell_size and cell_overhead can be used to simulate link layer schemes,
based on cells, like some TDMA schemes. Another application area are MAC
schemes using a link layer fragmentation with a (small) header each.
Cell size is the maximum amount of data bytes within one cell. Cell
overhead is an additional variable to change the per-cell-overhead
(e.g. 5 byte header per fragment).
Example (5 kbit/s, 20 byte per packet overhead, cell-size 100 byte, per
cell overhead 5 byte):
tc qdisc add dev eth0 root netem rate 5kbit 20 100 5
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/pkt_sched.h | 3 +++
net/sched/sch_netem.c | 33 +++++++++++++++++++++++++++++----
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h
index 8786ea7..8daced3 100644
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
@@ -502,6 +502,9 @@ struct tc_netem_corrupt {
struct tc_netem_rate {
__u32 rate; /* byte/s */
+ __s32 packet_overhead;
+ __u32 cell_size;
+ __s32 cell_overhead;
};
enum {
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 3bfd733..1fa2f90 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -22,6 +22,7 @@
#include <linux/skbuff.h>
#include <linux/vmalloc.h>
#include <linux/rtnetlink.h>
+#include <linux/reciprocal_div.h>
#include <net/netlink.h>
#include <net/pkt_sched.h>
@@ -80,6 +81,10 @@ struct netem_sched_data {
u32 reorder;
u32 corrupt;
u32 rate;
+ s32 packet_overhead;
+ u32 cell_size;
+ u32 cell_size_reciprocal;
+ s32 cell_overhead;
struct crndstate {
u32 last;
@@ -299,11 +304,23 @@ static psched_tdiff_t tabledist(psched_tdiff_t mu, psched_tdiff_t sigma,
return x / NETEM_DIST_SCALE + (sigma / NETEM_DIST_SCALE) * t + mu;
}
-static psched_time_t packet_len_2_sched_time(unsigned int len, u32 rate)
+static psched_time_t packet_len_2_sched_time(unsigned int len, struct netem_sched_data *q)
{
- u64 ticks = (u64)len * NSEC_PER_SEC;
+ u64 ticks;
- do_div(ticks, rate);
+ len += q->packet_overhead;
+
+ if (q->cell_size) {
+ u32 cells = reciprocal_divide(len, q->cell_size_reciprocal);
+
+ if (len > cells * q->cell_size) /* extra cell needed for remainder */
+ cells++;
+ len = cells * (q->cell_size + q->cell_overhead);
+ }
+
+ ticks = (u64)len * NSEC_PER_SEC;
+
+ do_div(ticks, q->rate);
return PSCHED_NS2TICKS(ticks);
}
@@ -384,7 +401,7 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
if (q->rate) {
struct sk_buff_head *list = &q->qdisc->q;
- delay += packet_len_2_sched_time(skb->len, q->rate);
+ delay += packet_len_2_sched_time(skb->len, q);
if (!skb_queue_empty(list)) {
/*
@@ -568,6 +585,11 @@ static void get_rate(struct Qdisc *sch, const struct nlattr *attr)
const struct tc_netem_rate *r = nla_data(attr);
q->rate = r->rate;
+ q->packet_overhead = r->packet_overhead;
+ q->cell_size = r->cell_size;
+ if (q->cell_size)
+ q->cell_size_reciprocal = reciprocal_value(q->cell_size);
+ q->cell_overhead = r->cell_overhead;
}
static int get_loss_clg(struct Qdisc *sch, const struct nlattr *attr)
@@ -909,6 +931,9 @@ static int netem_dump(struct Qdisc *sch, struct sk_buff *skb)
NLA_PUT(skb, TCA_NETEM_CORRUPT, sizeof(corrupt), &corrupt);
rate.rate = q->rate;
+ rate.packet_overhead = q->packet_overhead;
+ rate.cell_size = q->cell_size;
+ rate.cell_overhead = q->cell_overhead;
NLA_PUT(skb, TCA_NETEM_RATE, sizeof(rate), &rate);
if (dump_loss_model(q, skb) != 0)
--
1.7.7.3
^ permalink raw reply related
* Re: 3.0.8 kernel : NULL ptr deref in skb_queue_purge()
From: Grant Grundler @ 2011-12-13 0:30 UTC (permalink / raw)
To: netdev; +Cc: linux-usb
In-Reply-To: <CANEJEGtJ3UmFNyui_SaZ6NF5FFVjZ+_UBg1RC2eif5Lu1YKDsQ@mail.gmail.com>
more info...I've filed an issue tracker in chromium.org:
http://crosbug.com/23891
On Wed, Dec 7, 2011 at 2:40 PM, Grant Grundler <grundler@chromium.org> wrote:
> Hi,
> I'm testing asix (USB 100BT ethernet adapter with AX88772) driver
> initialization (and shut down) paths and reproduced a
> "skb_queue_purge" panic 3 times after a few hundred/thousand
> iterations of rmmod/modprobe. I'm inclined to believe
> skb_queue_purge() is a victim and not a culprit here.
I found a similar report from 3.0.7 that looks similar but different
stack trace:
https://bbs.archlinux.org/viewtopic.php?id=128951
In both cases, we are shutting down a device (close path) and kernel
blows up in skb_queue_purge().
The patch they claim "fixed" the problem is in the iwlagn_commit_rxon
code which I'm not using:
http://marc.info/?l=linux-wireless&m=131840748927629&w=2
So I'm thinking that patch might have fixed a different problem than
originally reported.
I've not yet tested 3.2-rc builds - not clear when I'll be able to try that.
Given the other skb_queue/dequeue functions use
spin_lock_irqsave(&list->lock,flags) to protect list traversal, I'm
going to hazard a guess that some one else is racing with the close
path (some other kernel thread? IRQ?) to access the same skb list.
When calling skb_queue_purge(), nothing else should be touching the
list. Does it sound like I'm on the right track?
cheers,
grant
> I don't know if all 3 "spontaneous reboots" I've seen have the same
> stack trace as the one I have a record for:
>
> ...
> <6>[57776.637311] asix 1-4:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
> <6>[57777.224552] usbcore: deregistering interface driver asix
> <6>[57777.224859] asix 1-4:1.0: eth0: unregister 'asix'
> usb-0000:00:1d.7-4, ASIX AX88772 USB 2.0 Ethernet
> <1>[57777.224918] BUG: unable to handle kernel NULL pointer
> dereference at 00000002
> <1>[57777.224934] IP: [<00000002>] 0x1
> <5>[57777.224952] *pdpt = 0000000061d70001 *pde = 0000000000000000
> <0>[57777.224967] Oops: 0010 [#1] SMP
> <5>[57777.224980] Modules linked in: asix(-) i2c_dev tsl2583(C)
> industrialio(C) snd_hda_codec_realtek i2c_i801 nm10_gpio snd_hda_intel
> snd_hda_codec snd_hwdep snd_pcm snd_timer snd_page_alloc gobi rtc_cmos
> fuse nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter xt_mark ath9k
> ip6_tables mac80211 ath9k_common ath9k_hw ath cfg80211 uvcvideo
> videodev usbnet qcserial usb_wwan [last unloaded: asix]
> <5>[57777.225109]
> <5>[57777.225121] Pid: 30292, comm: rmmod Tainted: G C 3.0.8
> #2 SAMSUNG ELECTRONICS CO., LTD. Alex/G100
> <5>[57777.225141] EIP: 0060:[<00000002>] EFLAGS: 00010286 CPU: 1
> <5>[57777.225153] EIP is at 0x2
> <5>[57777.225162] EAX: 00000001 EBX: 00000100 ECX: 00000000 EDX: 00000100
> <5>[57777.225172] ESI: f6bad5a8 EDI: f6bad59c EBP: e44e7e20 ESP: e44e7e14
> <5>[57777.225183] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> <0>[57777.225194] Process rmmod (pid: 30292, ti=e44e6000 task=f0c2e040
> task.ti=e44e6000)
> <0>[57777.225203] Stack:
> <5>[57777.225209] f58fdb70 f6bad000 f8c63a34 e44e7e2c 812d2a98
> f6bad480 e44e7e40 f87e820e
> <5>[57777.225242] e44e7e88 f6bad000 e44e7e88 e44e7e50 812d79cd
> e44e7e88 f6bad000 e44e7e6c
> <5>[57777.225273] 812d7a82 e44e7e58 e44e7e58 e44e7e88 f6bad000
> e44e7e88 e44e7e80 812d7b60
> <0>[57777.225305] Call Trace:
> <5>[57777.225325] [<812d2a98>] skb_queue_purge+0x19/0x20
> <5>[57777.225345] [<f87e820e>] usbnet_stop+0xb5/0xf9 [usbnet]
> <5>[57777.225361] [<812d79cd>] __dev_close_many+0x85/0xa2
> <5>[57777.225375] [<812d7a82>] dev_close_many+0x61/0xb1
> <5>[57777.225390] [<812d7b60>] rollback_registered_many+0x8e/0x1ec
> <5>[57777.225405] [<812d9224>] unregister_netdevice_queue+0x6e/0x9f
> <5>[57777.225419] [<812d9270>] unregister_netdev+0x1b/0x22
> <5>[57777.225437] [<f87e76be>] usbnet_disconnect+0x71/0xb9 [usbnet]
> <5>[57777.225454] [<81273a03>] usb_unbind_interface+0x44/0xf8
> <5>[57777.225471] [<81237d25>] __device_release_driver+0x80/0xb8
> <5>[57777.225484] [<812381e2>] driver_detach+0x6c/0x8a
> <5>[57777.225499] [<81237c41>] bus_remove_driver+0x6e/0x8d
> <5>[57777.225513] [<81238721>] driver_unregister+0x51/0x58
> <5>[57777.225526] [<812730c2>] usb_deregister+0x92/0x9f
> <5>[57777.225541] [<f8c62885>] cleanup_module+0xd/0x788 [asix]
> <5>[57777.225556] [<810573ed>] sys_delete_module+0x19d/0x1fa
> <5>[57777.225573] [<8109a059>] ? do_munmap+0x1f2/0x20a
> <5>[57777.225590] [<8137e677>] sysenter_do_call+0x12/0x26
> <0>[57777.225599] Code: Bad EIP value.
> <0>[57777.225614] EIP: [<00000002>] 0x2 SS:ESP 0068:e44e7e14
> <0>[57777.225631] CR2: 0000000000000002
> <1>[57777.225035] BUG: unable to handle kernel NULL pointer
> dereference at (null)
> <1>[57777.225035] IP: [< (null)>] (null)
> <5>[57777.225035] *pdpt = 000000006ff81001 *pde = 0000000000000000
> <4>[57777.225684] ---[ end trace
>
>
> On my workstation, I run the following to push/run multiple iterations
> on the target system:
> T=root@172.xx.xx.xx
> scp ~/reload_asix $T:/tmp
> for i in `seq 10000`; do printf " %3d: " $i; ssh $T ".
> /tmp/reload_asix" && ssh $T "tail -30 /var/log/messages | fgrep
> leased" ; done | tee reload_asix-loop.out
>
>
> "/tmp/reload_asix" script has the following contents:
> #!/bin/bash -x
>
> # redirect all output to a file. SSH might drop.
> exec > /tmp/`date --rfc-3339=date`-reload-$$.out 2>&1
>
> date
> rmmod asix
>
> # side effect of auth/deauth is a USB reset on reconnect. :)
> echo 0 > /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/authorized
> sleep 1
> echo 1 > /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/authorized
> sleep 1
>
> time modprobe asix
>
> for i in `seq 5` ; do
> l="$(cat /sys/class/net/eth0/speed) $(cat /sys/class/net/eth0/duplex)"
> printf "%3d: %s %s\n" $i $(cat /sys/class/net/eth0/address) "$l"
> if [ "$l" = "100 full" ] ; then
> break
> fi
> sleep 1
> done
>
> # at this point we have negotiated link..but not DHCP yet. :/
> return 0
>
>
> Reproduced this panic on two different x86 laptops (Asus AGB and
> Samsung Series 5).
>
> At first glance, this doesn't look like an asix driver bug (though it might be).
> I'm hoping the bug will be obvious to someone who understands usbnet
> and skb_queue calls.
> Open to any debugging advice folks have.
>
> thanks in advance,
> grant
^ permalink raw reply
* Re: [PATCH net-next V1 00/21] net/mlx4: SRIOV support
From: David Miller @ 2011-12-13 0:43 UTC (permalink / raw)
To: yevgenyp-VPRAkNaXOzVS1MOuV/RT9w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
roland-BHEL68pLQRGGvPXPguhicg, liranl-VPRAkNaXOzVS1MOuV/RT9w,
jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
In-Reply-To: <4EE612D4.6040502-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>
This patch series causes new warnings:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function ‘mr_states_str’:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:144:2: warning: case value ‘3’ not in enumerated type ‘enum res_mtt_states’ [-Wswitch]
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:145:2: warning: case value ‘4’ not in enumerated type ‘enum res_mtt_states’ [-Wswitch]
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function ‘eq_states_str’:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:167:2: warning: case value ‘3’ not in enumerated type ‘enum res_mtt_states’ [-Wswitch]
^ permalink raw reply
* Re: [PATCH] netem: add cell concept to simulate special MAC behavior
From: David Miller @ 2011-12-13 0:45 UTC (permalink / raw)
To: hagen; +Cc: netdev, fw
In-Reply-To: <1323736200-1252-1-git-send-email-hagen@jauu.net>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Tue, 13 Dec 2011 01:30:00 +0100
> This extension can be used to simulate special link layer
> characteristics. Simulate because packet data is not modified, only the
> calculation base is changed to delay a packet based on the original
> packet size and artificial cell information.
>
> packet_overhead can be used to simulate a link layer header compression
> scheme (e.g. set packet_overhead to -20) or with a positive
> packet_overhead value an additional MAC header can be simulated. It is
> also possible to "replace" the 14 byte Ethernet header with something
> else.
>
> cell_size and cell_overhead can be used to simulate link layer schemes,
> based on cells, like some TDMA schemes. Another application area are MAC
> schemes using a link layer fragmentation with a (small) header each.
> Cell size is the maximum amount of data bytes within one cell. Cell
> overhead is an additional variable to change the per-cell-overhead
> (e.g. 5 byte header per fragment).
>
> Example (5 kbit/s, 20 byte per packet overhead, cell-size 100 byte, per
> cell overhead 5 byte):
>
> tc qdisc add dev eth0 root netem rate 5kbit 20 100 5
>
> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: Fix for adding multicast route for loopback device automatically.
From: Li Wei @ 2011-12-13 0:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, yoshfuji
In-Reply-To: <20111212.184929.1998244574424635802.davem@davemloft.net>
> From: Li Wei <lw@cn.fujitsu.com>
> Date: Thu, 08 Dec 2011 08:58:21 +0800
>
>> The problem is that the resulting routing table depends on the sequence
>> of interface's initialization and in some situation, that would block all
>> muticast packets. Suppose there are two interfaces on my computer
>> (lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
>> table(for multicast) would be
>>
>> # ip -6 route show | grep ff00::
>> unreachable ff00::/8 dev lo metric 256 error -101
>> ff00::/8 dev eth0 metric 256
>>
>> When sending multicasting packets, routing subsystem will return the first
>> route entry which with a error set to -101(ENETUNREACH).
>>
>> I know the kernel will set the default ipv6 address for 'lo' when it is up
>> and won't set the default multicast route for it, but there is no reason to
>> stop 'init' program from setting address for 'lo', and that is exactly what
>> systemd did.
>
> Ok, I added this more detailed explanation to the commit message and
> applied your patch.
>
> Probably it is a good idea to explain things completely, with all details
> and examples, in the commit message from the beginning :-)
>
>
Thanks David, remember your advice :)
^ 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