* [PATCH v2] ath10k: fix group privacy action frame decryption for qca4019
From: Rajkumar Manoharan @ 2016-08-09 6:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
Recent commit 'mac80211: Encrypt "Group addressed privacy" action frames'
encrypts group privacy action frames. But qca99x0 family chipset delivers
broadcast/multicast management frames as encrypted and it should be
decrypted by mac80211. Setting RX_FLAG_DECRYPTED stats for those frames
is breaking mesh connection establishment.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
v2: is_broadcast_ether_addr check not needed
drivers/net/wireless/ath/ath10k/core.c | 4 ++++
drivers/net/wireless/ath/ath10k/core.h | 5 +++++
drivers/net/wireless/ath/ath10k/wmi.c | 29 ++++++++++++++++++++++++-----
3 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 0ca58cf0ffea..c4d1a5ba216e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -182,6 +182,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -205,6 +206,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -285,6 +288,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
};
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index f36c2b274ee5..7254bd3e7c82 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -765,6 +765,11 @@ struct ath10k {
size_t board_size;
size_t board_ext_size;
} fw;
+
+ /* qca99x0 family chips deliver broadcast/multicast management
+ * frames encrypted and expect software do decryption.
+ */
+ bool sw_decrypt_mcast_mgmt;
} hw_params;
/* contains the firmware images used with ATH10K_FIRMWARE_MODE_NORMAL */
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 169cd2e783eb..29b7eca071fc 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2240,6 +2240,29 @@ static int ath10k_wmi_10_4_op_pull_mgmt_rx_ev(struct ath10k *ar,
return 0;
}
+static bool ath10k_wmi_rx_is_decrypted(struct ath10k *ar,
+ struct ieee80211_hdr *hdr)
+{
+ if (!ieee80211_has_protected(hdr->frame_control))
+ return false;
+
+ /* FW delivers WEP Shared Auth frame with Protected Bit set and
+ * encrypted payload. However in case of PMF it delivers decrypted
+ * frames with Protected Bit set.
+ */
+ if (ieee80211_is_auth(hdr->frame_control))
+ return false;
+
+ /* qca99x0 based FW delivers broadcast or multicast management frames
+ * (ex: group privacy action frames in mesh) as encrypted payload.
+ */
+ if (is_multicast_ether_addr(ieee80211_get_DA(hdr)) &&
+ ar->hw_params.sw_decrypt_mcast_mgmt)
+ return false;
+
+ return true;
+}
+
int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
{
struct wmi_mgmt_rx_ev_arg arg = {};
@@ -2326,11 +2349,7 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
ath10k_wmi_handle_wep_reauth(ar, skb, status);
- /* FW delivers WEP Shared Auth frame with Protected Bit set and
- * encrypted payload. However in case of PMF it delivers decrypted
- * frames with Protected Bit set. */
- if (ieee80211_has_protected(hdr->frame_control) &&
- !ieee80211_is_auth(hdr->frame_control)) {
+ if (ath10k_wmi_rx_is_decrypted(ar, hdr)) {
status->flag |= RX_FLAG_DECRYPTED;
if (!ieee80211_is_action(hdr->frame_control) &&
--
2.9.2
^ permalink raw reply related
* Re: Wireless Workshop accepted into the 2016 Linux Kernel Summit and Linux Plumbers Conference
From: Johannes Berg @ 2016-08-09 6:31 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1470331975.29954.9.camel@sipsolutions.net>
> Please consider adding yourself, I have a number of free/reduced
> passes to hand out so I'll assign those maybe next week. You do need
> to be registered for LPC, which is currently closed for
> registrations, but I'm trying to see if we can get reservations or
> maybe workshop-only tickets.
Instead of that, we also have some reserved passes at a full rate now.
Please make plans as soon as you can, if you intend to participate.
I want to hand those out (getting the names to the LPC committee)
before full registration opens on August 27th. First come first serve,
since I don't have a better mechanism.
johannes
^ permalink raw reply
* RE: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Pan, Miaoqing @ 2016-08-09 6:30 UTC (permalink / raw)
To: Jason Cooper, Stephan Mueller
Cc: Ted Tso, Sepehrdad, Pouyan, herbert@gondor.apana.org.au,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Kalle Valo
In-Reply-To: <20160808172930.GD4511@io.lakedaemon.net>
Hi Jason, Stephan,
Agree with Jason's point, also understand Stephan's concern. The date rate can be roughly estimated by 'cat /dev/random |rngtest -c 1000', the average speed is 1111.294Kibits/s. I will sent the patch to disable ath9k RNG by default.
Thanks,
Miaoqing
-----Original Message-----
From: Jason Cooper [mailto:jason@lakedaemon.net]
Sent: Tuesday, August 09, 2016 1:30 AM
To: Stephan Mueller <smueller@chronox.de>
Cc: Pan, Miaoqing <miaoqing@qti.qualcomm.com>; Ted Tso <tytso@mit.edu>; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>; herbert@gondor.apana.org.au; linux-kernel@vger.kernel.org; linux-crypto@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org; Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
Hi Stephan, Miaoqing Pan,
On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert, the analysis report
> > show the ADC with at least 10bits and up to 22 bits of min-entropy
> > for a 32 bits value, we conservatively assume the min-entropy is 10
> > bits out of 32 bits, so that's why set entropy quality to 320/1024 = 10/32.
Ok, so the relevant commit is:
ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture
Which refers to a previous commit:
6301566e0b2d ath9k: export HW random number generator
> > Also we have explained in the commit message why can't use the HW
> > RNG framework.
>From ed14dc0af7cce:
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to bind it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?
> >
> > Otherwise, your patch will cause high CPU load, as continuously
> > read ADC data if entropy bits under write_wakeup_threshold.
>
> The issue is that although you may have analyzed it, others are unable
> to measure the quality of the RNG and assess the design as well as the
> implementation of the RNG. This RNG is the only implementation of a
> hardware RNG that per default and without being able to change it at
> runtime injects data into the input_pool where the noise source cannot
> be audited. Note, even other respected RNG noise sources like the
> Intel RDRAND will not feed into / dev/random per default in a way that dominates all other noise sources.
>
> I would like to be able to deactivate that noise source to the extent
> that it does not cause /dev/random to unblock. The reason is that your
> noise source starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card (HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts
> to spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng framework. Interrupt timings were never designed to be a source of entropy either. We need to grab it where ever we can find it, especially on embedded systems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be bogus (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of sources under char/hw_random/. I think the only thing we would be concerned about, other than the already addressed entropy estimation, would be constraining the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about sound cards?
thx,
Jason.
^ permalink raw reply
* Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: H. Nikolaus Schaller @ 2016-08-09 5:25 UTC (permalink / raw)
To: Discussions about the Letux Kernel; +Cc: linux-wireless, LKML
In-Reply-To: <20160808234959.47us7rukzpwplsdo@zver>
Hi Andrey,
> Am 09.08.2016 um 01:49 schrieb Andrey Utkin <andrey_utkin@fastmail.com>:
>
> On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
>> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
>> I hope someone knows what it means.
>>
>> BR and thanks,
>> Nikolaus
>>
>> root@letux:~# poweroff
>>
>> Broadcast message from root@letux (pts/0) (Mon Aug 8 21:19:21 2016):
>>
>> The system is going down for system halt NOW!
>>
>> xinit: unexpected signal 15
>> [info] Using makefile-style concurrent boot in runlevel 0.
>> [....] Stopping ISC DHCP server: dhcpd failed!
>> [....] Stopping bluetooth: /usr/sbin/bluetoothd. ok
>> [....] Stopping automount.... ok
>> [....] Not running dhcpcd because /etc/network/interfaces ... failed!
>> [....] defines some interfaces that will use a DHCP client ... failed!
>> [....] Shutting down ALSA...done.
>> [....] Asking all remaining processes to terminate...done.
>> [....] All processes ended within 1 seconds...done.
>> [....] Stopping enhanced syslogd: rsyslogd. ok
>> [....] Deconfiguring network interfaces...SIOCDELRT: No such process
>> Device "usb0" does not exist.
>> Cannot find device "usb0"
>> done.
>> [info] Saving the system clock.
>> [info] Hardware Clock updated to Mon Aug 8 21:19:30 UTC 2016.
>> [....] Unmounting temporary filesystems...done.
>> [....] Deactivating swap...done.
>> [....] Unmounting local filesystems...done.
>> [ 613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
>> [info] Will now halt.
>> [ 615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local choice (Reason: 3=DEAUTH_LEAVING)
>> [ 615.589721] Unable to handle kernel NULL pointer dereference at virtual address 00000a2a
>> [ 615.598249] pgd = ec3a4000
>> [ 615.601220] [00000a2a] *pgd=ab60f835, *pte=00000000, *ppte=00000000
>> [ 615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> [ 615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap snd_pcm_dmaengine [last unloaded: g_ether]
>> [ 615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: G B W 4.8.0-rc1-letux+ #655
>> [ 615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
>> [ 615.709052] task: eb2564c0 task.stack: ec456000
>> [ 615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
>> [ 615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
>> [ 615.727145] pc : [<bf4de050>] lr : [<bf40cf20>] psr: a00f0013
>> [ 615.727145] sp : ec457c48 ip : 00000000 fp : 400f0013
>> [ 615.739237] r10: ec414620 r9 : eb604b30 r8 : eb604c90
>> [ 615.744735] r7 : c0b02554 r6 : bf4815c4 r5 : bf4de03c r4 : ec823400
>> [ 615.751613] r3 : 00000000 r2 : 00000000 r1 : 000000c8 r0 : 000003e8
>> [ 615.758492] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
>> [ 615.766008] Control: 10c5387d Table: ac3a406a DAC: 00000051
>> [ 615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
>> [ 615.778208] Stack: (0xec457c48 to 0xec458000)
>> [ 615.782806] 7c40: 00000001 00000000 bf40d540 c0a76630 eb604f3c bf40d540
>> [ 615.791434] 7c60: ec414620 00000000 00000000 eb604a8c eb604c90 00000000 00000001 eb604800
>> [ 615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 00000001 ec414b94 00000000 bf40d540
>> [ 615.808682] 7ca0: 00000000 00000003 ec457cb0 ec414b94 ec457cb8 bf40d75c eb604808 eb604808
>> [ 615.817308] 7cc0: 00000000 ec45a600 00000000 ec414620 ec45ac50 ec457d1e 000000c0 00000003
>> [ 615.825940] 7ce0: ffffffff bf4629e8 00000001 ec457d1e ec45a600 ec457d60 ec457d1e 00000001
>> [ 615.834563] 7d00: bf38707c bf386c94 00000003 bf4680cc ec457d1e 00000000 ec45a67c 00c00000
>> [ 615.843178] 7d20: 12000000 e6ce7dbf efbeadde 12000000 e6ce7dbf 00030000 00000001 ec892bd4
>> [ 615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 00000003 ffffffff bf352b58
>> [ 615.860428] 7d60: ec892bd4 00000000 00000000 00000003 ec45a648 ec45a608 ec414000 ec414000
>> [ 615.869051] 7d80: ec414000 ec45a000 00000003 bf3590c0 00000000 00000003 00000000 ec45a000
>> [ 615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 00000009 ec96cc0c 00000000
>> [ 615.886300] 7dc0: ffffffff bf31cba8 ec45a608 ec4142a0 ec45a000 bf31cd70 00000000 00000000
>> [ 615.894918] 7de0: c06d0594 c06da874 c0b98444 fffffff7 00000000 00000009 ec457e3c bf47bb38
>> [ 615.903540] 7e00: ec96cc0c 00000000 ffffffff c0152df8 ec45a000 ec457e58 00001042 00001003
>> [ 615.912162] 7e20: 00000000 c0152e40 00000000 00000009 ec457e3c c0620eb4 00000009 ec45a000
>> [ 615.920786] 7e40: c062b690 c0620fd0 ec45a04c ec45a000 00000001 c0621134 ec45a04c ec45a04c
>> [ 615.929410] 7e60: c062b690 c062b97c ec45a000 00001003 ec45a150 ec45a000 00000000 c062ba38
>> [ 615.938027] 7e80: ec8f7600 00000000 ec96cc00 ec45a000 00000000 c0697f8c 00000000 beabc47c
>> [ 615.946652] 7ea0: 00000020 00000000 6e616c77 00000030 00000000 00000000 00001042 8202a8c0
>> [ 615.955275] 7ec0: 00000000 00000000 00000000 00008914 ed5014a0 beabc47c c0b90c80 ed501480
>> [ 615.963900] 7ee0: 00000003 00000000 00000001 c0609a30 beabc47c ed5014a0 eb34b140 c026560c
>> [ 615.972524] 7f00: 00000003 c0264ac4 0000c000 c02654a4 600f0013 c135c654 c08a43f4 eb2dccb4
>> [ 615.981145] 7f20: ec456000 00000000 00000003 eb34b140 ec456000 00000000 00000001 c0271cd8
>> [ 615.989769] 7f40: 00000000 00000000 c0271a44 c0255308 c0b03bc0 00000000 ed501480 c0609684
>> [ 615.998389] 7f60: ed813710 00000000 eb34b140 eb34b140 beabc47c 00008914 00000003 00000000
>> [ 616.007012] 7f80: 00000001 c026560c 00001042 beabc47c 00000000 beabc49c 00000036 c0107204
>> [ 616.015636] 7fa0: ec456000 c0107060 beabc47c 00000000 00000003 00008914 beabc47c 00001042
>> [ 616.024253] 7fc0: beabc47c 00000000 beabc49c 00000036 000230f0 00023100 00000003 00000001
>> [ 616.032875] 7fe0: 00023054 beabc44c 0001135b b6e83206 a00f0030 00000003 00000000 00000000
>> [ 616.041894] [<bf4de050>] (wlcore_op_get_expected_throughput [wlcore]) from [<bf40cf20>] (sta_set_sinfo+0xc18/0x1110 [mac80211])
>> [ 616.054542] [<bf40cf20>] (sta_set_sinfo [mac80211]) from [<bf40d540>] (__sta_info_destroy_part2+0x128/0x194 [mac80211])
>> [ 616.066426] [<bf40d540>] (__sta_info_destroy_part2 [mac80211]) from [<bf40d75c>] (__sta_info_flush+0xf8/0x13c [mac80211])
>> [ 616.078513] [<bf40d75c>] (__sta_info_flush [mac80211]) from [<bf4629e8>] (ieee80211_set_disassoc+0x168/0x2f8 [mac80211])
>> [ 616.090512] [<bf4629e8>] (ieee80211_set_disassoc [mac80211]) from [<bf4680cc>] (ieee80211_mgd_deauth+0x3dc/0x9fc [mac80211])
>> [ 616.102861] [<bf4680cc>] (ieee80211_mgd_deauth [mac80211]) from [<bf352b58>] (cfg80211_mlme_deauth+0x1f4/0x458 [cfg80211])
>> [ 616.114978] [<bf352b58>] (cfg80211_mlme_deauth [cfg80211]) from [<bf3590c0>] (cfg80211_disconnect+0xa0/0x4a4 [cfg80211])
>> [ 616.126880] [<bf3590c0>] (cfg80211_disconnect [cfg80211]) from [<bf31cba8>] (cfg80211_leave+0x28/0x34 [cfg80211])
>> [ 616.138137] [<bf31cba8>] (cfg80211_leave [cfg80211]) from [<bf31cd70>] (cfg80211_netdev_notifier_call+0x1bc/0x84c [cfg80211])
>> [ 616.150287] [<bf31cd70>] (cfg80211_netdev_notifier_call [cfg80211]) from [<c0152df8>] (notifier_call_chain+0x40/0x68)
>> [ 616.161479] [<c0152df8>] (notifier_call_chain) from [<c0152e40>] (raw_notifier_call_chain+0x14/0x1c)
>> [ 616.171111] [<c0152e40>] (raw_notifier_call_chain) from [<c0620eb4>] (call_netdevice_notifiers+0xc/0x14)
>> [ 616.181108] [<c0620eb4>] (call_netdevice_notifiers) from [<c0620fd0>] (__dev_close_many+0x48/0xb8)
>> [ 616.190551] [<c0620fd0>] (__dev_close_many) from [<c0621134>] (__dev_close+0x20/0x34)
>> [ 616.198806] [<c0621134>] (__dev_close) from [<c062b97c>] (__dev_change_flags+0x8c/0x130)
>> [ 616.207347] [<c062b97c>] (__dev_change_flags) from [<c062ba38>] (dev_change_flags+0x18/0x48)
>> [ 616.216255] [<c062ba38>] (dev_change_flags) from [<c0697f8c>] (devinet_ioctl+0x338/0x704)
>> [ 616.224883] [<c0697f8c>] (devinet_ioctl) from [<c0609a30>] (sock_ioctl+0x288/0x2d8)
>> [ 616.232959] [<c0609a30>] (sock_ioctl) from [<c0264ac4>] (vfs_ioctl+0x20/0x34)
>> [ 616.240482] [<c0264ac4>] (vfs_ioctl) from [<c02654a4>] (do_vfs_ioctl+0x854/0x970)
>> [ 616.248369] [<c02654a4>] (do_vfs_ioctl) from [<c026560c>] (SyS_ioctl+0x4c/0x74)
>> [ 616.256078] [<c026560c>] (SyS_ioctl) from [<c0107060>] (ret_fast_syscall+0x0/0x1c)
>> [ 616.264075] Code: e3a010c8 e5d02098 e3a00ffa e0233291 (e5d33a2a)
>> [ 616.272268] ---[ end trace 00ab29170ed628ed ]---
>> Segmentation fault
>> [....] startpar: service(s) skipped, program is not configured: dhcpcd ... (warning).
>> INIT: no more processes left in this runlevel
>
> Just curious - in which way did you get this log? netconsole, serial line or what?
serial port.
>
> Does this happen with older kernels? I guess yes.
No, I didn't see it before moving to 4.8-rc1
>
> Looks like insanity in net/mac80211/sta_info.c to me. The module is
> going to destroy sta_info (whatever it means), then it calls again
> sta_set_sinfo() which seems doing a lot of initialization work, which in
> turn involves calling a routine from hardware-specific driver (wlcore),
> which apparently doesn't expect to be run in context of shutdown, so to
> say. My speculation is very rough, but I think this worth forwarding to
> net/mac80211/sta_info.c maintainers. I haven't CCed them for now, but I
> would do so.
Yes, please do so!
>
> $ ./scripts/get_maintainer.pl -f net/mac80211/sta_info.c
> Johannes Berg <johannes@sipsolutions.net> (maintainer:MAC80211)
> "David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING [GENERAL])
> linux-wireless@vger.kernel.org (open list:MAC80211)
> netdev@vger.kernel.org (open list:NETWORKING [GENERAL])
> linux-kernel@vger.kernel.org (open list)
>
> $ ./scripts/get_maintainer.pl -f drivers/net/wireless/ti/wlcore
> Kalle Valo <kvalo@codeaurora.org> (maintainer:NETWORKING DRIVERS (WIRELESS),commit_signer:24/31=77%)
> Eliad Peller <eliad@wizery.com> (commit_signer:6/31=19%,authored:5/31=16%)
> Guy Mishol <guym@ti.com> (commit_signer:4/31=13%,authored:3/31=10%)
> Uri Mashiach <uri.mashiach@compulab.co.il> (commit_signer:4/31=13%,authored:4/31=13%)
> Johannes Berg <johannes.berg@intel.com> (commit_signer:4/31=13%)
> "Reizer, Eyal" <eyalr@ti.com> (authored:2/31=6%)
> Maxim Altshul <maxim.altshul@ti.com> (authored:2/31=6%)
> linux-wireless@vger.kernel.org (open list:TI WILINK WIRELESS DRIVERS)
> netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
> linux-kernel@vger.kernel.org (open list)
BR and thanks,
Nikolaus
^ permalink raw reply
* net-next is OPEN
From: David Miller @ 2016-08-09 5:24 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, netfilter-devel
I've merged 'net' into 'net-next' and applied a bunch of pending stuff.
Fire at will...
^ permalink raw reply
* Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: Andrey Utkin @ 2016-08-08 23:49 UTC (permalink / raw)
To: Discussions about the Letux Kernel; +Cc: linux-wireless, LKML
In-Reply-To: <4FEB5780-826B-49C3-81E9-D361CD12DD4A@goldelico.com>
On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
> I hope someone knows what it means.
>
> BR and thanks,
> Nikolaus
>
> root@letux:~# poweroff
>
> Broadcast message from root@letux (pts/0) (Mon Aug 8 21:19:21 2016):
>
> The system is going down for system halt NOW!
>
> xinit: unexpected signal 15
> [info] Using makefile-style concurrent boot in runlevel 0.
> [....] Stopping ISC DHCP server: dhcpd failed!
> [....] Stopping bluetooth: /usr/sbin/bluetoothd. ok
> [....] Stopping automount.... ok
> [....] Not running dhcpcd because /etc/network/interfaces ... failed!
> [....] defines some interfaces that will use a DHCP client ... failed!
> [....] Shutting down ALSA...done.
> [....] Asking all remaining processes to terminate...done.
> [....] All processes ended within 1 seconds...done.
> [....] Stopping enhanced syslogd: rsyslogd. ok
> [....] Deconfiguring network interfaces...SIOCDELRT: No such process
> Device "usb0" does not exist.
> Cannot find device "usb0"
> done.
> [info] Saving the system clock.
> [info] Hardware Clock updated to Mon Aug 8 21:19:30 UTC 2016.
> [....] Unmounting temporary filesystems...done.
> [....] Deactivating swap...done.
> [....] Unmounting local filesystems...done.
> [ 613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> [info] Will now halt.
> [ 615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local choice (Reason: 3=DEAUTH_LEAVING)
> [ 615.589721] Unable to handle kernel NULL pointer dereference at virtual address 00000a2a
> [ 615.598249] pgd = ec3a4000
> [ 615.601220] [00000a2a] *pgd=ab60f835, *pte=00000000, *ppte=00000000
> [ 615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [ 615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap snd_pcm_dmaengine [last unloaded: g_ether]
> [ 615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: G B W 4.8.0-rc1-letux+ #655
> [ 615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
> [ 615.709052] task: eb2564c0 task.stack: ec456000
> [ 615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
> [ 615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
> [ 615.727145] pc : [<bf4de050>] lr : [<bf40cf20>] psr: a00f0013
> [ 615.727145] sp : ec457c48 ip : 00000000 fp : 400f0013
> [ 615.739237] r10: ec414620 r9 : eb604b30 r8 : eb604c90
> [ 615.744735] r7 : c0b02554 r6 : bf4815c4 r5 : bf4de03c r4 : ec823400
> [ 615.751613] r3 : 00000000 r2 : 00000000 r1 : 000000c8 r0 : 000003e8
> [ 615.758492] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 615.766008] Control: 10c5387d Table: ac3a406a DAC: 00000051
> [ 615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
> [ 615.778208] Stack: (0xec457c48 to 0xec458000)
> [ 615.782806] 7c40: 00000001 00000000 bf40d540 c0a76630 eb604f3c bf40d540
> [ 615.791434] 7c60: ec414620 00000000 00000000 eb604a8c eb604c90 00000000 00000001 eb604800
> [ 615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 00000001 ec414b94 00000000 bf40d540
> [ 615.808682] 7ca0: 00000000 00000003 ec457cb0 ec414b94 ec457cb8 bf40d75c eb604808 eb604808
> [ 615.817308] 7cc0: 00000000 ec45a600 00000000 ec414620 ec45ac50 ec457d1e 000000c0 00000003
> [ 615.825940] 7ce0: ffffffff bf4629e8 00000001 ec457d1e ec45a600 ec457d60 ec457d1e 00000001
> [ 615.834563] 7d00: bf38707c bf386c94 00000003 bf4680cc ec457d1e 00000000 ec45a67c 00c00000
> [ 615.843178] 7d20: 12000000 e6ce7dbf efbeadde 12000000 e6ce7dbf 00030000 00000001 ec892bd4
> [ 615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 00000003 ffffffff bf352b58
> [ 615.860428] 7d60: ec892bd4 00000000 00000000 00000003 ec45a648 ec45a608 ec414000 ec414000
> [ 615.869051] 7d80: ec414000 ec45a000 00000003 bf3590c0 00000000 00000003 00000000 ec45a000
> [ 615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 00000009 ec96cc0c 00000000
> [ 615.886300] 7dc0: ffffffff bf31cba8 ec45a608 ec4142a0 ec45a000 bf31cd70 00000000 00000000
> [ 615.894918] 7de0: c06d0594 c06da874 c0b98444 fffffff7 00000000 00000009 ec457e3c bf47bb38
> [ 615.903540] 7e00: ec96cc0c 00000000 ffffffff c0152df8 ec45a000 ec457e58 00001042 00001003
> [ 615.912162] 7e20: 00000000 c0152e40 00000000 00000009 ec457e3c c0620eb4 00000009 ec45a000
> [ 615.920786] 7e40: c062b690 c0620fd0 ec45a04c ec45a000 00000001 c0621134 ec45a04c ec45a04c
> [ 615.929410] 7e60: c062b690 c062b97c ec45a000 00001003 ec45a150 ec45a000 00000000 c062ba38
> [ 615.938027] 7e80: ec8f7600 00000000 ec96cc00 ec45a000 00000000 c0697f8c 00000000 beabc47c
> [ 615.946652] 7ea0: 00000020 00000000 6e616c77 00000030 00000000 00000000 00001042 8202a8c0
> [ 615.955275] 7ec0: 00000000 00000000 00000000 00008914 ed5014a0 beabc47c c0b90c80 ed501480
> [ 615.963900] 7ee0: 00000003 00000000 00000001 c0609a30 beabc47c ed5014a0 eb34b140 c026560c
> [ 615.972524] 7f00: 00000003 c0264ac4 0000c000 c02654a4 600f0013 c135c654 c08a43f4 eb2dccb4
> [ 615.981145] 7f20: ec456000 00000000 00000003 eb34b140 ec456000 00000000 00000001 c0271cd8
> [ 615.989769] 7f40: 00000000 00000000 c0271a44 c0255308 c0b03bc0 00000000 ed501480 c0609684
> [ 615.998389] 7f60: ed813710 00000000 eb34b140 eb34b140 beabc47c 00008914 00000003 00000000
> [ 616.007012] 7f80: 00000001 c026560c 00001042 beabc47c 00000000 beabc49c 00000036 c0107204
> [ 616.015636] 7fa0: ec456000 c0107060 beabc47c 00000000 00000003 00008914 beabc47c 00001042
> [ 616.024253] 7fc0: beabc47c 00000000 beabc49c 00000036 000230f0 00023100 00000003 00000001
> [ 616.032875] 7fe0: 00023054 beabc44c 0001135b b6e83206 a00f0030 00000003 00000000 00000000
> [ 616.041894] [<bf4de050>] (wlcore_op_get_expected_throughput [wlcore]) from [<bf40cf20>] (sta_set_sinfo+0xc18/0x1110 [mac80211])
> [ 616.054542] [<bf40cf20>] (sta_set_sinfo [mac80211]) from [<bf40d540>] (__sta_info_destroy_part2+0x128/0x194 [mac80211])
> [ 616.066426] [<bf40d540>] (__sta_info_destroy_part2 [mac80211]) from [<bf40d75c>] (__sta_info_flush+0xf8/0x13c [mac80211])
> [ 616.078513] [<bf40d75c>] (__sta_info_flush [mac80211]) from [<bf4629e8>] (ieee80211_set_disassoc+0x168/0x2f8 [mac80211])
> [ 616.090512] [<bf4629e8>] (ieee80211_set_disassoc [mac80211]) from [<bf4680cc>] (ieee80211_mgd_deauth+0x3dc/0x9fc [mac80211])
> [ 616.102861] [<bf4680cc>] (ieee80211_mgd_deauth [mac80211]) from [<bf352b58>] (cfg80211_mlme_deauth+0x1f4/0x458 [cfg80211])
> [ 616.114978] [<bf352b58>] (cfg80211_mlme_deauth [cfg80211]) from [<bf3590c0>] (cfg80211_disconnect+0xa0/0x4a4 [cfg80211])
> [ 616.126880] [<bf3590c0>] (cfg80211_disconnect [cfg80211]) from [<bf31cba8>] (cfg80211_leave+0x28/0x34 [cfg80211])
> [ 616.138137] [<bf31cba8>] (cfg80211_leave [cfg80211]) from [<bf31cd70>] (cfg80211_netdev_notifier_call+0x1bc/0x84c [cfg80211])
> [ 616.150287] [<bf31cd70>] (cfg80211_netdev_notifier_call [cfg80211]) from [<c0152df8>] (notifier_call_chain+0x40/0x68)
> [ 616.161479] [<c0152df8>] (notifier_call_chain) from [<c0152e40>] (raw_notifier_call_chain+0x14/0x1c)
> [ 616.171111] [<c0152e40>] (raw_notifier_call_chain) from [<c0620eb4>] (call_netdevice_notifiers+0xc/0x14)
> [ 616.181108] [<c0620eb4>] (call_netdevice_notifiers) from [<c0620fd0>] (__dev_close_many+0x48/0xb8)
> [ 616.190551] [<c0620fd0>] (__dev_close_many) from [<c0621134>] (__dev_close+0x20/0x34)
> [ 616.198806] [<c0621134>] (__dev_close) from [<c062b97c>] (__dev_change_flags+0x8c/0x130)
> [ 616.207347] [<c062b97c>] (__dev_change_flags) from [<c062ba38>] (dev_change_flags+0x18/0x48)
> [ 616.216255] [<c062ba38>] (dev_change_flags) from [<c0697f8c>] (devinet_ioctl+0x338/0x704)
> [ 616.224883] [<c0697f8c>] (devinet_ioctl) from [<c0609a30>] (sock_ioctl+0x288/0x2d8)
> [ 616.232959] [<c0609a30>] (sock_ioctl) from [<c0264ac4>] (vfs_ioctl+0x20/0x34)
> [ 616.240482] [<c0264ac4>] (vfs_ioctl) from [<c02654a4>] (do_vfs_ioctl+0x854/0x970)
> [ 616.248369] [<c02654a4>] (do_vfs_ioctl) from [<c026560c>] (SyS_ioctl+0x4c/0x74)
> [ 616.256078] [<c026560c>] (SyS_ioctl) from [<c0107060>] (ret_fast_syscall+0x0/0x1c)
> [ 616.264075] Code: e3a010c8 e5d02098 e3a00ffa e0233291 (e5d33a2a)
> [ 616.272268] ---[ end trace 00ab29170ed628ed ]---
> Segmentation fault
> [....] startpar: service(s) skipped, program is not configured: dhcpcd ... (warning).
> INIT: no more processes left in this runlevel
Just curious - in which way did you get this log? netconsole, serial line or what?
Does this happen with older kernels? I guess yes.
Looks like insanity in net/mac80211/sta_info.c to me. The module is
going to destroy sta_info (whatever it means), then it calls again
sta_set_sinfo() which seems doing a lot of initialization work, which in
turn involves calling a routine from hardware-specific driver (wlcore),
which apparently doesn't expect to be run in context of shutdown, so to
say. My speculation is very rough, but I think this worth forwarding to
net/mac80211/sta_info.c maintainers. I haven't CCed them for now, but I
would do so.
$ ./scripts/get_maintainer.pl -f net/mac80211/sta_info.c
Johannes Berg <johannes@sipsolutions.net> (maintainer:MAC80211)
"David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING [GENERAL])
linux-wireless@vger.kernel.org (open list:MAC80211)
netdev@vger.kernel.org (open list:NETWORKING [GENERAL])
linux-kernel@vger.kernel.org (open list)
$ ./scripts/get_maintainer.pl -f drivers/net/wireless/ti/wlcore
Kalle Valo <kvalo@codeaurora.org> (maintainer:NETWORKING DRIVERS (WIRELESS),commit_signer:24/31=77%)
Eliad Peller <eliad@wizery.com> (commit_signer:6/31=19%,authored:5/31=16%)
Guy Mishol <guym@ti.com> (commit_signer:4/31=13%,authored:3/31=10%)
Uri Mashiach <uri.mashiach@compulab.co.il> (commit_signer:4/31=13%,authored:4/31=13%)
Johannes Berg <johannes.berg@intel.com> (commit_signer:4/31=13%)
"Reizer, Eyal" <eyalr@ti.com> (authored:2/31=6%)
Maxim Altshul <maxim.altshul@ti.com> (authored:2/31=6%)
linux-wireless@vger.kernel.org (open list:TI WILINK WIRELESS DRIVERS)
netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
linux-kernel@vger.kernel.org (open list)
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-08 22:04 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Ted Tso, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo
In-Reply-To: <20160808172930.GD4511@io.lakedaemon.net>
Hi Stephan,
On Mon, Aug 08, 2016 at 05:29:30PM +0000, Jason Cooper wrote:
> On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
...
> > If you think that this patch is a challenge because your driver starts to
> > spin, please help and offer another solution.
>
> Well, I don't buy the reasoning listed above for not using the hwrng
> framework. Interrupt timings were never designed to be a source of entropy
> either. We need to grab it where ever we can find it, especially on
> embedded systems. Documentation/hw_random.txt even says:
>
> """
> This data is NOT CHECKED by any fitness tests, and could potentially be
> bogus (if the hardware is faulty or has been tampered with).
> """
>
> I really don't think there's a problem with adding these sorts of
> sources under char/hw_random/. I think the only thing we would be
> concerned about, other than the already addressed entropy estimation,
> would be constraining the data rate.
Further research yields char/hw_random/timeriomem-rng.c
It could use an update to ->read() vice data_{present,read}(), but it's
functionally exactly what the ath9k rng is doing. :)
thx,
Jason.
^ permalink raw reply
* [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput
From: H. Nikolaus Schaller @ 2016-08-08 21:26 UTC (permalink / raw)
To: linux-wireless; +Cc: LKML, Discussions about the Letux Kernel
Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
I hope someone knows what it means.
BR and thanks,
Nikolaus
root@letux:~# poweroff
Broadcast message from root@letux (pts/0) (Mon Aug 8 21:19:21 2016):
The system is going down for system halt NOW!
xinit: unexpected signal 15
[info] Using makefile-style concurrent boot in runlevel 0.
[....] Stopping ISC DHCP server: dhcpd failed!
[....] Stopping bluetooth: /usr/sbin/bluetoothd. ok
[....] Stopping automount.... ok
[....] Not running dhcpcd because /etc/network/interfaces ... failed!
[....] defines some interfaces that will use a DHCP client ... failed!
[....] Shutting down ALSA...done.
[....] Asking all remaining processes to terminate...done.
[....] All processes ended within 1 seconds...done.
[....] Stopping enhanced syslogd: rsyslogd. ok
[....] Deconfiguring network interfaces...SIOCDELRT: No such process
Device "usb0" does not exist.
Cannot find device "usb0"
done.
[info] Saving the system clock.
[info] Hardware Clock updated to Mon Aug 8 21:19:30 UTC 2016.
[....] Unmounting temporary filesystems...done.
[....] Deactivating swap...done.
[....] Unmounting local filesystems...done.
[ 613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[info] Will now halt.
[ 615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 615.589721] Unable to handle kernel NULL pointer dereference at virtual address 00000a2a
[ 615.598249] pgd = ec3a4000
[ 615.601220] [00000a2a] *pgd=ab60f835, *pte=00000000, *ppte=00000000
[ 615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap snd_pcm_dmaengine [last unloaded: g_ether]
[ 615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: G B W 4.8.0-rc1-letux+ #655
[ 615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
[ 615.709052] task: eb2564c0 task.stack: ec456000
[ 615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
[ 615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
[ 615.727145] pc : [<bf4de050>] lr : [<bf40cf20>] psr: a00f0013
[ 615.727145] sp : ec457c48 ip : 00000000 fp : 400f0013
[ 615.739237] r10: ec414620 r9 : eb604b30 r8 : eb604c90
[ 615.744735] r7 : c0b02554 r6 : bf4815c4 r5 : bf4de03c r4 : ec823400
[ 615.751613] r3 : 00000000 r2 : 00000000 r1 : 000000c8 r0 : 000003e8
[ 615.758492] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 615.766008] Control: 10c5387d Table: ac3a406a DAC: 00000051
[ 615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
[ 615.778208] Stack: (0xec457c48 to 0xec458000)
[ 615.782806] 7c40: 00000001 00000000 bf40d540 c0a76630 eb604f3c bf40d540
[ 615.791434] 7c60: ec414620 00000000 00000000 eb604a8c eb604c90 00000000 00000001 eb604800
[ 615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 00000001 ec414b94 00000000 bf40d540
[ 615.808682] 7ca0: 00000000 00000003 ec457cb0 ec414b94 ec457cb8 bf40d75c eb604808 eb604808
[ 615.817308] 7cc0: 00000000 ec45a600 00000000 ec414620 ec45ac50 ec457d1e 000000c0 00000003
[ 615.825940] 7ce0: ffffffff bf4629e8 00000001 ec457d1e ec45a600 ec457d60 ec457d1e 00000001
[ 615.834563] 7d00: bf38707c bf386c94 00000003 bf4680cc ec457d1e 00000000 ec45a67c 00c00000
[ 615.843178] 7d20: 12000000 e6ce7dbf efbeadde 12000000 e6ce7dbf 00030000 00000001 ec892bd4
[ 615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 00000003 ffffffff bf352b58
[ 615.860428] 7d60: ec892bd4 00000000 00000000 00000003 ec45a648 ec45a608 ec414000 ec414000
[ 615.869051] 7d80: ec414000 ec45a000 00000003 bf3590c0 00000000 00000003 00000000 ec45a000
[ 615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 00000009 ec96cc0c 00000000
[ 615.886300] 7dc0: ffffffff bf31cba8 ec45a608 ec4142a0 ec45a000 bf31cd70 00000000 00000000
[ 615.894918] 7de0: c06d0594 c06da874 c0b98444 fffffff7 00000000 00000009 ec457e3c bf47bb38
[ 615.903540] 7e00: ec96cc0c 00000000 ffffffff c0152df8 ec45a000 ec457e58 00001042 00001003
[ 615.912162] 7e20: 00000000 c0152e40 00000000 00000009 ec457e3c c0620eb4 00000009 ec45a000
[ 615.920786] 7e40: c062b690 c0620fd0 ec45a04c ec45a000 00000001 c0621134 ec45a04c ec45a04c
[ 615.929410] 7e60: c062b690 c062b97c ec45a000 00001003 ec45a150 ec45a000 00000000 c062ba38
[ 615.938027] 7e80: ec8f7600 00000000 ec96cc00 ec45a000 00000000 c0697f8c 00000000 beabc47c
[ 615.946652] 7ea0: 00000020 00000000 6e616c77 00000030 00000000 00000000 00001042 8202a8c0
[ 615.955275] 7ec0: 00000000 00000000 00000000 00008914 ed5014a0 beabc47c c0b90c80 ed501480
[ 615.963900] 7ee0: 00000003 00000000 00000001 c0609a30 beabc47c ed5014a0 eb34b140 c026560c
[ 615.972524] 7f00: 00000003 c0264ac4 0000c000 c02654a4 600f0013 c135c654 c08a43f4 eb2dccb4
[ 615.981145] 7f20: ec456000 00000000 00000003 eb34b140 ec456000 00000000 00000001 c0271cd8
[ 615.989769] 7f40: 00000000 00000000 c0271a44 c0255308 c0b03bc0 00000000 ed501480 c0609684
[ 615.998389] 7f60: ed813710 00000000 eb34b140 eb34b140 beabc47c 00008914 00000003 00000000
[ 616.007012] 7f80: 00000001 c026560c 00001042 beabc47c 00000000 beabc49c 00000036 c0107204
[ 616.015636] 7fa0: ec456000 c0107060 beabc47c 00000000 00000003 00008914 beabc47c 00001042
[ 616.024253] 7fc0: beabc47c 00000000 beabc49c 00000036 000230f0 00023100 00000003 00000001
[ 616.032875] 7fe0: 00023054 beabc44c 0001135b b6e83206 a00f0030 00000003 00000000 00000000
[ 616.041894] [<bf4de050>] (wlcore_op_get_expected_throughput [wlcore]) from [<bf40cf20>] (sta_set_sinfo+0xc18/0x1110 [mac80211])
[ 616.054542] [<bf40cf20>] (sta_set_sinfo [mac80211]) from [<bf40d540>] (__sta_info_destroy_part2+0x128/0x194 [mac80211])
[ 616.066426] [<bf40d540>] (__sta_info_destroy_part2 [mac80211]) from [<bf40d75c>] (__sta_info_flush+0xf8/0x13c [mac80211])
[ 616.078513] [<bf40d75c>] (__sta_info_flush [mac80211]) from [<bf4629e8>] (ieee80211_set_disassoc+0x168/0x2f8 [mac80211])
[ 616.090512] [<bf4629e8>] (ieee80211_set_disassoc [mac80211]) from [<bf4680cc>] (ieee80211_mgd_deauth+0x3dc/0x9fc [mac80211])
[ 616.102861] [<bf4680cc>] (ieee80211_mgd_deauth [mac80211]) from [<bf352b58>] (cfg80211_mlme_deauth+0x1f4/0x458 [cfg80211])
[ 616.114978] [<bf352b58>] (cfg80211_mlme_deauth [cfg80211]) from [<bf3590c0>] (cfg80211_disconnect+0xa0/0x4a4 [cfg80211])
[ 616.126880] [<bf3590c0>] (cfg80211_disconnect [cfg80211]) from [<bf31cba8>] (cfg80211_leave+0x28/0x34 [cfg80211])
[ 616.138137] [<bf31cba8>] (cfg80211_leave [cfg80211]) from [<bf31cd70>] (cfg80211_netdev_notifier_call+0x1bc/0x84c [cfg80211])
[ 616.150287] [<bf31cd70>] (cfg80211_netdev_notifier_call [cfg80211]) from [<c0152df8>] (notifier_call_chain+0x40/0x68)
[ 616.161479] [<c0152df8>] (notifier_call_chain) from [<c0152e40>] (raw_notifier_call_chain+0x14/0x1c)
[ 616.171111] [<c0152e40>] (raw_notifier_call_chain) from [<c0620eb4>] (call_netdevice_notifiers+0xc/0x14)
[ 616.181108] [<c0620eb4>] (call_netdevice_notifiers) from [<c0620fd0>] (__dev_close_many+0x48/0xb8)
[ 616.190551] [<c0620fd0>] (__dev_close_many) from [<c0621134>] (__dev_close+0x20/0x34)
[ 616.198806] [<c0621134>] (__dev_close) from [<c062b97c>] (__dev_change_flags+0x8c/0x130)
[ 616.207347] [<c062b97c>] (__dev_change_flags) from [<c062ba38>] (dev_change_flags+0x18/0x48)
[ 616.216255] [<c062ba38>] (dev_change_flags) from [<c0697f8c>] (devinet_ioctl+0x338/0x704)
[ 616.224883] [<c0697f8c>] (devinet_ioctl) from [<c0609a30>] (sock_ioctl+0x288/0x2d8)
[ 616.232959] [<c0609a30>] (sock_ioctl) from [<c0264ac4>] (vfs_ioctl+0x20/0x34)
[ 616.240482] [<c0264ac4>] (vfs_ioctl) from [<c02654a4>] (do_vfs_ioctl+0x854/0x970)
[ 616.248369] [<c02654a4>] (do_vfs_ioctl) from [<c026560c>] (SyS_ioctl+0x4c/0x74)
[ 616.256078] [<c026560c>] (SyS_ioctl) from [<c0107060>] (ret_fast_syscall+0x0/0x1c)
[ 616.264075] Code: e3a010c8 e5d02098 e3a00ffa e0233291 (e5d33a2a)
[ 616.272268] ---[ end trace 00ab29170ed628ed ]---
Segmentation fault
[....] startpar: service(s) skipped, program is not configured: dhcpcd ... (warning).
INIT: no more processes left in this runlevel
^ permalink raw reply
* Re: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: Arnd Bergmann @ 2016-08-08 20:49 UTC (permalink / raw)
To: David Laight
Cc: linuxppc-dev@lists.ozlabs.org, 'Arvind Yadav',
zajec5@gmail.com, leoli@freescale.com, qiang.zhao@freescale.com,
viresh.kumar@linaro.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, scottwood@freescale.com,
akpm@linux-foundation.org, linux@roeck-us.net
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F50C532@AcuExch.aculab.com>
On Monday, August 8, 2016 3:49:22 PM CEST David Laight wrote:
> From: Arnd Bergmann
> > Sent: 08 August 2016 16:13
> >
> > On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
> > >
> > > > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > > > return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> > > > will be a dead code on 64bit. Even qe_muram_addr will return wrong
> > > > virtual address. Which can cause an error.
> > > >
> > > > kfree((void *)ugeth->tx_bd_ring_offset[i]);
> > >
> > > Erm, kfree() isn't the right function for things allocated by qe_muram_alloc().
> > >
> > > I still thing you need to stop this code using IS_ERR_VALUE() at all.
> >
> > Those are two separate issues:
> >
> > a) The ucc_geth driver mixing kmalloc() memory with muram, and assigning
> > the result to "u32" and "void __iomem *" variables, both of which
> > are wrong at least half of the time.
> >
> > b) calling conventions of qe_muram_alloc() being defined in a way that
> > requires the use of IS_ERR_VALUE(), because '0' is a valid address
> > here.
>
> Yep, it is all a big bag of worms...
> '0' being valid is going to make tidying up after failure 'problematic'.
>
> > The first one can be solved by updating the network driver, ideally
> > by getting rid of the casts and using proper types and accessors,
> > while the second would require updating all users of that interface.
>
> It might be worth (at least as a compilation option) of embedding the
> 'muram offset' in a structure (passed and returned by value).
>
> The compiler can then check that the driver code is never be looking
> directly at the value.
>
> For 'b' zero can be made invalid by changing the places where the
> offset is added/subtracted.
> It could even be used to offset the saved physical and virtual
> addresses of the area - so not needing any extra code when the values
> are converted to physical/virtual addresses.
Agreed.
For this driver, we don't actually seem to use the value returned from
the allocation function, only the virtual __iomem address we get after
calling qe_muram_addr(), so it would be a big improvement to just
store the virtual address as a pointer, and wrap the calls
to qe_muram_alloc/qe_muram_addr/qe_muram_free with an appropriate
helper that doesn't even show the offset.
However, I'd also separate the normal kmalloc pointer from the
muram_alloc() pointer because only the latter is __iomem, and
we shouldn't really call MMIO accessor functions on RAM in
portable code.
Arnd
^ permalink raw reply
* RE: [PATCH v4] cfg80211: Provision to allow the support for different beacon intervals
From: Undekari, Sunil Dutt @ 2016-08-08 17:58 UTC (permalink / raw)
To: Johannes Berg, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Kondabattini, Ganesh, Kalikot Veetil, Mahesh Kumar,
Hullur Subramanyam, Amarnath, Kumar, Deepak (QCA)
In-Reply-To: <1470386912.2977.28.camel@sipsolutions.net>
PldoYXQgaWYgeW91IGhhdmUgQVAsR08sbWVzaCBpbiB0aGUgc2FtZSBpbnRlcmZhY2UgY29tYmlu
YXRpb24/IEVpdGhlciB5b3VyIGRvY3VtZW50YXRpb24gbmVlZHMgdG8gdmVyeSB2ZXJ5IGNsZWFy
bHkgc3RhdGUgdGhhdCB0aGUgbWVzaCBtdXN0IG1hdGNoIChlaXRoZXIgb25lIG9mIHRoZW0/KSBh
bmQgSSdkIGdvIGFzIGZhciBhcyA+cmVuYW1pbmcgdGhlIEFQSXMsIG9yIHlvdSBzaG91bGRuJ3Qg
cmVxdWlyZSBtdWx0aXBsZSBBUHMgYW5kIG1ha2UgdGhpcyBhcHBseSBvbiBtZXNoIGFuZCBJQlNT
IGFzIHdlbGwuDQpJIGd1ZXNzICwgd2UgY2FuIGV4dGVuZCB0aGlzIHRvIG1lc2ggYW5kIElCU1Mg
YXMgd2VsbC4gDQoNCj5JdCBzZWVtcyB0byBtZSB0aGF0IGlmIEkgd2VyZSB0byBzcGVjaWZ5IGJl
YWNvbiBpbnRlcnZhbHMgd2hpY2ggaGF2ZSBhIHZlcnkgc21hbGwgR0NELCB5b3UnbGwgcnVuIGlu
dG8gdHJvdWJsZSB3aGVuIGFjdHVhbGx5IHNlbmRpbmcgYmVhY29ucy4NCj5QZXJoYXBzIHRoZXJl
IHNob3VsZCBiZSBhIHJlcXVpcmVtZW50IG9uIHRoZSBHQ0Q/DQpDYW4gd2UgaGF2ZSB0aGlzIHB1
Ymxpc2hlZCBieSB0aGUgaG9zdCBkcml2ZXJzIHRocm91Z2ggYSBuZXcgd2lwaHkgcGFyYW1ldGVy
ICwgc2F5ICJtaW5fZGlmZl9iZWFjb25faW50ZXJ2YWxfbXVsdGlwbGllciIuIFRoaXMgc2V0J3Mg
dGhlIGV4cGVjdGF0aW9uIHRoYXQgYW55IGRpZmZlcmVudCBiZWFjb24gaW50ZXJ2YWxzIG9uIHRo
ZSB3aXBoeSAgc2hhbGwgYmUgYSBtdWx0aXBsZSBvZiB0aGlzIHBhcmFtZXRlciB3aGljaCBpcyBh
ZHZlcnRpc2VkIGJ5IHRoZSBob3N0IGRyaXZlciAsIGlzbid0ID8NCg0KUmVnYXJkcywNClN1bmls
DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaGFubmVzIEJlcmcgW21h
aWx0bzpqb2hhbm5lc0BzaXBzb2x1dGlvbnMubmV0XSANClNlbnQ6IEZyaWRheSwgQXVndXN0IDUs
IDIwMTYgMjoxOSBQTQ0KVG86IEt1c2h3YWhhLCBQdXJ1c2hvdHRhbSA8cGt1c2h3YWhAcXRpLnF1
YWxjb21tLmNvbT4NCkNjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE1hbGluZW4s
IEpvdW5pIDxqb3VuaUBxY2EucXVhbGNvbW0uY29tPjsgVW5kZWthcmksIFN1bmlsIER1dHQgPHVz
ZHV0dEBxdGkucXVhbGNvbW0uY29tPjsgS29uZGFiYXR0aW5pLCBHYW5lc2ggPGdhbmVzaGtAcXRp
LnF1YWxjb21tLmNvbT47IEthbGlrb3QgVmVldGlsLCBNYWhlc2ggS3VtYXIgPG1rYWxpa290QHFj
YS5xdWFsY29tbS5jb20+OyBIdWxsdXIgU3VicmFtYW55YW0sIEFtYXJuYXRoIDxhbWFybmF0aEBx
Y2EucXVhbGNvbW0uY29tPg0KU3ViamVjdDogUmU6IFtQQVRDSCB2NF0gY2ZnODAyMTE6IFByb3Zp
c2lvbiB0byBhbGxvdyB0aGUgc3VwcG9ydCBmb3IgZGlmZmVyZW50IGJlYWNvbiBpbnRlcnZhbHMN
Cg0KT24gRnJpLCAyMDE2LTA4LTA1IGF0IDEwOjU2ICswNTMwLCBQdXJ1c2hvdHRhbSBLdXNod2Fo
YSB3cm90ZToNCj4gVGhpcyBjb21taXQgcHJvdmlkZXMgdGhlIG9wdGlvbiBmb3IgdGhlIGhvc3Qg
ZHJpdmVycyB0byBhZHZlcnRpc2UgdGhlIA0KPiBzdXBwb3J0IGZvciBkaWZmZXJlbnQgYmVhY29u
IGludGVydmFscyBhbW9uZyB0aGUgcmVzcGVjdGl2ZSBpbnRlcmZhY2UgDQo+IGNvbWJpbmF0aW9u
cywgdGhyb3VnaCBzdXBwX2RpZmZfYmVhY29uX2ludCAoYm9vbCkuDQoNCk5laXRoZXIgeW91ciBj
b21taXQgbWVzc2FnZSBub3IgdGhlIGRvY3VtZW50YXRpb24gbWFrZXMgYSBkaXJlY3QgcmVmZXJl
bmNlIHRvIHRoaXMgYWZmZWN0aW5nIG9ubHkgQVAvR08gaW50ZXJmYWNlLiBIb3dldmVyLCB5b3Ug
dGhlbiBnbyBhbmQgcmVxdWlyZSB0aGF0IGF0IGxlYXN0IDIgaW50ZXJmYWNlcyB3aXRoIEFQL0dP
IGFyZSBwcmVzZW50Lg0KDQpXaGF0IGlmIHlvdSBoYXZlIEFQLEdPLG1lc2ggaW4gdGhlIHNhbWUg
aW50ZXJmYWNlIGNvbWJpbmF0aW9uPyBFaXRoZXIgeW91ciBkb2N1bWVudGF0aW9uIG5lZWRzIHRv
IHZlcnkgdmVyeSBjbGVhcmx5IHN0YXRlIHRoYXQgdGhlIG1lc2ggbXVzdCBtYXRjaCAoZWl0aGVy
IG9uZSBvZiB0aGVtPykgYW5kIEknZCBnbyBhcyBmYXIgYXMgcmVuYW1pbmcgdGhlIEFQSXMsIG9y
IHlvdSBzaG91bGRuJ3QgcmVxdWlyZSBtdWx0aXBsZSBBUHMgYW5kIG1ha2UgdGhpcyBhcHBseSBv
biBtZXNoIGFuZCBJQlNTIGFzIHdlbGwuDQoNCkFyZSB0aGVyZSByZWFsbHkgbm8gcmVzdHJpY3Rp
b25zIHdoYXRzb2V2ZXIsIGJ0dz8NCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBpZiBJIHdlcmUgdG8g
c3BlY2lmeSBiZWFjb24gaW50ZXJ2YWxzIHdoaWNoIGhhdmUgYSB2ZXJ5IHNtYWxsIEdDRCwgeW91
J2xsIHJ1biBpbnRvIHRyb3VibGUgd2hlbiBhY3R1YWxseSBzZW5kaW5nIGJlYWNvbnMuDQpQZXJo
YXBzIHRoZXJlIHNob3VsZCBiZSBhIHJlcXVpcmVtZW50IG9uIHRoZSBHQ0Q/DQoNCmpvaGFubmVz
DQo=
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-08 17:29 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Ted Tso, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo
In-Reply-To: <1830987.VF9l4XmGxv@tauon.atsec.com>
Hi Stephan, Miaoqing Pan,
On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert, the analysis report show the
> > ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> > value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> > so that's why set entropy quality to 320/1024 = 10/32.
Ok, so the relevant commit is:
ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture
Which refers to a previous commit:
6301566e0b2d ath9k: export HW random number generator
> > Also we have explained in the commit message why can't use the HW
> > RNG framework.
>From ed14dc0af7cce:
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to
bind it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?
> >
> > Otherwise, your patch will cause high CPU load, as continuously read ADC
> > data if entropy bits under write_wakeup_threshold.
>
> The issue is that although you may have analyzed it, others are unable to
> measure the quality of the RNG and assess the design as well as the
> implementation of the RNG. This RNG is the only implementation of a hardware
> RNG that per default and without being able to change it at runtime injects
> data into the input_pool where the noise source cannot be audited. Note, even
> other respected RNG noise sources like the Intel RDRAND will not feed into /
> dev/random per default in a way that dominates all other noise sources.
>
> I would like to be able to deactivate that noise source to the extent that it
> does not cause /dev/random to unblock. The reason is that your noise source
> starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card
(HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing
out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts to
> spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng
framework. Interrupt timings were never designed to be a source of entropy
either. We need to grab it where ever we can find it, especially on
embedded systems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of
sources under char/hw_random/. I think the only thing we would be
concerned about, other than the already addressed entropy estimation,
would be constraining the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about
sound cards?
thx,
Jason.
^ permalink raw reply
* mac80211: AP changed bandwidth in a way we can't support - disconnect
From: Kevin O'Connor @ 2016-08-08 16:58 UTC (permalink / raw)
To: linux-wireless
Hi,
I am getting periodic wifi disconnects. The logs show the following
messages when I receive the disconnect:
Sun Aug 7 16:12:59 2016 kern.info kernel: [321982.209148] wlan0: AP ... changed bandwidth, new config is 5500 MHz, width 1 (5500/0 MHz)
Sun Aug 7 16:12:59 2016 kern.info kernel: [321982.218868] wlan0: AP ... changed bandwidth in a way we can't support - disconnect
After the above messages, the connection immediately reconnects. It
will typically stay up for a few hours and then go through the cycle
again.
The client (which I control) is a tp-link archer c7 router running
openwrt (ath10k, QCA9880-BR4A, linux v4.1.23, mac80211.ko from
compat-wireless-2016-01-10). The AP (which I do not have admin access
to) appears to be a "Ruckus Wireless ZoneFlex 802.11ac wave 2 4x4
access point"
To try and debug this, I altered the mac80211 code to display some
additional debugging data and to not force a disconnect (see debugging
patch below). With the altered code the client now stays connected.
I occasionally see periodic debugging messages like the following:
Sun Aug 7 17:52:54 2016 kern.info kernel: [327977.219622] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0
Sun Aug 7 17:53:02 2016 kern.info kernel: [327985.206823] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0
And then every few hours I'll get:
Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.076091] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 1 (5500/0 MHz) 1024
Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.086633] wlan0: AP ... changed bandwidth, new config is 5500 MHz, width 1 (5500/0 MHz)
Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.096362] wlan0: AP ... changed bandwidth in a way we can't support 1024 132 1 - ignore
Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.383324] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0
The above message sequence would have forced a disconnect in the past.
The "width 3" message always immediately follows the "width 1"
messages.
If I'm interpreting the sequence correctly, the AP and client
initially negotiate an 80mhz connection and then at some point the AP
requests a 20mhz connection that is immediately followed by an 80mhz
request.
What is the best way to proceed with this error? I no longer have the
disconnect issue with the debugging patch (which ignores the
unsupported request instead of disconnecting), but it would be good to
get a real fix upstream.
Thanks. I'm not subscribed to the linux-wireless mailing list, so
please CC me on replies.
-Kevin
Debugging patch:
--- mlme.c~ 2016-06-30 14:51:00.999254180 -0400
+++ mlme.c 2016-08-03 18:31:08.938869667 -0400
@@ -345,6 +345,10 @@
ht_cap, ht_oper, vht_oper,
&chandef, true);
+ sdata_info(sdata,
+ "AP %pM changed bandwidth, orig new config is %d MHz, width %d (%d/%d MHz) %d\n",
+ ifmgd->bssid, chandef.chan->center_freq, chandef.width,
+ chandef.center_freq1, chandef.center_freq2, flags);
/*
* Downgrade the new channel if we associated with restricted
* capabilities. For example, if we associated as a 20 MHz STA
@@ -377,9 +381,9 @@
IEEE80211_STA_DISABLE_160MHZ)) ||
!cfg80211_chandef_valid(&chandef)) {
sdata_info(sdata,
- "AP %pM changed bandwidth in a way we can't support - disconnect\n",
- ifmgd->bssid);
- return -EINVAL;
+ "AP %pM changed bandwidth in a way we can't support %d %d %d - ignore\n",
+ ifmgd->bssid, flags, ifmgd->flags, cfg80211_chandef_valid(&chandef));
+ return 0;
}
switch (chandef.width) {
^ permalink raw reply
* RE: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: David Laight @ 2016-08-08 15:49 UTC (permalink / raw)
To: 'Arnd Bergmann', linuxppc-dev@lists.ozlabs.org
Cc: 'Arvind Yadav', zajec5@gmail.com, leoli@freescale.com,
qiang.zhao@freescale.com, viresh.kumar@linaro.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
scottwood@freescale.com, akpm@linux-foundation.org,
linux@roeck-us.net
In-Reply-To: <2862487.guU7g5Qkfj@wuerfel>
From: Arnd Bergmann
> Sent: 08 August 2016 16:13
>
> On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
> >
> > > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > > return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> > > will be a dead code on 64bit. Even qe_muram_addr will return wrong
> > > virtual address. Which can cause an error.
> > >
> > > kfree((void *)ugeth->tx_bd_ring_offset[i]);
> >
> > Erm, kfree() isn't the right function for things allocated by qe_muram_alloc().
> >
> > I still thing you need to stop this code using IS_ERR_VALUE() at all.
>
> Those are two separate issues:
>
> a) The ucc_geth driver mixing kmalloc() memory with muram, and assigning
> the result to "u32" and "void __iomem *" variables, both of which
> are wrong at least half of the time.
>
> b) calling conventions of qe_muram_alloc() being defined in a way that
> requires the use of IS_ERR_VALUE(), because '0' is a valid address
> here.
Yep, it is all a big bag of worms...
'0' being valid is going to make tidying up after failure 'problematic'.
> The first one can be solved by updating the network driver, ideally
> by getting rid of the casts and using proper types and accessors,
> while the second would require updating all users of that interface.
It might be worth (at least as a compilation option) of embedding the
'muram offset' in a structure (passed and returned by value).
The compiler can then check that the driver code is never be looking
directly at the value.
For 'b' zero can be made invalid by changing the places where the
offset is added/subtracted.
It could even be used to offset the saved physical and virtual
addresses of the area - so not needing any extra code when the values
are converted to physical/virtual addresses.
David
^ permalink raw reply
* [v5.1] ucc_fast: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: Arvind Yadav @ 2016-08-04 16:52 UTC (permalink / raw)
To: zajec5, leoli
Cc: qiang.zhao, scottwood, viresh.kumar, akpm, linux-wireless, netdev,
linuxppc-dev, linux, arnd, Arvind Yadav
IS_ERR_VALUE() assumes that parameter is an unsigned long.
It can not be used to check if 'unsigned int' is passed insted.
Which tends to reflect an error.
In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
value is zero extended to 64 bits.
Now Problem In UCC fast protocols -: drivers/soc/fsl/qe/ucc_fast.c
/* Allocate memory for Tx Virtual Fifo */
uccf->ucc_fast_tx_virtual_fifo_base_offset =
qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
__func__);
uccf->ucc_fast_tx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
}
/* Allocate memory for Rx Virtual Fifo */
uccf->ucc_fast_rx_virtual_fifo_base_offset =
qe_muram_alloc(uf_info->urfs +
UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for RX FIFO\n",
__func__);
uccf->ucc_fast_rx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
}
qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.
Return value store in a u32 (ucc_fast_tx_virtual_fifo_base_offset
and ucc_fast_rx_virtual_fifo_base_offset).If qe_muram_alloc will
return any error, Then IS_ERR_VALUE will always return 0. it'll not
call ucc_fast_free for any failure. Inside 'if code' will be a dead
code on 64bit.
This patch is to avoid this problem on 64bit machine.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
include/soc/fsl/qe/ucc_fast.h | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/soc/fsl/qe/ucc_fast.h b/include/soc/fsl/qe/ucc_fast.h
index df8ea79..ada9070 100644
--- a/include/soc/fsl/qe/ucc_fast.h
+++ b/include/soc/fsl/qe/ucc_fast.h
@@ -165,10 +165,12 @@ struct ucc_fast_private {
int stopped_tx; /* Whether channel has been stopped for Tx
(STOP_TX, etc.) */
int stopped_rx; /* Whether channel has been stopped for Rx */
- u32 ucc_fast_tx_virtual_fifo_base_offset;/* pointer to base of Tx
- virtual fifo */
- u32 ucc_fast_rx_virtual_fifo_base_offset;/* pointer to base of Rx
- virtual fifo */
+ unsigned long ucc_fast_tx_virtual_fifo_base_offset;/* pointer to base of
+ * Tx virtual fifo
+ */
+ unsigned long ucc_fast_rx_virtual_fifo_base_offset;/* pointer to base of
+ * Rx virtual fifo
+ */
#ifdef STATISTICS
u32 tx_frames; /* Transmitted frames counter. */
u32 rx_frames; /* Received frames counter (only frames
--
1.9.1
^ permalink raw reply related
* Re: Buggy rhashtable walking
From: Herbert Xu @ 2016-08-08 15:26 UTC (permalink / raw)
To: Ben Greear
Cc: Johannes Berg, David S. Miller, netdev, linux-wireless,
Thomas Graf, tom
In-Reply-To: <57A47CA3.4010101@candelatech.com>
On Fri, Aug 05, 2016 at 04:46:43AM -0700, Ben Greear wrote:
>
> It would not be fun to have to revert to the old way of hashing
> stations in mac80211...
>
> I'll be happy to test the patches when you have them ready.
Thanks for the offer. Unfortunately it'll be a few days before
I'm ready because I need to work through some crypto patches first.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: Arnd Bergmann @ 2016-08-08 15:13 UTC (permalink / raw)
To: linuxppc-dev
Cc: David Laight, 'Arvind Yadav', zajec5@gmail.com,
leoli@freescale.com, qiang.zhao@freescale.com,
viresh.kumar@linaro.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, scottwood@freescale.com,
akpm@linux-foundation.org, linux@roeck-us.net
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F50C493@AcuExch.aculab.com>
On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
>
> > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> > will be a dead code on 64bit. Even qe_muram_addr will return wrong
> > virtual address. Which can cause an error.
> >
> > kfree((void *)ugeth->tx_bd_ring_offset[i]);
>
> Erm, kfree() isn't the right function for things allocated by qe_muram_alloc().
>
> I still thing you need to stop this code using IS_ERR_VALUE() at all.
Those are two separate issues:
a) The ucc_geth driver mixing kmalloc() memory with muram, and assigning
the result to "u32" and "void __iomem *" variables, both of which
are wrong at least half of the time.
b) calling conventions of qe_muram_alloc() being defined in a way that
requires the use of IS_ERR_VALUE(), because '0' is a valid address
here.
The first one can be solved by updating the network driver, ideally
by getting rid of the casts and using proper types and accessors,
while the second would require updating all users of that interface.
Arnd
^ permalink raw reply
* RE: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: David Laight @ 2016-08-08 14:49 UTC (permalink / raw)
To: 'Arvind Yadav', zajec5@gmail.com, leoli@freescale.com
Cc: qiang.zhao@freescale.com, scottwood@freescale.com,
viresh.kumar@linaro.org, akpm@linux-foundation.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux@roeck-us.net, arnd@arndb.de
In-Reply-To: <1470386442-7208-1-git-send-email-arvind.yadav.cs@gmail.com>
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Arvind Yadav
> IS_ERR_VALUE() assumes that parameter is an unsigned long.
> It can not be used to check if 'unsigned int' is passed insted.
> Which tends to reflect an error.
> In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
> IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
> IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
> value is zero extended to 64 bits.
You are being far too wordy above, and definitely below.
>
> Now problem in Freescale QEGigabit Ethernet-:
> drivers/net/ethernet/freescale/ucc_geth.c
>
...
> qe_muram_addr(init_enet_pram_offset);
>
> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.
> Return value store in a u32 (init_enet_offset, exf_glbl_param_offset,
> rx_glbl_pram_offset, tx_glbl_pram_offset, send_q_mem_reg_offset,
> thread_dat_tx_offset, thread_dat_rx_offset, scheduler_offset,
> tx_fw_statistics_pram_offset, rx_fw_statistics_pram_offset,
> rx_irq_coalescing_tbl_offset, rx_bd_qs_tbl_offset, tx_bd_ring_offset,
> init_enet_pram_offset and rx_bd_ring_offset).
Inpenetrable...
> If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> will be a dead code on 64bit. Even qe_muram_addr will return wrong
> virtual address. Which can cause an error.
>
> kfree((void *)ugeth->tx_bd_ring_offset[i]);
Erm, kfree() isn't the right function for things allocated by qe_muram_alloc().
I still thing you need to stop this code using IS_ERR_VALUE() at all.
David
^ permalink raw reply
* [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.
From: Arvind Yadav @ 2016-08-05 8:40 UTC (permalink / raw)
To: zajec5, leoli
Cc: qiang.zhao, scottwood, viresh.kumar, akpm, linux-wireless, netdev,
linuxppc-dev, linux, arnd, Arvind Yadav
IS_ERR_VALUE() assumes that parameter is an unsigned long.
It can not be used to check if 'unsigned int' is passed insted.
Which tends to reflect an error.
In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
value is zero extended to 64 bits.
Now problem in Freescale QEGigabit Ethernet-:
drivers/net/ethernet/freescale/ucc_geth.c
init_enet_offset =
qe_muram_alloc(thread_size, thread_alignment);
if (IS_ERR_VALUE(init_enet_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory\n");
qe_put_snum((u8) snum);
return -ENOMEM;
}
ugeth->tx_bd_ring_offset[j] =
qe_muram_alloc(length,
UCC_GETH_TX_BD_RING_ALIGNMENT);
if (!IS_ERR_VALUE(ugeth->tx_bd_ring_offset[j]))
ugeth->p_tx_bd_ring[j] = (u8 __iomem *) qe_muram_addr(ugeth->
tx_bd_ring_offset[j]);
ugeth->rx_bd_ring_offset[j] =
qe_muram_alloc(length,
UCC_GETH_RX_BD_RING_ALIGNMENT);
if (!IS_ERR_VALUE(ugeth->rx_bd_ring_offset[j]))
ugeth->p_rx_bd_ring[j] =
(u8 __iomem *) qe_muram_addr(ugeth->
rx_bd_ring_offset[j]);
/* Allocate global tx parameter RAM page */
ugeth->tx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
UCC_GETH_TX_GLOBAL_PRAM_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->tx_glbl_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_tx_glbl_pram\n");
return -ENOMEM;
}
/* Size varies with number of Tx threads */
ugeth->thread_dat_tx_offset =
qe_muram_alloc(numThreadsTxNumerical *
sizeof(struct ucc_geth_thread_data_tx) +
32 * (numThreadsTxNumerical == 1),
UCC_GETH_THREAD_DATA_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->thread_dat_tx_offset)) {
if (netif_msg_ifup(ugeth))
pr_err
("Can not allocate DPRAM memory for p_thread_data_tx\n");
return -ENOMEM;
}
/* Size varies with number of Tx queues */
ugeth->send_q_mem_reg_offset =
qe_muram_alloc(ug_info->numQueuesTx *
sizeof(struct ucc_geth_send_queue_qd),
UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->send_q_mem_reg_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_send_q_mem_reg\n");
return -ENOMEM;
}
ugeth->scheduler_offset =
qe_muram_alloc(sizeof(struct ucc_geth_scheduler),
UCC_GETH_SCHEDULER_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->scheduler_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_scheduler\n");
return -ENOMEM;
}
ugeth->tx_fw_statistics_pram_offset =
qe_muram_alloc(sizeof
(struct ucc_geth_tx_firmware_statistics_pram),
UCC_GETH_TX_STATISTICS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->tx_fw_statistics_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_tx_fw_statistics_pram\n");
return -ENOMEM;
}
/* Allocate global rx parameter RAM page */
ugeth->rx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_rx_global_pram),
UCC_GETH_RX_GLOBAL_PRAM_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_glbl_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_rx_glbl_pram\n");
return -ENOMEM;
}
/* Size varies with number of Rx threads */
ugeth->thread_dat_rx_offset =
qe_muram_alloc(numThreadsRxNumerical *
sizeof(struct ucc_geth_thread_data_rx),
UCC_GETH_THREAD_DATA_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->thread_dat_rx_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_thread_data_rx\n");
return -ENOMEM;
}
ugeth->rx_fw_statistics_pram_offset =
qe_muram_alloc(sizeof
(struct ucc_geth_rx_firmware_statistics_pram),
UCC_GETH_RX_STATISTICS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_fw_statistics_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_rx_fw_statistics_pram\n");
return -ENOMEM;
}
/* Size varies with number of Rx queues */
ugeth->rx_irq_coalescing_tbl_offset =
qe_muram_alloc(ug_info->numQueuesRx *
sizeof(struct ucc_geth_rx_interrupt_coalescing_entry)
+ 4, UCC_GETH_RX_INTERRUPT_COALESCING_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_irq_coalescing_tbl_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_rx_irq_coalescing_tbl\n");
return -ENOMEM;
}
/* Size varies with number of Rx queues */
ugeth->rx_bd_qs_tbl_offset =
qe_muram_alloc(ug_info->numQueuesRx *
(sizeof(struct ucc_geth_rx_bd_queues_entry) +
sizeof(struct ucc_geth_rx_prefetched_bds)),
UCC_GETH_RX_BD_QUEUES_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_bd_qs_tbl_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_rx_bd_qs_tbl\n");
return -ENOMEM;
}
ugeth->exf_glbl_param_offset =
qe_muram_alloc(sizeof(struct ucc_geth_exf_global_pram),
UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->exf_glbl_param_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_exf_glbl_param\n");
return -ENOMEM;
}
/* Allocate InitEnet command parameter structure */
init_enet_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_init_pram), 4);
if (IS_ERR_VALUE(init_enet_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err(
"Can not allocate DPRAM memory for p_init_enet_pram\n");
return -ENOMEM;
}
p_init_enet_pram =
(struct ucc_geth_init_pram __iomem *)
qe_muram_addr(init_enet_pram_offset);
qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.
Return value store in a u32 (init_enet_offset, exf_glbl_param_offset,
rx_glbl_pram_offset, tx_glbl_pram_offset, send_q_mem_reg_offset,
thread_dat_tx_offset, thread_dat_rx_offset, scheduler_offset,
tx_fw_statistics_pram_offset, rx_fw_statistics_pram_offset,
rx_irq_coalescing_tbl_offset, rx_bd_qs_tbl_offset, tx_bd_ring_offset,
init_enet_pram_offset and rx_bd_ring_offset).
If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
will be a dead code on 64bit. Even qe_muram_addr will return wrong
virtual address. Which can cause an error.
kfree((void *)ugeth->tx_bd_ring_offset[i]);
which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
that also holds the return value of qe_muram_alloc.
This patch is to avoid these problem on 64bit machine.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 7 ++++---
drivers/net/ethernet/freescale/ucc_geth.h | 26 +++++++++++++-------------
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 5bf1ade..eb1f4e2 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -273,7 +273,7 @@ static int fill_init_enet_entries(struct ucc_geth_private *ugeth,
unsigned int risc,
int skip_page_for_first_entry)
{
- u32 init_enet_offset;
+ unsigned long init_enet_offset;
u8 i;
int snum;
@@ -1871,7 +1871,7 @@ static void ucc_geth_free_rx(struct ucc_geth_private *ugeth)
if (ugeth->ug_info->uf_info.bd_mem_part ==
MEM_PART_SYSTEM)
- kfree((void *)ugeth->rx_bd_ring_offset[i]);
+ kfree(ugeth->rx_bd_ring_offset[i]);
else if (ugeth->ug_info->uf_info.bd_mem_part ==
MEM_PART_MURAM)
qe_muram_free(ugeth->rx_bd_ring_offset[i]);
@@ -2367,7 +2367,8 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
struct ucc_geth __iomem *ug_regs;
int ret_val = -EINVAL;
u32 remoder = UCC_GETH_REMODER_INIT;
- u32 init_enet_pram_offset, cecr_subblock, command;
+ unsigned long init_enet_pram_offset;
+ u32 cecr_subblock, command;
u32 ifstat, i, j, size, l2qt, l3qt;
u16 temoder = UCC_GETH_TEMODER_INIT;
u16 test;
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
index 5da19b4..1639ffd 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -1162,31 +1162,31 @@ struct ucc_geth_private {
struct ucc_geth __iomem *ug_regs;
struct ucc_geth_init_pram *p_init_enet_param_shadow;
struct ucc_geth_exf_global_pram __iomem *p_exf_glbl_param;
- u32 exf_glbl_param_offset;
+ unsigned long exf_glbl_param_offset;
struct ucc_geth_rx_global_pram __iomem *p_rx_glbl_pram;
- u32 rx_glbl_pram_offset;
+ unsigned long rx_glbl_pram_offset;
struct ucc_geth_tx_global_pram __iomem *p_tx_glbl_pram;
- u32 tx_glbl_pram_offset;
+ unsigned long tx_glbl_pram_offset;
struct ucc_geth_send_queue_mem_region __iomem *p_send_q_mem_reg;
- u32 send_q_mem_reg_offset;
+ unsigned long send_q_mem_reg_offset;
struct ucc_geth_thread_data_tx __iomem *p_thread_data_tx;
- u32 thread_dat_tx_offset;
+ unsigned long thread_dat_tx_offset;
struct ucc_geth_thread_data_rx __iomem *p_thread_data_rx;
- u32 thread_dat_rx_offset;
+ unsigned long thread_dat_rx_offset;
struct ucc_geth_scheduler __iomem *p_scheduler;
- u32 scheduler_offset;
+ unsigned long scheduler_offset;
struct ucc_geth_tx_firmware_statistics_pram __iomem *p_tx_fw_statistics_pram;
- u32 tx_fw_statistics_pram_offset;
+ unsigned long tx_fw_statistics_pram_offset;
struct ucc_geth_rx_firmware_statistics_pram __iomem *p_rx_fw_statistics_pram;
- u32 rx_fw_statistics_pram_offset;
+ unsigned long rx_fw_statistics_pram_offset;
struct ucc_geth_rx_interrupt_coalescing_table __iomem *p_rx_irq_coalescing_tbl;
- u32 rx_irq_coalescing_tbl_offset;
+ unsigned long rx_irq_coalescing_tbl_offset;
struct ucc_geth_rx_bd_queues_entry __iomem *p_rx_bd_qs_tbl;
- u32 rx_bd_qs_tbl_offset;
+ unsigned long rx_bd_qs_tbl_offset;
u8 __iomem *p_tx_bd_ring[NUM_TX_QUEUES];
- u32 tx_bd_ring_offset[NUM_TX_QUEUES];
+ unsigned long tx_bd_ring_offset[NUM_TX_QUEUES];
u8 __iomem *p_rx_bd_ring[NUM_RX_QUEUES];
- u32 rx_bd_ring_offset[NUM_RX_QUEUES];
+ unsigned long rx_bd_ring_offset[NUM_RX_QUEUES];
u8 __iomem *confBd[NUM_TX_QUEUES];
u8 __iomem *txBd[NUM_TX_QUEUES];
u8 __iomem *rxBd[NUM_RX_QUEUES];
--
1.9.1
^ permalink raw reply related
* wireless-testing on 4.8-rc1
From: Bob Copeland @ 2016-08-08 13:04 UTC (permalink / raw)
To: linux-wireless
Hi all,
Now that Linus closed the merge window for 4.8, I'm resuming near-daily
wireless-testing builds at:
http://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git
The first tag in this series is wt-2016-08-08. Let us know of any issues.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* [PATCH] wlcore: mesh: add zone time sync support
From: Guy Mishol @ 2016-08-08 8:57 UTC (permalink / raw)
To: linux-wireless; +Cc: Guy Mishol
Add zone time sync support for mesh role.
This allows to configure the mesh peer
master of each zone for time synchronization.
Signed-off-by: Guy Mishol <guym@ti.com>
---
drivers/net/wireless/ti/wl18xx/acx.c | 29 ++++++++++++++++
drivers/net/wireless/ti/wl18xx/acx.h | 13 +++++++
drivers/net/wireless/ti/wl18xx/debugfs.c | 59 ++++++++++++++++++++++++++++++++
drivers/net/wireless/ti/wl18xx/event.c | 1 +
drivers/net/wireless/ti/wlcore/wlcore.h | 3 ++
5 files changed, 105 insertions(+)
diff --git a/drivers/net/wireless/ti/wl18xx/acx.c b/drivers/net/wireless/ti/wl18xx/acx.c
index 4be0409..b5525a3 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.c
+++ b/drivers/net/wireless/ti/wl18xx/acx.c
@@ -309,3 +309,32 @@ out:
kfree(acx);
return ret;
}
+
+int wl18xx_acx_time_sync_cfg(struct wl1271 *wl)
+{
+ struct acx_time_sync_cfg *acx;
+ int ret;
+
+ wl1271_debug(DEBUG_ACX, "acx time sync cfg: mode %d, addr: %pM",
+ wl->conf.sg.params[WL18XX_CONF_SG_TIME_SYNC],
+ wl->zone_master_mac_addr);
+
+ acx = kzalloc(sizeof(*acx), GFP_KERNEL);
+ if (!acx) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ acx->sync_mode = wl->conf.sg.params[WL18XX_CONF_SG_TIME_SYNC];
+ memcpy(acx->zone_mac_addr, wl->zone_master_mac_addr, ETH_ALEN);
+
+ ret = wl1271_cmd_configure(wl, ACX_TIME_SYNC_CFG,
+ acx, sizeof(*acx));
+ if (ret < 0) {
+ wl1271_warning("acx time sync cfg failed: %d", ret);
+ goto out;
+ }
+out:
+ kfree(acx);
+ return ret;
+}
diff --git a/drivers/net/wireless/ti/wl18xx/acx.h b/drivers/net/wireless/ti/wl18xx/acx.h
index 342a299..2edbbbf 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.h
+++ b/drivers/net/wireless/ti/wl18xx/acx.h
@@ -37,6 +37,7 @@ enum {
ACX_RX_BA_FILTER = 0x0058,
ACX_AP_SLEEP_CFG = 0x0059,
ACX_DYNAMIC_TRACES_CFG = 0x005A,
+ ACX_TIME_SYNC_CFG = 0x005B,
};
/* numbers of bits the length field takes (add 1 for the actual number) */
@@ -388,6 +389,17 @@ struct acx_dynamic_fw_traces_cfg {
__le32 dynamic_fw_traces;
} __packed;
+/*
+ * ACX_TIME_SYNC_CFG
+ * configure the time sync parameters
+ */
+struct acx_time_sync_cfg {
+ struct acx_header header;
+ u8 sync_mode;
+ u8 zone_mac_addr[ETH_ALEN];
+ u8 padding[1];
+} __packed;
+
int wl18xx_acx_host_if_cfg_bitmap(struct wl1271 *wl, u32 host_cfg_bitmap,
u32 sdio_blk_size, u32 extra_mem_blks,
u32 len_field_size);
@@ -402,5 +414,6 @@ int wl18xx_acx_interrupt_notify_config(struct wl1271 *wl, bool action);
int wl18xx_acx_rx_ba_filter(struct wl1271 *wl, bool action);
int wl18xx_acx_ap_sleep(struct wl1271 *wl);
int wl18xx_acx_dynamic_fw_traces(struct wl1271 *wl);
+int wl18xx_acx_time_sync_cfg(struct wl1271 *wl);
#endif /* __WL18XX_ACX_H__ */
diff --git a/drivers/net/wireless/ti/wl18xx/debugfs.c b/drivers/net/wireless/ti/wl18xx/debugfs.c
index 86ccf84..9e28748 100644
--- a/drivers/net/wireless/ti/wl18xx/debugfs.c
+++ b/drivers/net/wireless/ti/wl18xx/debugfs.c
@@ -408,6 +408,64 @@ static const struct file_operations radar_debug_mode_ops = {
};
#endif /* CFG80211_CERTIFICATION_ONUS */
+static ssize_t time_sync_zone_addr_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos) {
+ struct wl1271 *wl = file->private_data;
+ char buf[(ETH_ALEN * 2)];
+ int ret;
+
+ if (count < (ETH_ALEN * 2 + 1)) {
+ wl1271_warning("Illegal MAC address: wrong size");
+ return -EINVAL;
+ }
+
+ ret = copy_from_user(buf, user_buf, (ETH_ALEN * 2));
+ if (ret < 0)
+ return ret;
+
+ ret = hex2bin(wl->zone_master_mac_addr, buf, ETH_ALEN);
+ if (ret < 0) {
+ wl1271_warning("Illegal MAC address: invalid characters");
+ return ret;
+ }
+
+ mutex_lock(&wl->mutex);
+
+ if (unlikely(wl->state != WLCORE_STATE_ON))
+ goto out;
+
+ ret = wl1271_ps_elp_wakeup(wl);
+ if (ret < 0)
+ goto out;
+
+ ret = wl18xx_acx_time_sync_cfg(wl);
+ if (ret < 0)
+ count = ret;
+
+ wl1271_ps_elp_sleep(wl);
+out:
+ mutex_unlock(&wl->mutex);
+ return count;
+}
+
+static ssize_t time_sync_zone_addr_read(struct file *file,
+ char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct wl1271 *wl = file->private_data;
+
+ return wl1271_format_buffer(userbuf, count, ppos,
+ "%pM\n", wl->zone_master_mac_addr);
+}
+
+static const struct file_operations time_sync_zone_addr_ops = {
+ .write = time_sync_zone_addr_write,
+ .read = time_sync_zone_addr_read,
+ .open = simple_open,
+ .llseek = default_llseek,
+};
+
int wl18xx_debugfs_add_files(struct wl1271 *wl,
struct dentry *rootdir)
{
@@ -576,6 +634,7 @@ int wl18xx_debugfs_add_files(struct wl1271 *wl,
#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
DEBUGFS_ADD(radar_debug_mode, moddir);
#endif
+ DEBUGFS_ADD(time_sync_zone_addr, moddir);
DEBUGFS_ADD(dynamic_fw_traces, moddir);
return 0;
diff --git a/drivers/net/wireless/ti/wl18xx/event.c b/drivers/net/wireless/ti/wl18xx/event.c
index 2c5df43..b36ce18 100644
--- a/drivers/net/wireless/ti/wl18xx/event.c
+++ b/drivers/net/wireless/ti/wl18xx/event.c
@@ -22,6 +22,7 @@
#include <net/genetlink.h>
#include "event.h"
#include "scan.h"
+#include "conf.h"
#include "../wlcore/cmd.h"
#include "../wlcore/debug.h"
#include "../wlcore/vendor_cmd.h"
diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h b/drivers/net/wireless/ti/wlcore/wlcore.h
index 8f28aa0..1827546 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore.h
@@ -501,6 +501,9 @@ struct wl1271 {
/* dynamic fw traces */
u32 dynamic_fw_traces;
+
+ /* time sync zone master */
+ u8 zone_master_mac_addr[ETH_ALEN];
};
int wlcore_probe(struct wl1271 *wl, struct platform_device *pdev);
--
2.6.4
^ permalink raw reply related
* [PATCH 2/2] mwifiex: simplify length computation for some memset
From: Christophe JAILLET @ 2016-08-08 7:39 UTC (permalink / raw)
To: akarwar, nishants, linux-wireless
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
This patch should be a no-op. It just simplifies code by using the name of
a variable instead of its type when calling 'sizeof'.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index 78819e8..644f3a2 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -574,7 +574,7 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
adapter->hs_activate_wait_q_woken = false;
- memset(&hscfg, 0, sizeof(struct mwifiex_ds_hs_cfg));
+ memset(&hscfg, 0, sizeof(hscfg));
hscfg.is_invoke_hostcmd = true;
adapter->hs_enabling = true;
@@ -1138,7 +1138,7 @@ int mwifiex_set_encode(struct mwifiex_private *priv, struct key_params *kp,
{
struct mwifiex_ds_encrypt_key encrypt_key;
- memset(&encrypt_key, 0, sizeof(struct mwifiex_ds_encrypt_key));
+ memset(&encrypt_key, 0, sizeof(encrypt_key));
encrypt_key.key_len = key_len;
encrypt_key.key_index = key_index;
--
2.7.4
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply related
* [PATCH 1/2] mwifiex: fix the length parameter of a memset
From: Christophe JAILLET @ 2016-08-08 7:38 UTC (permalink / raw)
To: akarwar, nishants, linux-wireless
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
In 'mwifiex_get_ver_ext', we have:
struct mwifiex_ver_ext ver_ext;
memset(&ver_ext, 0, sizeof(struct host_cmd_ds_version_ext));
This is likely that memset'ing sizeof(struct mwifiex_ver_ext) was expected.
Remove the ambiguity by using the variable name directly instead of its
type.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index e06647a..78819e8 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -1180,7 +1180,7 @@ mwifiex_get_ver_ext(struct mwifiex_private *priv, u32 version_str_sel)
{
struct mwifiex_ver_ext ver_ext;
- memset(&ver_ext, 0, sizeof(struct host_cmd_ds_version_ext));
+ memset(&ver_ext, 0, sizeof(ver_ext));
ver_ext.version_str_sel = version_str_sel;
if (mwifiex_send_cmd(priv, HostCmd_CMD_VERSION_EXT,
HostCmd_ACT_GEN_GET, 0, &ver_ext, true))
--
2.7.4
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply related
* [PATCH v3] mac80211: mesh: set tx_info->hw_queue to the correct queue upon packet forwarding
From: Yaniv Machani @ 2016-08-08 7:06 UTC (permalink / raw)
To: linux-kernel
Cc: Meirav Kama, Yaniv Machani, Johannes Berg, David S. Miller,
linux-wireless, netdev
From: Meirav Kama <meiravk@ti.com>
MP received data frames from another MP. Frames are forwarded
from Rx to Tx to be transmitted to a third MP.
Upon cloning the skb, the tx_info was zeroed, and the
hw_queue wasn't set correctly, causing frames to be
inserted to queue 0 (VOICE). If re-queue occurred for some
reason, frame will be inserted to correct queue 2 (BE).
In this case frames are now dequeued from 2 different queues and
sent out of order.
Signed-off-by: Meirav Kama <meiravk@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
---
v3 - update the headline
net/mac80211/rx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9a1eb70..88dc744 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2392,6 +2392,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->control.vif = &rx->sdata->vif;
info->control.jiffies = jiffies;
+ info->hw_queue = q;
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, fwded_mcast);
memcpy(fwd_hdr->addr2, sdata->vif.addr, ETH_ALEN);
--
2.9.0
^ permalink raw reply related
* [PATCH] Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel"
From: Johannes Berg @ 2016-08-08 6:50 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Hutchings, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
This reverts commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724.
Ben Hutchings pointed out that the commit isn't safe since it assumes
that the structure used by the driver is iw_point, when in fact there's
no way to know about that.
Fortunately, the only driver in the tree that ever runs this code path
is the wilc1000 staging driver, so it doesn't really matter.
Clearly I should have investigated this better before applying, sorry.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable@vger.kernel.org [though I guess it doesn't matter much]
Fixes: 3d5fdff46c4b ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/wext-core.c | 25 ++-----------------------
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
index dbb2738e356a..6250b1cfcde5 100644
--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -958,29 +958,8 @@ static int wireless_process_ioctl(struct net *net, struct ifreq *ifr,
return private(dev, iwr, cmd, info, handler);
}
/* Old driver API : call driver ioctl handler */
- if (dev->netdev_ops->ndo_do_ioctl) {
-#ifdef CONFIG_COMPAT
- if (info->flags & IW_REQUEST_FLAG_COMPAT) {
- int ret = 0;
- struct iwreq iwr_lcl;
- struct compat_iw_point *iwp_compat = (void *) &iwr->u.data;
-
- memcpy(&iwr_lcl, iwr, sizeof(struct iwreq));
- iwr_lcl.u.data.pointer = compat_ptr(iwp_compat->pointer);
- iwr_lcl.u.data.length = iwp_compat->length;
- iwr_lcl.u.data.flags = iwp_compat->flags;
-
- ret = dev->netdev_ops->ndo_do_ioctl(dev, (void *) &iwr_lcl, cmd);
-
- iwp_compat->pointer = ptr_to_compat(iwr_lcl.u.data.pointer);
- iwp_compat->length = iwr_lcl.u.data.length;
- iwp_compat->flags = iwr_lcl.u.data.flags;
-
- return ret;
- } else
-#endif
- return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
- }
+ if (dev->netdev_ops->ndo_do_ioctl)
+ return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
return -EOPNOTSUPP;
}
--
2.8.1
^ permalink raw reply related
* Re: wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel
From: Johannes Berg @ 2016-08-08 6:45 UTC (permalink / raw)
To: Ben Hutchings
Cc: rasun Maiti, Ujjal Roy, Dibyajyoti Ghosh, linux-wireless, stable
In-Reply-To: <1470588577.4325.4.camel@decadent.org.uk>
On Sun, 2016-08-07 at 17:49 +0100, Ben Hutchings wrote:
> I'm looking at commit 3d5fdff46c4b as part of the stable process.
>
> The path it touches is only used for drivers that don't describe
> their private wext handlers, right? So how can we know that the
> private ioctl is using the iw_point structure and not one of the
> other types in union iwreq_data? Doesn't this result in a regression
> when another type is being used?
>
Crap, that's good point. I'll revert the patch.
Fortunately this code path is never actually used. The only "mainline"
driver that appears to use it is staging/wilc1000.
I wonder if we should just remove it entirely. Yes, it'd break that
staging driver to some extent, but it's clearly an unsafe code path.
Prasun, did you need this for the mwifiex wext ioctl support that was
shot down anyway?
johannes
^ 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