* Re: pull-request: iwlwifi-fixes 2013-06-05
From: Johannes Berg @ 2013-06-12 12:17 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1370415743.8920.6.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]
Amending this ...
I picked up Nikolay's patch for the chain noise calibration bug that
seems to have been there forever, a fix from Emmanuel for setting TX
flags on BAR frames and a fix of my own to avoid printing
request_module() errors if the kernel isn't even modular. We also have
our own version of Stanislaw's fix for rate control.
johannes
The following changes since commit a87783699b23395c46bbeeb5d28f6db24897bf26:
iwlwifi: dvm: fix zero LQ CMD sending avoidance (2013-05-27 11:33:57 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git for-john
for you to fetch changes up to 622ebe994f6866b8d46ee5d3bcc329ed65d3722d:
iwlwifi: fix rate control regression (2013-06-12 14:13:39 +0200)
----------------------------------------------------------------
Emmanuel Grumbach (1):
iwlwifi: mvm: correctly set the flags for BAR
Johannes Berg (1):
iwlwifi: don't print module loading error if not modular
Moshe Benji (1):
iwlwifi: fix rate control regression
Nikolay Martynov (1):
iwlwifi: dvm: fix chain noise calibration
drivers/net/wireless/iwlwifi/dvm/rs.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/rxon.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-drv.c | 2 ++
drivers/net/wireless/iwlwifi/mvm/rs.c | 1 +
drivers/net/wireless/iwlwifi/mvm/tx.c | 3 ++-
5 files changed, 7 insertions(+), 3 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [QUERY] Intel Centrino Wireless-N 100 modules vs built-in
From: Nick Warne @ 2013-06-12 12:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1371038139.8601.15.camel@jlt4.sipsolutions.net>
On Wed, Jun 12, 2013 at 01:55:39PM +0200, Johannes Berg wrote:
>
> > Newer versions of udev don't
> > respond negatively if they don't have the firmware while running from
> > initrd/initramfs, and will leave the driver's request pending to be
> > answered once the real filesystem is mounted.
>
> And by "newer", I really mean "anything not ancient", the version with
> the logic was 187, released almost a year ago :-)
I will have to wait for debian/ubuntu/mint to catch up then :)
Nick
--
Free Software Foundation Associate Member 5508
http://linicks.net/
^ permalink raw reply
* Re: [QUERY] Intel Centrino Wireless-N 100 modules vs built-in
From: Nick Warne @ 2013-06-12 12:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1371037816.8601.13.camel@jlt4.sipsolutions.net>
Hi Johannes,
On Wed, Jun 12, 2013 at 01:50:16PM +0200, Johannes Berg wrote:
> Nick,
>
> > Device Drivers->Network Device Support->Wireless LAN
> >
> > <M> Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate-N (iwlwifi)
> > -M- Intel Wireless WiFi DVM Firmware support
> >
> > all is hucky dory. But if I build-in these drivers into kernel (<*>), on boot dmesg reports:
> >
> > [2.347954] iwlwifi 0000:05:00.0: request for firmware file 'iwlwifi-100-5.ucode' failed.
> > [2.351885] iwlwifi 0000:05:00.0: no suitable firmware found!
> >
> > Am I missing something here - I don't quite understand why this happens?
>
> The driver has to request firmware when the device is bound to it, so it
> can then register correctly with mac80211. Newer versions of udev don't
> respond negatively if they don't have the firmware while running from
> initrd/initramfs, and will leave the driver's request pending to be
> answered once the real filesystem is mounted. You seem to not be running
> a version of udev with this logic.
>
> To work around it, you could include the firmware in the
> initrd/initramfs.
>
> Alternatively, you could unbind/re-bind the driver after the system has
> full booted, like this:
>
> # echo 0000:05:00.0 > /sys/module/iwlwifi/drivers/pci\:iwlwifi/unbind
> # echo 0000:05:00.0 > /sys/module/iwlwifi/drivers/pci\:iwlwifi/bind
>
> This will force it to attempt to load the firmware from disk again.
Thank you very much for a comprehensive reply.
I am using Linux-Mint on this machines, so at the moment am using the 'debian fakeroot make-kpkg...' stuff, so the build is dumbed down for the user ('tis easy on my Slackware box!).
So, reading what you said, I think I will leave 'as is'.
Again, thank you for the reply, and 'sorry for the noise!'
Nick
--
Free Software Foundation Associate Member 5508
http://linicks.net/
^ permalink raw reply
* Re: [QUERY] Intel Centrino Wireless-N 100 modules vs built-in
From: Johannes Berg @ 2013-06-12 11:55 UTC (permalink / raw)
To: Nick Warne; +Cc: linux-wireless
In-Reply-To: <1371037816.8601.13.camel@jlt4.sipsolutions.net>
> Newer versions of udev don't
> respond negatively if they don't have the firmware while running from
> initrd/initramfs, and will leave the driver's request pending to be
> answered once the real filesystem is mounted.
And by "newer", I really mean "anything not ancient", the version with
the logic was 187, released almost a year ago :-)
johannes
^ permalink raw reply
* Re: [QUERY] Intel Centrino Wireless-N 100 modules vs built-in
From: Johannes Berg @ 2013-06-12 11:50 UTC (permalink / raw)
To: Nick Warne; +Cc: linux-wireless
In-Reply-To: <20130612112326.GA10313@sauron>
Nick,
> Device Drivers->Network Device Support->Wireless LAN
>
> <M> Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate-N (iwlwifi)
> -M- Intel Wireless WiFi DVM Firmware support
>
> all is hucky dory. But if I build-in these drivers into kernel (<*>), on boot dmesg reports:
>
> [2.347954] iwlwifi 0000:05:00.0: request for firmware file 'iwlwifi-100-5.ucode' failed.
> [2.351885] iwlwifi 0000:05:00.0: no suitable firmware found!
>
> Am I missing something here - I don't quite understand why this happens?
The driver has to request firmware when the device is bound to it, so it
can then register correctly with mac80211. Newer versions of udev don't
respond negatively if they don't have the firmware while running from
initrd/initramfs, and will leave the driver's request pending to be
answered once the real filesystem is mounted. You seem to not be running
a version of udev with this logic.
To work around it, you could include the firmware in the
initrd/initramfs.
Alternatively, you could unbind/re-bind the driver after the system has
full booted, like this:
# echo 0000:05:00.0 > /sys/module/iwlwifi/drivers/pci\:iwlwifi/unbind
# echo 0000:05:00.0 > /sys/module/iwlwifi/drivers/pci\:iwlwifi/bind
This will force it to attempt to load the firmware from disk again.
johannes
^ permalink raw reply
* [QUERY] Intel Centrino Wireless-N 100 modules vs built-in
From: Nick Warne @ 2013-06-12 11:23 UTC (permalink / raw)
To: linux-wireless
Dear Devs,
I have a strange query. Building a custom kernel on my Samsung N145 notebook I came a cropper.
05:00.0 Network controller: Intel Corporation Centrino Wireless-N 100
If I select:
Device Drivers->Network Device Support->Wireless LAN
<M> Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate-N (iwlwifi)
-M- Intel Wireless WiFi DVM Firmware support
all is hucky dory. But if I build-in these drivers into kernel (<*>), on boot dmesg reports:
[2.347954] iwlwifi 0000:05:00.0: request for firmware file 'iwlwifi-100-5.ucode' failed.
[2.351885] iwlwifi 0000:05:00.0: no suitable firmware found!
Am I missing something here - I don't quite understand why this happens?
Any help appricated please.
Please CC any replies please, I am not subscribed.
Nick
--
Free Software Foundation Associate Member 5508
http://linicks.net/
^ permalink raw reply
* Re: [PATCH] mac80211: Use RCU protection in ieee80211_get_tx_rates()
From: Felix Fietkau @ 2013-06-12 9:47 UTC (permalink / raw)
To: Calvin Owens
Cc: Johannes Berg, Luis R. Rodriguez, John W. Linville,
linux-wireless, linux-kernel, ath9k-devel, netdev
In-Reply-To: <20130612080042.GA1695@gmail.com>
On 2013-06-12 10:00 AM, Calvin Owens wrote:
> Copying the rate table should be done in an RCU read-side critical
> section.
I think this approach is wrong. The sta entry is also under RCU
protection (no locking for read access in that part of the code.
In a normal driver tx path, no extra rcu_read_lock/rcu_read_unlock is
needed. Only if the driver does some scheduling outside of the tx
function (which ath9k does), this RCU warning appears.
How about this change instead:
---
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1570,6 +1570,8 @@ void ath_txq_schedule(struct ath_softc *
txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH)
return;
+ rcu_read_lock();
+
ac = list_first_entry(&txq->axq_acq, struct ath_atx_ac, list);
last_ac = list_entry(txq->axq_acq.prev, struct ath_atx_ac, list);
@@ -1608,8 +1610,10 @@ void ath_txq_schedule(struct ath_softc *
if (ac == last_ac ||
txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH)
- return;
+ break;
}
+
+ rcu_read_unlock();
}
/***********/
^ permalink raw reply
* Re: [PATCH 1/3] skbuff: Update truesize in pskb_expand_head
From: Eric Dumazet @ 2013-06-12 9:16 UTC (permalink / raw)
To: Dave Wiltshire
Cc: davem, netdev, linux-kernel, nsujir, mchan, rmody, jcliburn,
chris.snook, jeffrey.t.kirsher, bruce.w.allan, alexander.h.duyck,
cooldavid, linux-driver, linux-wimax, wimax, linux-wireless, viro,
eparis, edumazet, dev, jhs
In-Reply-To: <1371027934-1955-2-git-send-email-david.wiltshire@gmx.com>
On Wed, 2013-06-12 at 19:05 +1000, Dave Wiltshire wrote:
> Some call sites to pskb_expand_head subsequently update the skb truesize
> and others don't (even with non-zero arguments). This is likely a memory
> audit leak. Fixed this up by moving the memory accounting to the
> skbuff.c file and removing it from the calling sites.
>
> Signed-off-by: Dave Wiltshire <david.wiltshire@gmx.com>
> ---
> drivers/net/wireless/mwl8k.c | 1 -
> kernel/audit.c | 2 --
> net/core/skbuff.c | 1 +
> net/netlink/af_netlink.c | 3 +--
> net/wireless/util.c | 2 --
> 5 files changed, 2 insertions(+), 7 deletions(-)
Ouch.
Sorry, you cannot do that.
skb->truesize is really complex, because there is a strong relation
between skb->truesize and memory accounting on sockets.
So pskb_expand_head() should not touch skb->truesize.
Only callers can do that when needed, and if possible.
An example of very careful truesize manipulation can be found in
tcp_tso_segment()
^ permalink raw reply
* [PATCH 1/3] skbuff: Update truesize in pskb_expand_head
From: Dave Wiltshire @ 2013-06-12 9:05 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, nsujir, mchan, rmody, jcliburn, chris.snook,
jeffrey.t.kirsher, bruce.w.allan, alexander.h.duyck, cooldavid,
linux-driver, linux-wimax, wimax, linux-wireless, viro, eparis,
edumazet, dev, jhs, Dave Wiltshire
In-Reply-To: <1371027934-1955-1-git-send-email-david.wiltshire@gmx.com>
Some call sites to pskb_expand_head subsequently update the skb truesize
and others don't (even with non-zero arguments). This is likely a memory
audit leak. Fixed this up by moving the memory accounting to the
skbuff.c file and removing it from the calling sites.
Signed-off-by: Dave Wiltshire <david.wiltshire@gmx.com>
---
drivers/net/wireless/mwl8k.c | 1 -
kernel/audit.c | 2 --
net/core/skbuff.c | 1 +
net/netlink/af_netlink.c | 3 +--
net/wireless/util.c | 2 --
5 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 6820fce..802c8d7 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -845,7 +845,6 @@ mwl8k_add_dma_header(struct mwl8k_priv *priv, struct sk_buff *skb,
"Failed to reallocate TX buffer\n");
return;
}
- skb->truesize += REDUCED_TX_HEADROOM;
}
reqd_hdrlen = sizeof(*tr) + head_pad;
diff --git a/kernel/audit.c b/kernel/audit.c
index 21c7fa6..e05b57b 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1157,7 +1157,6 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
static inline int audit_expand(struct audit_buffer *ab, int extra)
{
struct sk_buff *skb = ab->skb;
- int oldtail = skb_tailroom(skb);
int ret = pskb_expand_head(skb, 0, extra, ab->gfp_mask);
int newtail = skb_tailroom(skb);
@@ -1166,7 +1165,6 @@ static inline int audit_expand(struct audit_buffer *ab, int extra)
return 0;
}
- skb->truesize += newtail - oldtail;
return newtail;
}
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index edf3757..125bb7e 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1061,6 +1061,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
if (!data)
goto nodata;
size = SKB_WITH_OVERHEAD(ksize(data));
+ skb->truesize += size - skb_end_offset(skb);
/* Copy only real data... and, alas, header. This should be
* optimized for the cases when header is void.
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 9b6b115..77fd986 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1565,8 +1565,7 @@ static struct sk_buff *netlink_trim(struct sk_buff *skb, gfp_t allocation)
skb = nskb;
}
- if (!pskb_expand_head(skb, 0, -delta, allocation))
- skb->truesize -= delta;
+ pskb_expand_head(skb, 0, -delta, allocation);
return skb;
}
diff --git a/net/wireless/util.c b/net/wireless/util.c
index f5ad4d9..5710aa2 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -533,8 +533,6 @@ int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
if (pskb_expand_head(skb, head_need, 0, GFP_ATOMIC))
return -ENOMEM;
-
- skb->truesize += head_need;
}
if (encaps_data) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/3] skbuff: pskb_expand_head changes
From: Dave Wiltshire @ 2013-06-12 9:05 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, nsujir, mchan, rmody, jcliburn, chris.snook,
jeffrey.t.kirsher, bruce.w.allan, alexander.h.duyck, cooldavid,
linux-driver, linux-wimax, wimax, linux-wireless, viro, eparis,
edumazet, dev, jhs, Dave Wiltshire
This patchset applies against David Miller's net-next tree.
This is my first patch, so please let me know if I've done something
wrong or could do something better (e.g. splitting the patch in a
different way).
I think there is a problem with memory accounting in pskb_expand_head.
Some call sites update truesize while others don't. This means that the
skbuff can change in size without truesize being updated. This seems
incorrect to me. So I changed it. Perhaps I don't understand something,
but I thought it best to generate the change and then ask. So is this
correct?
The other patches are from looking at all the call sites to
pskb_expand_head and since I was doing that I cleaned some of them up.
Dave Wiltshire (3):
skbuff: Update truesize in pskb_expand_head
skbuff: skb_cow_head not used in some drivers.
skbuff: Added new helper function skb_cow_clone_head.
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 8 ++------
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 8 ++------
drivers/net/ethernet/atheros/atlx/atl1.c | 8 ++------
drivers/net/ethernet/broadcom/tg3.c | 3 +--
drivers/net/ethernet/brocade/bna/bnad.c | 11 +++--------
drivers/net/ethernet/intel/e1000/e1000_main.c | 8 ++------
drivers/net/ethernet/intel/e1000e/netdev.c | 8 ++------
drivers/net/ethernet/intel/igb/igb_main.c | 7 ++-----
drivers/net/ethernet/intel/igbvf/netdev.c | 11 +++--------
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 8 ++------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 10 +++-------
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 7 ++-----
drivers/net/ethernet/jme.c | 3 +--
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 8 ++------
drivers/net/wimax/i2400m/netdev.c | 3 +--
drivers/net/wireless/mwl8k.c | 1 -
include/linux/skbuff.h | 14 +++++++++++++
kernel/audit.c | 2 --
net/core/dev.c | 8 ++------
net/core/skbuff.c | 1 +
net/netlink/af_netlink.c | 3 +--
net/openvswitch/actions.c | 22 +++++++--------------
net/sched/act_csum.c | 8 ++------
net/sched/act_nat.c | 18 +++++------------
net/wireless/util.c | 2 --
25 files changed, 62 insertions(+), 128 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH] mac80211: Use RCU protection in ieee80211_get_tx_rates()
From: Calvin Owens @ 2013-06-12 8:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, John W. Linville, Felix Fietkau,
linux-wireless, linux-kernel, ath9k-devel, netdev, jcalvinowens
In-Reply-To: <20130612075634.GA1649@gmail.com>
Copying the rate table should be done in an RCU read-side critical
section.
Signed-off-by: Calvin Owens <jcalvinowens@gmail.com>
---
net/mac80211/rate.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index d3f414f..090d9b0 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -538,6 +538,8 @@ static void rate_control_fill_sta_table(struct ieee80211_sta *sta,
struct ieee80211_sta_rates *ratetbl = NULL;
int i;
+ rcu_read_lock();
+
if (sta && !info->control.skip_table)
ratetbl = rcu_dereference(sta->rates);
@@ -566,6 +568,8 @@ static void rate_control_fill_sta_table(struct ieee80211_sta *sta,
if (rates[i].idx < 0 || !rates[i].count)
break;
}
+
+ rcu_read_unlock();
}
static void rate_control_apply_mask(struct ieee80211_sub_if_data *sdata,
--
1.8.2.1
^ permalink raw reply related
* Re: [PATCH] mac80211: ath9k: Use RCU protection calling ieee80211_get_tx_rates
From: Calvin Owens @ 2013-06-12 7:56 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, John W. Linville, Felix Fietkau,
linux-wireless, linux-kernel, ath9k-devel, netdev
In-Reply-To: <1370980523.8356.70.camel@jlt4.sipsolutions.net>
On Tuesday 06/11 at 21:55 +0200, Johannes Berg wrote:
> Now the subject should no longer say "mac80211:" :)
>
> However... given that ieee80211_get_tx_rates() actually *copies* the
> rates into the parameter, I guess it should do the rcu_read_lock()
> internally. I guess I wasn't paying attention previously. Felix?
I thought about that, but it seemed too simple, so I assumed I was
missing something. ;)
I'll send a patch per above. That makes the header file update
unnecessary too.
> johannes
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: David Miller @ 2013-06-12 7:42 UTC (permalink / raw)
To: sujith; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20920.8752.339655.254147@gargle.gargle.HOWL>
From: Sujith Manoharan <sujith@msujith.org>
Date: Wed, 12 Jun 2013 12:54:32 +0530
> David Miller wrote:
>> John, I also don't like the ATK9K Kconfig option name change added in
>> this pull request, this is exactly the kind of thing that drives
>> Linus insane.
>>
>> Change the default, fine, but changing the name is unnecssary churn
>> and adds a new config prompt that people are going to respond to
>> incorrectly when they type "make oldconfig"
>
> This was Linus' suggestion: https://patchwork.kernel.org/patch/2676971/
>
> The RH bugzilla appears to be down at the moment, but more background
> for the bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=927191
Fair enough, I rescind my objection.
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: Sujith Manoharan @ 2013-06-12 7:24 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20130612.002103.916991474696226731.davem@davemloft.net>
David Miller wrote:
> John, I also don't like the ATK9K Kconfig option name change added in
> this pull request, this is exactly the kind of thing that drives
> Linus insane.
>
> Change the default, fine, but changing the name is unnecssary churn
> and adds a new config prompt that people are going to respond to
> incorrectly when they type "make oldconfig"
This was Linus' suggestion: https://patchwork.kernel.org/patch/2676971/
The RH bugzilla appears to be down at the moment, but more background
for the bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=927191
Sujith
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: David Miller @ 2013-06-12 7:21 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130611.222706.1492583255605214982.davem@davemloft.net>
John, I also don't like the ATK9K Kconfig option name change added in
this pull request, this is exactly the kind of thing that drives
Linus insane.
Change the default, fine, but changing the name is unnecssary churn
and adds a new config prompt that people are going to respond to
incorrectly when they type "make oldconfig"
^ permalink raw reply
* Re: [PATCH] mwifiex: Add module parameter for regdomain
From: Kalle Valo @ 2013-06-12 7:15 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-wireless, John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Paul Stewart
In-Reply-To: <1370904007-10959-1-git-send-email-bzhao@marvell.com>
Bing Zhao <bzhao@marvell.com> writes:
> From: Avinash Patil <patila@marvell.com>
>
> Allow a regulatory domain country code to be specified at boot
> using a module argument. This overrides the firmware regulatory
> mode.
>
> This patch also enables uAP to operate in 11a mode with hostapd.
>
> Signed-off-by: Avinash Patil <patila@marvell.com>
> Signed-off-by: Paul Stewart <pstew@chromium.org>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
This looks ugly. Why can't you use the proper nl80211 interface and
instead want to add a driver specific hack?
--
Kalle Valo
^ permalink raw reply
* Re: pull-request: mac80211 2013-06-12
From: Johannes Berg @ 2013-06-12 7:14 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1371019363.8601.6.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]
Let's try that again :-)
Following davem's complaint about my patch, here's a new pull request
w/o the patch he was complaining about, but instead with the const fix
rolled into the fix.
I have a fix for radar detection, one for rate control and a workaround
for broken HT APs which is a regression fix because we didn't rely on
them to be correct before.
johannes
The following changes since commit ac20976dcaeea3e77e40e9aac8f3799d2a22ea2b:
mac80211: Allow single vif mac address change with addr_mask (2013-05-27 11:26:48 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
for you to fetch changes up to 795d855d56c6d172f50a974f603ba923ac93ee76:
mac80211: Fix rate control mask matching call (2013-06-12 09:12:43 +0200)
----------------------------------------------------------------
Johannes Berg (1):
mac80211: work around broken APs not including HT info
Simon Wunderlich (2):
mac80211: abort CAC in stop_ap()
mac80211: Fix rate control mask matching call
net/mac80211/cfg.c | 6 ++++
net/mac80211/ieee80211_i.h | 5 +--
net/mac80211/mlme.c | 87 ++++++++++++++++++++++++++++++++++++++++++----
net/mac80211/rate.c | 2 +-
net/mac80211/util.c | 4 +--
5 files changed, 92 insertions(+), 12 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: Johannes Berg @ 2013-06-12 7:09 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20130612.000711.759531077550828193.davem@davemloft.net>
On Wed, 2013-06-12 at 00:07 -0700, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Wed, 12 Jun 2013 08:26:49 +0200
>
> > On Tue, 2013-06-11 at 22:27 -0700, David Miller wrote:
> >> From: "John W. Linville" <linville@tuxdriver.com>
> >> Date: Thu, 6 Jun 2013 15:09:30 -0400
> >>
> >> > Johannes Berg (2):
> >> > mac80211: constify ieee802_11_parse_elems() argument
> >>
> >> Such cleanups are absolutely, positively, not appropriate at this
> >> time.
> >
> > My other fix depends on this to not have a const warning. I can add a
> > cast to pretend the input isn't const at this point, but that seemed
> > like a bad idea as well.
>
> I would combine the two changes into one commit, because then this
> necessity is clear and you can even explain this in the commit message
> so that there is no argument about the justification.
Sure, I can do that too.
johannes
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: David Miller @ 2013-06-12 7:07 UTC (permalink / raw)
To: johannes; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1371018409.8601.2.camel@jlt4.sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 12 Jun 2013 08:26:49 +0200
> On Tue, 2013-06-11 at 22:27 -0700, David Miller wrote:
>> From: "John W. Linville" <linville@tuxdriver.com>
>> Date: Thu, 6 Jun 2013 15:09:30 -0400
>>
>> > Johannes Berg (2):
>> > mac80211: constify ieee802_11_parse_elems() argument
>>
>> Such cleanups are absolutely, positively, not appropriate at this
>> time.
>
> My other fix depends on this to not have a const warning. I can add a
> cast to pretend the input isn't const at this point, but that seemed
> like a bad idea as well.
I would combine the two changes into one commit, because then this
necessity is clear and you can even explain this in the commit message
so that there is no argument about the justification.
Thanks.
^ permalink raw reply
* pull-request: mac80211 2013-06-12
From: Johannes Berg @ 2013-06-12 6:42 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
John,
Following davem's complaint about my patch, here's a new pull request
w/o the patch he was complaining about, but instead with an ugly void*
cast to suppress the compiler warning.
I have a fix for radar detection, one for rate control and a workaround
for broken HT APs which is a regression fix because we didn't rely on
them to be correct before.
johannes
The following changes since commit ac20976dcaeea3e77e40e9aac8f3799d2a22ea2b:
mac80211: Allow single vif mac address change with addr_mask (2013-05-27 11:26:48 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
for you to fetch changes up to be0d678f67ce75ad7099d067e0de6c72f61db27f:
mac80211: Fix rate control mask matching call (2013-06-12 08:37:36 +0200)
----------------------------------------------------------------
Johannes Berg (1):
mac80211: work around broken APs not including HT info
Simon Wunderlich (2):
mac80211: abort CAC in stop_ap()
mac80211: Fix rate control mask matching call
net/mac80211/cfg.c | 6 ++++
net/mac80211/mlme.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++-----
net/mac80211/rate.c | 2 +-
3 files changed, 87 insertions(+), 8 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: ath9k: Use RCU protection calling ieee80211_get_tx_rates
From: Kalle Valo @ 2013-06-12 6:37 UTC (permalink / raw)
To: Johannes Berg
Cc: Calvin Owens, Luis R. Rodriguez, John W. Linville, Felix Fietkau,
linux-wireless, linux-kernel, ath9k-devel, netdev
In-Reply-To: <1370980523.8356.70.camel@jlt4.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> Now the subject should no longer say "mac80211:" :)
It did have a change to mac80211.h as well, but IMHO that should be in a
separate patch.
--
Kalle Valo
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: Johannes Berg @ 2013-06-12 6:26 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20130611.222706.1492583255605214982.davem@davemloft.net>
On Tue, 2013-06-11 at 22:27 -0700, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Thu, 6 Jun 2013 15:09:30 -0400
>
> > Johannes Berg (2):
> > mac80211: constify ieee802_11_parse_elems() argument
>
> Such cleanups are absolutely, positively, not appropriate at this
> time.
My other fix depends on this to not have a const warning. I can add a
cast to pretend the input isn't const at this point, but that seemed
like a bad idea as well.
johannes
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: David Miller @ 2013-06-12 5:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130606190929.GB18827@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 6 Jun 2013 15:09:30 -0400
> Johannes Berg (2):
> mac80211: constify ieee802_11_parse_elems() argument
Such cleanups are absolutely, positively, not appropriate at this
time.
Sorry.
I still can't pull this.
^ permalink raw reply
* Re: Intel Centrino Wireless-N 2200 Tech Support
From: Edward Seyler @ 2013-06-12 4:04 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless
In-Reply-To: <CANUX_P0ddkfEY+hxir8=PGH1ocS5FQRFwvrm2otj3eTUkwJ+Gw@mail.gmail.com>
>
> This is really weird...
> Can you compile with CONFIG_IWLWIFI_DEBUG?
> I will then need a few debug prints.
> I recently changed this flow to speed up the fw loading process on
> platform that can afford a bit amount of DMA, but I just tested it
> (again) and it works even if there is not big DMA chunk available.
I compiled with CONFIG_IWLWIFI_DEBUG. I also absent mindedly enabled CONFIG_IWLWIFI_DEBUG_EXPERIMENTAL_UCODE--please let me know if you do not want this. I can provide other debugging output, but I am sending this now in case I cannot respond promptly.
# echo 0xFFFFFFFF > /sys/module/iwlwifi/parameters/debug
# dmesg | grep iwl
[ 10.116748] iwlwifi 0000:03:00.0: irq 43 for MSI/MSI-X
[ 10.234866] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1
[ 10.362940] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
[ 10.362952] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[ 10.362957] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
[ 10.362963] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[ 10.362967] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
[ 10.362974] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Wireless-N 2200 BGN, REV=0x104
[ 10.363003] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
[ 10.377474] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 1180.920142] iwlwifi 0000:03:00.0: U iwlagn_mac_start enter
[ 1180.920152] iwlwifi 0000:03:00.0: I iwl_prep_station Add STA to driver ID 15: ff:ff:ff:ff:ff:ff
[ 1180.920158] iwlwifi 0000:03:00.0: I iwl_prep_station Add STA to driver ID 14: ff:ff:ff:ff:ff:ff
[ 1180.920163] iwlwifi 0000:03:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
[ 1180.920171] iwlwifi 0000:03:00.0: U iwl_pcie_set_hw_ready hardware ready
[ 1180.920173] iwlwifi 0000:03:00.0: U iwl_enable_rfkill_int Enabling rfkill interrupt
[ 1180.920180] iwlwifi 0000:03:00.0: U iwl_pcie_apm_init Init card's basic functions
[ 1180.920196] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
[ 1180.928171] iwlwifi 0000:03:00.0: Radio type=0x2-0x0-0x0
[ 1180.929423] iwlwifi 0000:03:00.0: U iwl_enable_interrupts Enabling interrupts
[ 1180.929431] iwlwifi 0000:03:00.0: U iwl_pcie_load_section [0] uCode section being loaded...
[ 1185.926627] iwlwifi 0000:03:00.0: Failed to load firmware chunk!
[ 1185.926967] iwlwifi 0000:03:00.0: Could not load the [0] uCode section
[ 1185.927256] iwlwifi 0000:03:00.0: U iwl_disable_interrupts Disabled interrupts
[ 1185.927442] iwlwifi 0000:03:00.0: U iwl_pcie_apm_stop Stop card, put in low power state
[ 1185.927449] iwlwifi 0000:03:00.0: U iwl_pcie_apm_stop_master stop master
[ 1185.927465] iwlwifi 0000:03:00.0: U iwl_disable_interrupts Disabled interrupts
[ 1185.927467] iwlwifi 0000:03:00.0: U iwl_enable_rfkill_int Enabling rfkill interrupt
[ 1185.927470] iwlwifi 0000:03:00.0: Failed to run INIT ucode: -110
[ 1185.927712] iwlwifi 0000:03:00.0: U iwl_down iwlwifi is going down
[ 1185.927715] iwlwifi 0000:03:00.0: U iwl_scan_cancel_timeout Scan cancel timeout
[ 1185.927718] iwlwifi 0000:03:00.0: U iwl_do_scan_abort Not performing scan to abort
[ 1185.927721] iwlwifi 0000:03:00.0: U iwl_clear_ucode_stations Clearing ucode stations in driver
[ 1185.927725] iwlwifi 0000:03:00.0: U iwl_clear_ucode_stations No active stations found to be cleared
[ 1185.927733] iwlwifi 0000:03:00.0: U iwl_disable_interrupts Disabled interrupts
[ 1185.927738] iwlwifi 0000:03:00.0: U iwl_pcie_apm_stop Stop card, put in low power state
[ 1185.927744] iwlwifi 0000:03:00.0: U iwl_pcie_apm_stop_master stop master
[ 1185.927759] iwlwifi 0000:03:00.0: U iwl_disable_interrupts Disabled interrupts
[ 1185.927761] iwlwifi 0000:03:00.0: U iwl_enable_rfkill_int Enabling rfkill interrupt
[ 1185.927763] iwlwifi 0000:03:00.0: Unable to initialize device.
^ permalink raw reply
* Re: kmemleak report in 3.9.5+, related to cfg80211_inform_bss_frame
From: Ben Greear @ 2013-06-12 0:36 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <51B77594.20000@candelatech.com>
On 06/11/2013 12:08 PM, Ben Greear wrote:
> On 06/11/2013 12:00 PM, Ben Greear wrote:
>> I see several reports similar to the one below while doing some
>> kmemleak testing on my 3.9.5+ tree (with local patches applied):
>>
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
>> The kmemleak report is below:
>>
>>
>> unreferenced object 0xffff8801c8e41e78 (size 192):
>> comm "kworker/u:2", pid 157, jiffies 4295509873 (age 86582.869s)
>> hex dump (first 32 bytes):
>> 41 0d 00 30 02 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b A..0....kkkkkkkk
>> 6b 6b 6b 6b 6b 6b 6b 6b 69 00 00 00 00 0c 2e 32 kkkkkkkki......2
>> backtrace:
>> [<ffffffff815de7bf>] kmemleak_alloc+0x73/0x98
>> [<ffffffff8118b4d4>] slab_post_alloc_hook+0x28/0x2a
>> [<ffffffff8118d605>] __kmalloc+0xf9/0x122
>> [<ffffffffa027cb27>] cfg80211_inform_bss_frame+0x114/0x1f8 [cfg80211]
>> [<ffffffffa03d6865>] ieee80211_bss_info_update+0x66/0x21f [mac80211]
>> [<ffffffffa040aec6>] ieee80211_rx_bss_info+0x12f/0x1ca [mac80211]
>> [<ffffffffa040b017>] ieee80211_rx_mgmt_probe_resp+0xb6/0x197 [mac80211]
>> [<ffffffffa040e8a3>] ieee80211_sta_rx_queued_mgmt+0xdd/0x60e [mac80211]
>> [<ffffffffa03df0ee>] ieee80211_iface_work+0x238/0x2cc [mac80211]
>> [<ffffffff810b0cd3>] process_one_work+0x292/0x42e
>> [<ffffffff810b36af>] worker_thread+0x14f/0x264
>> [<ffffffff810b7bea>] kthread+0xc7/0xcf
>> [<ffffffff815f64ec>] ret_from_fork+0x7c/0xb0
>> [<ffffffffffffffff>] 0xffffffffffffffff
Something else came to mind on this.
To determine if we should delete an old pointer to memory,
we do an rcu_access_pointer to read the old value, and
we are assigning with rcu_assign_pointer.
Could this be racing so that rcu_access_pointer returns NULL
when looking for the old pointer, but other threads manage
to set the pointer more than once, leaking all but the last
to be set?
For instance, this code:
if (found) {
/* Update IEs */
if (rcu_access_pointer(tmp->pub.proberesp_ies)) {
const struct cfg80211_bss_ies *old;
old = rcu_access_pointer(found->pub.proberesp_ies);
rcu_assign_pointer(found->pub.proberesp_ies,
tmp->pub.proberesp_ies);
/* Override possible earlier Beacon frame IEs */
rcu_assign_pointer(found->pub.ies,
tmp->pub.proberesp_ies);
if (old)
kfree_rcu((struct cfg80211_bss_ies *)old,
rcu_head);
I don't see a huge number of leaks..but they are definitely
accumulating if kmemleak is to be believed...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.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