* Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.
From: Scott Wood @ 2016-08-02 19:57 UTC (permalink / raw)
To: arvind Yadav, Arnd Bergmann, linuxppc-dev@lists.ozlabs.org
Cc: qiang.zhao@freescale.com, viresh.kumar@linaro.org,
zajec5@gmail.com, linux-wireless@vger.kernel.org,
David.Laight@aculab.com, netdev@vger.kernel.org,
scottwood@freescale.com, akpm@linux-foundation.org,
davem@davemloft.net, linux@roeck-us.net, Li Yang
In-Reply-To: <57A0BD8E.9050305@gmail.com>
On 08/02/2016 10:34 AM, arvind Yadav wrote:
>
>
> On Tuesday 02 August 2016 01:15 PM, Arnd Bergmann wrote:
>> On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:
>>> On 08/01/2016 02:02 AM, Arnd Bergmann wrote:
>>>>> diff --git a/include/linux/err.h b/include/linux/err.h
>>>>> index 1e35588..c2a2789 100644
>>>>> --- a/include/linux/err.h
>>>>> +++ b/include/linux/err.h
>>>>> @@ -18,7 +18,17 @@
>>>>>
>>>>> #ifndef __ASSEMBLY__
>>>>>
>>>>> -#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
>>>>> +#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
>>>>> +
>>>>> +static inline int is_error_check(unsigned long error)
>>>> Please leave the existing macro alone. I think you were looking for
>>>> something specific to the return code of qe_muram_alloc() function,
>>>> so please add a helper in that subsystem if you need it, not in
>>>> the generic header files.
>>> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long. The
>>> problem is certain callers that store the return value in a u32. Why
>>> not just fix those callers to store it in unsigned long (at least until
>>> error checking is done)?
>>>
>> Yes, that would also address another problem with code like
>>
>> 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.
Well, hopefully it doesn't hold a return of qe_muram_alloc() when it's
being passed to kfree()...
There's also the code that casts kmalloc()'s return to u32, etc.
ucc_geth is not 64-bit clean in general.
>>
>> Arnd
> Yes, we will fix caller. Caller api is not safe on 64bit.
The API is fine (or at least, I haven't seen a valid issue pointed out
yet). The problem is the ucc_geth driver.
> Even qe_muram_addr(a.k.a. cpm_muram_addr )passing value unsigned int,
> but it should be unsigned long.
cpm_muram_addr takes unsigned long as a parameter, not that it matters
since you can't pass errors into it and a muram offset should never
exceed 32 bits.
-Scott
^ permalink raw reply
* [PATCH] Staging: rtl8723au: rtw_xmit: fixed coding style issues
From: Shiva Kerdel @ 2016-08-02 17:57 UTC (permalink / raw)
To: Larry.Finger
Cc: Jes.Sorensen, gregkh, geliangtang, linux-wireless, devel,
linux-kernel, Shiva Kerdel
Fixed some coding style issues that were detected as errors.
Signed-off-by: Shiva Kerdel <shiva@exdev.nl>
---
drivers/staging/rtl8723au/core/rtw_xmit.c | 26 ++++++++++----------------
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_xmit.c b/drivers/staging/rtl8723au/core/rtw_xmit.c
index 3de40cf..4ea7c5f 100644
--- a/drivers/staging/rtl8723au/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723au/core/rtw_xmit.c
@@ -174,7 +174,7 @@ int _rtw_init_xmit_priv23a(struct xmit_priv *pxmitpriv,
rtw_alloc_hwxmits23a(padapter);
rtw_init_hwxmits23a(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
- for (i = 0; i < 4; i ++)
+ for (i = 0; i < 4; i++)
pxmitpriv->wmm_para_seq[i] = i;
sema_init(&pxmitpriv->tx_retevt, 0);
@@ -640,7 +640,7 @@ static int xmitframe_addmic(struct rtw_adapter *padapter,
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
int curfragnum, length;
u8 *pframe, *payload, mic[8];
- u8 priority[4]= {0x0, 0x0, 0x0, 0x0};
+ u8 priority[4] = {0x0, 0x0, 0x0, 0x0};
u8 hw_hdr_offset = 0;
int bmcst = is_multicast_ether_addr(pattrib->ra);
@@ -667,10 +667,10 @@ static int xmitframe_addmic(struct rtw_adapter *padapter,
if (pattrib->encrypt == WLAN_CIPHER_SUITE_TKIP) {
/* encode mic code */
if (stainfo) {
- u8 null_key[16]={0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0};
+ u8 null_key[16] = {0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0};
pframe = pxmitframe->buf_addr + hw_hdr_offset;
@@ -902,8 +902,7 @@ static int rtw_make_wlanhdr(struct rtw_adapter *padapter, u8 *hdr,
if (psta->qos_option)
qos_option = true;
- }
- else {
+ } else {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_,
"fw_state:%x is not allowed to xmit frame\n",
get_fwstate(pmlmepriv));
@@ -1190,7 +1189,7 @@ int rtw_xmitframe_coalesce23a(struct rtw_adapter *padapter, struct sk_buff *skb,
pdata += mem_sz;
data_len -= mem_sz;
- if ((pattrib->icv_len >0) && (pattrib->bswenc)) {
+ if ((pattrib->icv_len > 0) && (pattrib->bswenc)) {
memcpy(pframe, pattrib->icv, pattrib->icv_len);
pframe += pattrib->icv_len;
}
@@ -1766,7 +1765,6 @@ void rtw_alloc_hwxmits23a(struct rtw_adapter *padapter)
hwxmits[4] .sta_queue = &pxmitpriv->be_pending;
} else if (pxmitpriv->hwxmit_entry == 4) {
-
/* pxmitpriv->vo_txqueue.head = 0; */
/* hwxmits[0] .phwtxqueue = &pxmitpriv->vo_txqueue; */
hwxmits[0] .sta_queue = &pxmitpriv->vo_pending;
@@ -1952,18 +1950,16 @@ int xmitframe_enqueue_for_sleeping_sta23a(struct rtw_adapter *padapter, struct x
/* spin_unlock_bh(&psta->sleep_q.lock); */
ret = true;
-
}
spin_unlock_bh(&psta->sleep_q.lock);
return ret;
-
}
spin_lock_bh(&psta->sleep_q.lock);
- if (psta->state&WIFI_SLEEP_STATE) {
+ if (psta->state & WIFI_SLEEP_STATE) {
u8 wmmps_ac = 0;
if (pstapriv->sta_dz_bitmap & CHKBIT(psta->aid)) {
@@ -2017,9 +2013,7 @@ int xmitframe_enqueue_for_sleeping_sta23a(struct rtw_adapter *padapter, struct x
/* */
ret = true;
-
}
-
}
spin_unlock_bh(&psta->sleep_q.lock);
@@ -2159,7 +2153,7 @@ void wakeup_sta_to_xmit23a(struct rtw_adapter *padapter, struct sta_info *psta)
/* update BCN for TIM IE */
update_mask = BIT(0);
- if (psta->state&WIFI_SLEEP_STATE)
+ if (psta->state & WIFI_SLEEP_STATE)
psta->state ^= WIFI_SLEEP_STATE;
if (psta->state & WIFI_STA_ALIVE_CHK_STATE) {
--
2.9.2
^ permalink raw reply related
* [PATCH v3] nl80211: Receive correct value for NL80211_MESHCONF_HT_OPMODE command
From: Masashi Honma @ 2016-08-03 1:07 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, j, me, Masashi Honma
In-Reply-To: <1468927556-4703-1-git-send-email-masashi.honma@gmail.com>
Previously, NL80211_MESHCONF_HT_OPMODE rejected correct flag
combination, ex) IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED |
IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT.
This was caused by simple comparison with value 16. This causes setting
non-existent flag (like 0x08) and invalid flag combinations. So this
commit implements some checks based on IEEE 802.11 2012 8.4.2.59 HT
Operation element.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
net/wireless/nl80211.c | 42 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 46417f9..7b7530d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5380,6 +5380,7 @@ static int nl80211_parse_mesh_config(struct genl_info *info,
{
struct nlattr *tb[NL80211_MESHCONF_ATTR_MAX + 1];
u32 mask = 0;
+ u16 ht_opmode;
#define FILL_IN_MESH_PARAM_IF_SET(tb, cfg, param, min, max, mask, attr, fn) \
do { \
@@ -5471,9 +5472,44 @@ do { \
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, rssi_threshold, -255, 0,
mask, NL80211_MESHCONF_RSSI_THRESHOLD,
nl80211_check_s32);
- FILL_IN_MESH_PARAM_IF_SET(tb, cfg, ht_opmode, 0, 16,
- mask, NL80211_MESHCONF_HT_OPMODE,
- nl80211_check_u16);
+ /*
+ * Check HT operation mode based on
+ * IEEE 802.11 2012 8.4.2.59 HT Operation element.
+ */
+ if (tb[NL80211_MESHCONF_HT_OPMODE]) {
+ ht_opmode = nla_get_u16(tb[NL80211_MESHCONF_HT_OPMODE]);
+
+ if (ht_opmode & (~(IEEE80211_HT_OP_MODE_PROTECTION |
+ IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT |
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT)))
+ return -EINVAL;
+
+ if ((ht_opmode & IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT) &&
+ (ht_opmode & IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT))
+ return -EINVAL;
+
+ switch (ht_opmode & IEEE80211_HT_OP_MODE_PROTECTION) {
+ case IEEE80211_HT_OP_MODE_PROTECTION_NONE:
+ if (ht_opmode & IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT)
+ return -EINVAL;
+ break;
+ case IEEE80211_HT_OP_MODE_PROTECTION_NONMEMBER:
+ if (!(ht_opmode &
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT))
+ return -EINVAL;
+ break;
+ case IEEE80211_HT_OP_MODE_PROTECTION_20MHZ:
+ if (ht_opmode & IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT)
+ return -EINVAL;
+ break;
+ case IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED:
+ if (!(ht_opmode &
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT))
+ return -EINVAL;
+ break;
+ }
+ cfg->ht_opmode = ht_opmode;
+ }
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, dot11MeshHWMPactivePathToRootTimeout,
1, 65535, mask,
NL80211_MESHCONF_HWMP_PATH_TO_ROOT_TIMEOUT,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] nl80211: Receive correct value for NL80211_MESHCONF_HT_OPMODE command
From: Masashi Honma @ 2016-08-03 1:07 UTC (permalink / raw)
To: masashi.honma; +Cc: johannes, linux-wireless, j, me
In-Reply-To: <1470138089-6864-1-git-send-email-masashi.honma@gmail.com>
On 2016年08月02日 20:41, Masashi Honma wrote:
> - FILL_IN_MESH_PARAM_IF_SET(tb, cfg, ht_opmode, 0, 16,
> + FILL_IN_MESH_PARAM_IF_SET(tb, cfg, ht_opmode, 0,
> + IEEE80211_HT_OP_MODE_PROTECTION |
> + IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT |
> + IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT,
> mask, NL80211_MESHCONF_HT_OPMODE,
> nl80211_check_u16);
This patch could over write cfg->ht_opmode even though EINVAL.
I will modify this.
Masashi Honma.
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Masashi Honma @ 2016-08-03 2:51 UTC (permalink / raw)
To: Johannes Berg
Cc: Yaniv Machani, linux-kernel, Meirav Kama, David S. Miller,
linux-wireless, netdev
In-Reply-To: <1470122837.2665.5.camel@sipsolutions.net>
On 2016年08月02日 16:27, Johannes Berg wrote:
> This explicitly configures *HT capability* though - that's even the
> name of the parameter. If you enable HT40 in the capability, the
> resulting BSS might still not actually *use* 40 MHz bandwidth, as
> required by overlapping BSS detection.
OK, I see.
HT Capabilities element = Defined by hardware and software spec of the
node. So it does not be modified after boot.
HT Operation element = Defined by surrounding environment and
configuration of the node. So it could be modified after boot.
So, if the node supports HT40, HT Capabilities shows HT40 is capable.
Now, I understand why you rejected this patch.
But now, when disable_ht=1, no HT Capabilities element in beacon even
though the node supports HT.
My trailing patch could solve the issue.
Masashi Honma.
^ permalink raw reply
* [PATCH] mac80211: Include HT Capabilities element if capable
From: Masashi Honma @ 2016-08-03 2:54 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, j, me, Masashi Honma
In-Reply-To: <1470122837.2665.5.camel@sipsolutions.net>
Previously, "HT Capabilities element" was not included in beacon and
Mesh Peering Open/Close frames when wpa_supplicant config file includes
disable_ht=1 even though HT is capable. But "HT Capabilities element"
should not be modified because it is defined by hardware and software
spec of the node.
We do not change "HT Operation element" code, because it is defined by
surrounding environment and configuration of the node. So it could be
vanished by disable_ht=1.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
net/mac80211/mesh.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index c66411d..ebd4159 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -409,10 +409,7 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data *sdata,
u8 *pos;
sband = local->hw.wiphy->bands[band];
- if (!sband->ht_cap.ht_supported ||
- sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT ||
- sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_5 ||
- sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
+ if (!sband->ht_cap.ht_supported)
return 0;
if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_cap))
--
2.7.4
^ permalink raw reply related
* Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
From: Alan Curry @ 2016-08-03 3:49 UTC (permalink / raw)
To: Al Viro
Cc: alexmcwhirter, David Miller, rlwinm, chunkeey, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20160728012253.GT2356@ZenIV.linux.org.uk>
Al Viro wrote:
>
> Which just might mean that we have *three* issues here -
> (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs
> (2) your ssl-only corruption
> (3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc
> anywhere, and no multi-segment recvmsg(). Which would strongly argue in
> favour of some kind of copy_page_to_iter() breakage triggered when handling
> a fragmented skb, as in (1). Except that I don't see anything similar in
> x86_64 uaccess primitives...
>
I think I've solved (3) at least...
Using the twin weapons of printk and stubbornness, I have built a working
theory of the bug. I haven't traced it all the way through, so my explanation
may be partly wrong. I do have a patch that eliminates the symptom in all my
tests though. Here's what happens:
A corrupted packet somehow arrives in skb_copy_and_csum_datagram_msg().
During downloads at reasonably high speed, about 0.1% of my incoming
packets are bad. Probably because the access point is that suspicious
Comcast thing.
skb_copy_and_csum_datagram_msg() does this:
if (skb_copy_and_csum_datagram(skb, hlen, &msg->msg_iter,
chunk, &csum))
goto fault;
if (csum_fold(csum))
goto csum_error;
skb_copy_and_csum_datagram() copies the bad data, computes the checksum,
and *advances the iterator*. The checksum is bad, so it goes to
csum_error, which returns without indicating success to userspace, but the
bad data is in the userspace buffer, and since the iterator has advanced,
the proper data doesn't get written to the proper place when it arrives in a
retransmission. The same iterator is still used because we're still in the
same syscall (I guess - this is one of the parts I didn't check out).
My ugly patch fixes this in the most obvious way: make a local copy of
msg->msg_iter before the call to skb_copy_and_csum_datagram(), and copy it
back if the checksum is bad, just before "goto csum_error;". (I wonder if the
other failure exits from this function might need to do the same thing.)
You can probably reproduce this problem if you deliberately inject some
bad TCP checksums into a stream. Just make sure the receiving machine is
in a blocking read() on the socket when the bad packet arrives. You may
need to resend the offending packet afterward with the checksum corrected.
diff --git a/net/core/datagram.c b/net/core/datagram.c
index b7de71f..574d4bf 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -730,6 +730,7 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
{
__wsum csum;
int chunk = skb->len - hlen;
+ struct iov_iter save_iter;
if (!chunk)
return 0;
@@ -741,11 +742,14 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
goto fault;
} else {
csum = csum_partial(skb->data, hlen, skb->csum);
+ memcpy(&save_iter, &msg->msg_iter, sizeof save_iter);
if (skb_copy_and_csum_datagram(skb, hlen, &msg->msg_iter,
chunk, &csum))
goto fault;
- if (csum_fold(csum))
+ if (csum_fold(csum)) {
+ memcpy(&msg->msg_iter, &save_iter, sizeof save_iter);
goto csum_error;
+ }
if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE))
netdev_rx_csum_fault(skb->dev);
}
--
Alan Curry
^ permalink raw reply related
* Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Johannes Berg @ 2016-08-03 6:50 UTC (permalink / raw)
To: Masashi Honma
Cc: Yaniv Machani, linux-kernel, Meirav Kama, David S. Miller,
linux-wireless, netdev
In-Reply-To: <bb69b031-53ad-4649-bd1d-e95ca7a0cc70@gmail.com>
On Wed, 2016-08-03 at 11:51 +0900, Masashi Honma wrote:
> On 2016年08月02日 16:27, Johannes Berg wrote:
> > This explicitly configures *HT capability* though - that's even the
> > name of the parameter. If you enable HT40 in the capability, the
> > resulting BSS might still not actually *use* 40 MHz bandwidth, as
> > required by overlapping BSS detection.
>
> OK, I see.
>
> HT Capabilities element = Defined by hardware and software spec of
> the node. So it does not be modified after boot.
It shouldn't really need to be modified, but perhaps for
interoperability reasons one might want to, like for example we do in
assoc request (we restrict our own capabilities to what the AP
supports, because some APs are stupid.)
That said, I'm basically only objecting to calling this a bugfix. If
the behaviour of restricting the information is desired, I see no real
problem with that, I just don't see how it could possibly be a bugfix.
> HT Operation element = Defined by surrounding environment and
> configuration of the node. So it could be modified after boot.
>
> So, if the node supports HT40, HT Capabilities shows HT40 is capable.
> Now, I understand why you rejected this patch.
>
> But now, when disable_ht=1, no HT Capabilities element in beacon even
> though the node supports HT.
>
> My trailing patch could solve the issue.
Actually, *this* one I'm not sure is correct. If you want to disable HT
completely, then HT operation can't actually indicate that, and having
HT capabilities without HT operation would likely just confuse peers,
so I think in this case it's quite possibly necessary to remove HT
capabilities.
johannes
^ permalink raw reply
* Re: [PATCH v2] nl80211: Receive correct value for NL80211_MESHCONF_HT_OPMODE command
From: Johannes Berg @ 2016-08-03 6:52 UTC (permalink / raw)
To: Masashi Honma; +Cc: linux-wireless, j, me
In-Reply-To: <9967cc0f-777e-31f6-0c4a-a788e92b9049@gmail.com>
> This patch could over write cfg->ht_opmode even though EINVAL.
> I will modify this.
>
Don't think that actually matters since then it shouldn't be used, but
the v3 patch looks good.
I'm not sure we should bother to do cross-setting validation? Like, I
mean, validating that non-GF and non-HT aren't set together, etc. Those
are somewhat nonsense configurations, but we can't prevent them all.
I'm actually half thinking that we could just remove all restrictions
on this and allow any u16 value of this field, and rely on
wpa_supplicant to do the right thing... Then we don't have to update
this if we ever want to do something new either.
What do you think? What does the validation actually help us with?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix purging multicast PS buffer queue
From: Johannes Berg @ 2016-08-03 6:54 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless
In-Reply-To: <20160802091341.64330-1-nbd@nbd.name>
On Tue, 2016-08-02 at 11:13 +0200, Felix Fietkau wrote:
> The code currently assumes that buffered multicast PS frames don't
> have
> a pending ACK frame for tx status reporting.
> However, hostapd sends a broadcast deauth frame on teardown for which
> tx
> status is requested. This can lead to the "Have pending ack frames"
> warning on module reload.
> Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue.
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: End the MPSP even if EOSP frame was not acked
From: Johannes Berg @ 2016-08-03 6:56 UTC (permalink / raw)
To: Masashi Honma; +Cc: linux-wireless, j, me
In-Reply-To: <1470125817-4461-1-git-send-email-masashi.honma@gmail.com>
On Tue, 2016-08-02 at 17:16 +0900, Masashi Honma wrote:
> If QoS frame with EOSP (end of service period) subfield=1 sent by
> local
> peer was not acked by remote peer, local peer did not end the MPSP.
> This
> prevents local peer from going to DOZE state. And if the remote peer
> goes away without closing connection, local peer continues AWAKE
> state
> and wastes battery.
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Daniel Wagner @ 2016-08-03 6:57 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Dmitry Torokhov, Arend van Spriel, Bjorn Andersson, Daniel Wagner,
Bastien Nocera, Greg Kroah-Hartman, Johannes Berg, Kalle Valo,
Ohad Ben-Cohen, Mimi Zohar, David Howells, Andy Lutomirski,
David Woodhouse, Julia Lawall, linux-input, linux-kselftest,
linux-wireless, linux-kernel
In-Reply-To: <20160802074106.GI3296@wotan.suse.de>
On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote:
> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
>>> On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
>> So you argue for the remoteproc use case with 100+ MB firmware that
>> if there is a way to load after pivot_root() (or other additional
>> firmware partition shows up) then there is no need at all for
>> usermode helper?
>
> No, I'm saying I'd like to hear valid uses cases for the usermode helper and so
> far I have only found using coccinelle grammar 2 explicit users, that's it. My
> patch series (not yet merge) then annotates these as valid as I've verified
> through their documentation they have some quirky requirement.
I got that question wrong. It should read something like 'for the
remoteproc 100+MB there is no need for the user help?'. I've gone
through your patches and they make perfectly sense too. Maybe I can
convince you to take a better version of my patch 3 into your queue. And
I help you converting the exiting drivers. Obviously if you like my help
at all.
> Other than these two drivers I'd like hear to valid requirements for it.
>
> The existential issue is a real issue but it does not look impossible to
> resolve. It may be a solution to bloat up the kernel with 100+ MB size just to
> stuff built-in firmware to avoid this issue, but it does not mean a solution
> is not possible.
>
> Remind me -- why can remoteproc not stuff the firmware in initramfs ?
I don't know. I was just bringing it up with the hope that Bjorn will
defend it. It seems my tactics didn't work out :)
> Anyway, here's a simple suggestion: fs/exec.c gets a sentinel file monitor
> support per enum kernel_read_file_id. For instance we'd have one for
> READING_FIRMWARE, one for READING_KEXEC_IMAGE, perhaps READING_POLICY, and this
> would in turn be used as the system configurable deterministic file for
> which to wait for to be present before enabling each enum kernel_read_file_id
> type read.
>
> Thoughts ?
Not sure if I get you here correctly. Is the 'system configurable
deterministic file' is a knob which controlled by user space? Or it this
something you define at compile time?
Hmm, so it would allow to decided to ask a userspace helper or load the
firmware directly (to be more precised the kernel_read_file_id type). If
yes, than it is what currently already have just integrated nicely into
the new sysdata API.
cheers,
daniel
^ permalink raw reply
* Re: [PATCH] ath10k: Allow setting coverage class
From: Michal Kazior @ 2016-08-03 7:09 UTC (permalink / raw)
To: Ben Greear
Cc: Benjamin Berg, Kalle Valo, linux-wireless, Mathias Kretschmer,
Sebastian Gottschall, ath10k@lists.infradead.org,
Simon Wunderlich
In-Reply-To: <579B71B4.7080206@candelatech.com>
On 29 July 2016 at 17:09, Ben Greear <greearb@candelatech.com> wrote:
> On 07/29/2016 07:52 AM, Benjamin Berg wrote:
[...]
>> Yeah, I am aware of the fact that the firmware may do internal resets
>> from time to time. The interesting question (and one for which I do not
>> know the answer) is whether we get a wmi or other event under all
>> conditions where the register may be rewritten due to a reset.
>>
>> The current code will re-set the register value after any wmi event
>> including debug messages. If this is not enough, then the only solution
>> might be to periodically poll the register values instead of relying on
>> a received event.
>
> You will get a dbglog event at least most of the time, so maybe that
> will be good enough.
But you need to remember you need to enable dbglog first to get these
events. I guess when coverage class is set the driver could,
internally, override dbglog mask so that these events are guaranteed
to be reported for the purpose of properly refreshing registers on
channel programming.
At that point I guess the update hook could be just placed in dbglog
handler alone instead of all over wmi_rx variants.
Michał
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Dmitry Torokhov @ 2016-08-03 7:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Daniel Wagner, Arend van Spriel, Bjorn Andersson, Daniel Wagner,
Bastien Nocera, Greg Kroah-Hartman, Johannes Berg, Kalle Valo,
Ohad Ben-Cohen, Mimi Zohar, David Howells, Andy Lutomirski,
David Woodhouse, Julia Lawall, linux-input@vger.kernel.org,
linux-kselftest, linux-wireless, lkml
In-Reply-To: <20160802074106.GI3296@wotan.suse.de>
On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
>> >On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
>> >>>The sysdata API's main goal rather is to provide a flexible API first,
>> >>>compartamentalizing the usermode helper was secondary. But now it seems
>> >>>I may just also add devm support too to help simplify code further.
>> >>
>> >>I missed the point that you plan to add usermode helper support to
>> >>the sysdata API.
>> >
>> >I had no such plans, when I have asked folks so far about "hey are you
>> >really in need for it, OK what for? " and "what extended uses do you
>> >envision?" so I far I have not gotten any replies at all. So -- instead
>> >sysdata currently ignores it.
>>
>> So you argue for the remoteproc use case with 100+ MB firmware that
>> if there is a way to load after pivot_root() (or other additional
>> firmware partition shows up) then there is no need at all for
>> usermode helper?
>
> No, I'm saying I'd like to hear valid uses cases for the usermode helper and so
> far I have only found using coccinelle grammar 2 explicit users, that's it. My
> patch series (not yet merge) then annotates these as valid as I've verified
> through their documentation they have some quirky requirement.
In certain configurations (embedded) people do not want to use
initramfs nor modules nor embed firmware into the kernel. In this case
usermode helper + firmware calss timeout handling provides necessary
wait for the root filesystem to be mounted.
If we solve waiting for rootfs (or something else that may contain
firmware) then these cases will not need to use usermode helper.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC v2 0/3] Improve wireless netdev detection
From: Johannes Berg @ 2016-08-03 6:59 UTC (permalink / raw)
To: Denis Kenzior, linux-wireless
In-Reply-To: <1468044967-9236-1-git-send-email-denkenz@gmail.com>
On Sat, 2016-07-09 at 01:16 -0500, Denis Kenzior wrote:
> The current mechanism to detect hot-plug / unplug of wireless devices
> is
> somewhat arcane. One has to listen to NEW_WIPHY/DEL_WIPHY events
> over
> nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then
> somehow find a correlation between these events. This involves
> userspace
> sending GET_INTERFACE or GET_WIPHY commands to the kernel, which
> incurs
> additional roundtrips.
>
> This patch series proposes that NEW_INTERFACE and DEL_INTERFACE
> events are
> always emitted, regardless of whether a netdev was added/removed by
> the
> driver or explicitly via NEW_INTERFACE/DEL_INTERFACE commands.
>
> v2: Squished patches 2+3, 4+5. DEL_INTERFACE event notification is
> now
> sent inside cfg80211_unregister_wdev instead of
> nl80211_del_interface.
>
Looks fine to me, care to resend as [PATCH]?
johannes
^ permalink raw reply
* Re: [PATCH 1/1 v2] rtlwifi: remove superfluous condition
From: Kalle Valo @ 2016-08-03 6:01 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Larry Finger, Chaoming Li, linux-wireless, netdev, linux-kernel
In-Reply-To: <1470165981-6241-1-git-send-email-xypron.glpk@gmx.de>
Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
> If sta == NULL, the changed line will not be reached.
> So no need to check that sta != NULL here.
>
> v2:
> fix typo
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
The change log goes under the "---" line so that git can automatically
strip it away while committing the patch. I can fix it this time but
please keep this in mind in the future.
--
Kalle Valo
^ permalink raw reply
* [bug report] NFC: nfcsim: Make use of the Digital layer
From: Dan Carpenter @ 2016-08-03 11:40 UTC (permalink / raw)
To: thierry.escande; +Cc: linux-wireless
Hello Thierry Escande,
The patch 204bddcb508f: "NFC: nfcsim: Make use of the Digital layer"
from Jun 23, 2016, leads to the following static checker warning:
drivers/nfc/nfcsim.c:485 nfcsim_init()
error: we previously assumed 'link0' could be null (see line 457)
drivers/nfc/nfcsim.c
450 static int __init nfcsim_init(void)
451 {
452 struct nfcsim_link *link0, *link1;
453 int rc;
454
455 link0 = nfcsim_link_new();
456 link1 = nfcsim_link_new();
457 if (!link0 || !link1) {
Say link0 is NULL here.
458 rc = -ENOMEM;
459 goto exit_err;
460 }
461
462 nfcsim_debugfs_init();
463
464 dev0 = nfcsim_device_new(link0, link1);
465 if (IS_ERR(dev0)) {
466 rc = PTR_ERR(dev0);
467 goto exit_err;
468 }
469
470 dev1 = nfcsim_device_new(link1, link0);
471 if (IS_ERR(dev1)) {
472 nfcsim_device_free(dev0);
473
474 rc = PTR_ERR(dev1);
475 goto exit_err;
476 }
477
478 pr_info("nfcsim " NFCSIM_VERSION " initialized\n");
479
480 return 0;
481
482 exit_err:
483 pr_err("Failed to initialize nfcsim driver (%d)\n", rc);
484
485 nfcsim_link_free(link0);
We oops inside the call to nfcsim_link_free().
486 nfcsim_link_free(link1);
487
488 return rc;
489 }
regards,
dan carpenter
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Arend van Spriel @ 2016-08-03 11:33 UTC (permalink / raw)
To: Luis R. Rodriguez, Valo, Kalle
Cc: Stanislaw Gruszka, Prarit Bhargava, Greg Kroah-Hartman, Ming Lei,
linux-wireless, ath10k, mmarek@suse.com, michal.kazior@tieto.com,
Arend van Spriel, Emmanuel Grumbach
In-Reply-To: <20160802141610.GJ3296@wotan.suse.de>
On 02-08-16 16:16, Luis R. Rodriguez wrote:
> On Tue, Aug 02, 2016 at 11:10:22AM +0000, Valo, Kalle wrote:
>> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
>>
>>> I was considering this as a future extension to the firmware API
>>> through the new extensible firmware API, the sysdata API.
>>
>> I think Linus mentioned this already, but I want to reiterate anyway.
>> The name "sysdata" is horrible, I didn't have any idea what it means
>> until I read your description. Please continue to use the term
>> "firmware", anyone already know what it means.
>
> We've gone well past using the firmware API for firmware though, if
> we use it for 802.11 to replace CRDA for instance its really odd to
> be calling it firmware. But sure... I will rebrand again to firmware...
I tend to agree. Although some people even call an OpenWrt image
firmware. Guess it is just in the eye of the beholder.
Regards,
Arend
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Arend van Spriel @ 2016-08-03 11:43 UTC (permalink / raw)
To: Dmitry Torokhov, Luis R. Rodriguez
Cc: Daniel Wagner, Bjorn Andersson, Daniel Wagner, Bastien Nocera,
Greg Kroah-Hartman, Johannes Berg, Kalle Valo, Ohad Ben-Cohen,
Mimi Zohar, David Howells, Andy Lutomirski, David Woodhouse,
Julia Lawall, linux-input@vger.kernel.org, linux-kselftest,
linux-wireless, lkml
In-Reply-To: <CAKdAkRR=NC4Agen9ad3CK8hgZh+zbZhzhr2MP169JwisgWvP_w@mail.gmail.com>
On 03-08-16 09:42, Dmitry Torokhov wrote:
> On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
>>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
>>>> On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
>>>>>> The sysdata API's main goal rather is to provide a flexible API first,
>>>>>> compartamentalizing the usermode helper was secondary. But now it seems
>>>>>> I may just also add devm support too to help simplify code further.
>>>>>
>>>>> I missed the point that you plan to add usermode helper support to
>>>>> the sysdata API.
>>>>
>>>> I had no such plans, when I have asked folks so far about "hey are you
>>>> really in need for it, OK what for? " and "what extended uses do you
>>>> envision?" so I far I have not gotten any replies at all. So -- instead
>>>> sysdata currently ignores it.
>>>
>>> So you argue for the remoteproc use case with 100+ MB firmware that
>>> if there is a way to load after pivot_root() (or other additional
>>> firmware partition shows up) then there is no need at all for
>>> usermode helper?
>>
>> No, I'm saying I'd like to hear valid uses cases for the usermode helper and so
>> far I have only found using coccinelle grammar 2 explicit users, that's it. My
>> patch series (not yet merge) then annotates these as valid as I've verified
>> through their documentation they have some quirky requirement.
>
> In certain configurations (embedded) people do not want to use
> initramfs nor modules nor embed firmware into the kernel. In this case
> usermode helper + firmware calss timeout handling provides necessary
> wait for the root filesystem to be mounted.
And there are people who don't have a usermode helper running at all in
their configuration, but I guess they should disable the helper.
In my opinion the kernel should provide functionality to user-space and
user-space providing functionality to the kernel should be avoided.
> If we solve waiting for rootfs (or something else that may contain
> firmware) then these cases will not need to use usermode helper.
If firmware (or whatever) API could get notification of mount syscall it
could be used to retry firmware loading instead of periodic polling.
That leaves the question raised by you about when to stop trying. The
initlevel stuff is probably a user-space only concept, right? So no
ideas how the kernel itself could decide except for a "long" timeout.
Regards,
Arend
^ permalink raw reply
* Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
From: Christian Lamparter @ 2016-08-03 12:43 UTC (permalink / raw)
To: Alan Curry
Cc: Al Viro, alexmcwhirter, David Miller, chunkeey, linux-wireless,
netdev, linux-kernel
In-Reply-To: <201608030349.u733nRPn000595@sdf.org>
On Wednesday, August 3, 2016 3:49:26 AM CEST Alan Curry wrote:
> Al Viro wrote:
> >
> > Which just might mean that we have *three* issues here -
> > (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs
> > (2) your ssl-only corruption
> > (3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc
> > anywhere, and no multi-segment recvmsg(). Which would strongly argue in
> > favour of some kind of copy_page_to_iter() breakage triggered when handling
> > a fragmented skb, as in (1). Except that I don't see anything similar in
> > x86_64 uaccess primitives...
> >
>
> I think I've solved (3) at least...
>
> Using the twin weapons of printk and stubbornness, I have built a working
> theory of the bug. I haven't traced it all the way through, so my explanation
> may be partly wrong. I do have a patch that eliminates the symptom in all my
> tests though. Here's what happens:
>
> A corrupted packet somehow arrives in skb_copy_and_csum_datagram_msg().
> During downloads at reasonably high speed, about 0.1% of my incoming
> packets are bad. Probably because the access point is that suspicious
> Comcast thing.
Thanks for being very persistent with this. I think I'm able to reproduce
this now (on any hardware... like r8169 ethernet) as long as the following
"traffic policy" is enacted on the HTTP - Server:
# tc qdisc add dev eth0 root netem corrupt 0.1%
(This needs the "Network Emulation" Sched CONFIG_NET_SCH_NETEM [0].)
With your tool (changed to point to my apache local server). I'm seeing
corruptions in the "noselect" case. Running it in "select" mode however
and the resulting files have no corruptions.
About AR9170 corruption issues: I know of one report that the AR9170's
Encryption Engine can cause corruptions [1]. In this case outgoing
data was corrupted which lead to deauths/disassocs since the AP was
basically sending out multicast deauths/disassocs with bad addresses.
However, "nohwcrypt" should have made a difference there since the
software decryption would discard the faulty package due the message
integrety checks.
Another source for corruptions could be the USB-PHY (FUSB200) in the
AR9170 [2]. I know it's causing problems for the ath9k_htc. However
not everyone is affected.
One thing I noticed in your previous post is that you "might" not have
draft-802.11n enabled. Do you see any "disabling HT/VHT due to WEP/TKIP use."
in your dmesg logs? If so, check if you can force your AP to use WPA2
with CCMP/AES only.
Regards,
Christian
[0] <http://www.spinics.net/lists/linux-wireless/msg60104.html>
[1] <https://wiki.linuxfoundation.org/networking/netem>
[2] <https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues>
^ permalink raw reply
* Re: [PATCH] ath9k: fix GPIO mask for AR9462 and AR9565
From: Valo, Kalle @ 2016-08-03 13:54 UTC (permalink / raw)
To: Stefan Lippers-Hollmann, miaoqing@codeaurora.org
Cc: linux-wireless@vger.kernel.org, ath9k-devel,
sudipm.mukherjee@gmail.com
In-Reply-To: <20160717230519.46e3a661@mir>
Stefan Lippers-Hollmann <s.l-h@gmx.de> writes:
> Hi
>
> On 2016-06-03, miaoqing@codeaurora.org wrote:
>> From: Miaoqing Pan <miaoqing@codeaurora.org>
>>
>> The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11.
>> Also fix the mask for AR9565.
> [...]
>
> I think I'm seeing a very similar issue on AR5008/ AR5416+AR2133 and
> 4.7-rc7 (mainline v4.7-rc7-92-g47ef4ad, to be exact).
>
> [ 4.958874] ath9k 0000:02:02.0: enabling device (0000 -> 0002)
> [...]
> [ 5.401086] ------------[ cut here ]------------
> [ 5.401093] WARNING: CPU: 1 PID: 1159 at /build/linux-aptosid-4.7~rc7/drivers/net/wireless/ath/ath9k/hw.c:2776 ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw]
[...]
> Reverting this, and the other patches depending on it, fixes the
> problem for me:
>
> e024111f6946f45cf1559a8c6fd48d2d0f696d07 Revert "ath9k: fix GPIO mask for AR9462 and AR9565"
> db2221901fbded787daed153281ed875de489692 Revert "ath9k: free GPIO resource for SOC GPIOs"
> c7212b7136ba69efb9785df68b669381cb893920 Revert "ath9k: fix BTCoex configuration for SOC chips"
> dfcf02cd2998e2240b2bc7b4f4412578b8070bdb Revert "ath9k: fix BTCoex access invalid registers for SOC chips"
> 668ae0a3e48ac6811f431915b466514bf167e2f4 Revert "ath9k: add bits definition of BTCoex MODE2/3 for SOC chips"
> c8770bcf5cefa8cbfae21c07c4fe3428f5a9d42a Revert "ath9k: Allow platform override BTCoex pin"
> 79d4db1214a0c7b1818aaf64d0606b17ff1acea7 Revert "ath9k: cleanup led_pin initial"
> b2d70d4944c1789bc64376ad97a811f37e230c87 Revert "ath9k: make GPIO API to support both of WMAC and SOC"
> a01ab81b09c55025365c1de1345b941a18e05529 Revert "ath9k: define correct GPIO numbers and bits mask"
>
> AR9285 (168c:002b) is fine either way.
Miaoqing, have you looked at this? Looks like another regression which
should be fixed.
--
Kalle Valo
^ permalink raw reply
* Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.
From: arvind Yadav @ 2016-08-03 13:55 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev@lists.ozlabs.org
Cc: qiang.zhao@freescale.com, viresh.kumar@linaro.org,
zajec5@gmail.com, linux-wireless@vger.kernel.org,
David.Laight@aculab.com, netdev@vger.kernel.org,
scottwood@freescale.com, akpm@linux-foundation.org,
davem@davemloft.net, linux@roeck-us.net, Li Yang
In-Reply-To: <DB5PR0401MB1928DE1F195A57160DED735D91050@DB5PR0401MB1928.eurprd04.prod.outlook.com>
On Wednesday 03 August 2016 01:27 AM, Scott Wood wrote:
> On 08/02/2016 10:34 AM, arvind Yadav wrote:
>>
>> On Tuesday 02 August 2016 01:15 PM, Arnd Bergmann wrote:
>>> On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:
>>>> On 08/01/2016 02:02 AM, Arnd Bergmann wrote:
>>>>>> diff --git a/include/linux/err.h b/include/linux/err.h
>>>>>> index 1e35588..c2a2789 100644
>>>>>> --- a/include/linux/err.h
>>>>>> +++ b/include/linux/err.h
>>>>>> @@ -18,7 +18,17 @@
>>>>>>
>>>>>> #ifndef __ASSEMBLY__
>>>>>>
>>>>>> -#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
>>>>>> +#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
>>>>>> +
>>>>>> +static inline int is_error_check(unsigned long error)
>>>>> Please leave the existing macro alone. I think you were looking for
>>>>> something specific to the return code of qe_muram_alloc() function,
>>>>> so please add a helper in that subsystem if you need it, not in
>>>>> the generic header files.
>>>> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long. The
>>>> problem is certain callers that store the return value in a u32. Why
>>>> not just fix those callers to store it in unsigned long (at least until
>>>> error checking is done)?
>>>>
>>> Yes, that would also address another problem with code like
>>>
>>> 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.
> Well, hopefully it doesn't hold a return of qe_muram_alloc() when it's
> being passed to kfree()...
>
> There's also the code that casts kmalloc()'s return to u32, etc.
> ucc_geth is not 64-bit clean in general.
>
>>> Arnd
>> Yes, we will fix caller. Caller api is not safe on 64bit.
> The API is fine (or at least, I haven't seen a valid issue pointed out
> yet). The problem is the ucc_geth driver.
>
>> Even qe_muram_addr(a.k.a. cpm_muram_addr )passing value unsigned int,
>> but it should be unsigned long.
> cpm_muram_addr takes unsigned long as a parameter, not that it matters
> since you can't pass errors into it and a muram offset should never
> exceed 32 bits.
>
> -Scott
Yes, It will work for 32bit machine. But will not safe for 64bit.
Example :
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]);
If qe_muram_alloc will return any error, IS_ERR_VALUE will
always return 0 (IS_ERR_VALUE will always pass for 'unsigned int').
Now qe_muram_addr will return wrong virtual address. Which
can cause an error.
-Arvind
^ permalink raw reply
* [PATCH v3 1/3] nl80211: Add nl80211_notify_iface
From: Denis Kenzior @ 2016-08-03 21:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Denis Kenzior
In-Reply-To: <1470261515-2830-1-git-send-email-denkenz@gmail.com>
This function emits NL80211_CMD_NEW_INTERFACE or
NL80211_CMD_DEL_INTERFACE events. This is meant to be used by the core
to notify userspace applications such as wpa_supplicant when a netdev
related to a wireless device has been added or removed.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/nl80211.c | 28 ++++++++++++++++++++++++++++
net/wireless/nl80211.h | 3 +++
2 files changed, 31 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ac19eb8..c174770 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -11855,6 +11855,34 @@ void nl80211_notify_wiphy(struct cfg80211_registered_device *rdev,
NL80211_MCGRP_CONFIG, GFP_KERNEL);
}
+void nl80211_notify_iface(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev,
+ enum nl80211_commands cmd)
+{
+ struct sk_buff *msg;
+ bool removal;
+
+ WARN_ON(cmd != NL80211_CMD_NEW_INTERFACE &&
+ cmd != NL80211_CMD_DEL_INTERFACE);
+
+ if (cmd == NL80211_CMD_DEL_INTERFACE)
+ removal = true;
+ else
+ removal = false;
+
+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (!msg)
+ return;
+
+ if (nl80211_send_iface(msg, 0, 0, 0, rdev, wdev, removal) < 0) {
+ nlmsg_free(msg);
+ return;
+ }
+
+ genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy), msg, 0,
+ NL80211_MCGRP_CONFIG, GFP_KERNEL);
+}
+
static int nl80211_add_scan_req(struct sk_buff *msg,
struct cfg80211_registered_device *rdev)
{
diff --git a/net/wireless/nl80211.h b/net/wireless/nl80211.h
index a63f402..6f6b73c 100644
--- a/net/wireless/nl80211.h
+++ b/net/wireless/nl80211.h
@@ -7,6 +7,9 @@ int nl80211_init(void);
void nl80211_exit(void);
void nl80211_notify_wiphy(struct cfg80211_registered_device *rdev,
enum nl80211_commands cmd);
+void nl80211_notify_iface(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev,
+ enum nl80211_commands cmd);
void nl80211_send_scan_start(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev);
struct sk_buff *nl80211_build_scan_msg(struct cfg80211_registered_device *rdev,
--
2.7.3
^ permalink raw reply related
* [PATCH v3 3/3] core: Always notify when wireless netdev is removed
From: Denis Kenzior @ 2016-08-03 21:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Denis Kenzior
In-Reply-To: <1470261515-2830-1-git-send-email-denkenz@gmail.com>
This change alters the semantics of NL80211_CMD_DEL_INTERFACE events
by always sending this event whenever a net_device object associated
with a wdev is destroyed. Prior to this change, this event was only
emitted as a result of NL80211_CMD_DEL_INTERFACE command sent from
userspace. This allows userspace to reliably detect when wireless
interfaces have been removed, e.g. due to USB removal events, etc.
For wireless device objects without an associated net_device (e.g.
NL80211_IFTYPE_P2P_DEVICE), the NL80211_CMD_DEL_INTERFACE event is
now generated inside cfg80211_unregister_wdev.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/core.c | 4 ++++
net/wireless/nl80211.c | 18 +-----------------
2 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7758c0f..fccead7 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -906,6 +906,8 @@ void cfg80211_unregister_wdev(struct wireless_dev *wdev)
if (WARN_ON(wdev->netdev))
return;
+ nl80211_notify_iface(rdev, wdev, NL80211_CMD_DEL_INTERFACE);
+
list_del_rcu(&wdev->list);
rdev->devlist_generation++;
@@ -1159,6 +1161,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
* remove and clean it up.
*/
if (!list_empty(&wdev->list)) {
+ nl80211_notify_iface(rdev, wdev,
+ NL80211_CMD_DEL_INTERFACE);
sysfs_remove_link(&dev->dev.kobj, "phy80211");
list_del_rcu(&wdev->list);
rdev->devlist_generation++;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 591c3ab..4fa7175 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2907,18 +2907,10 @@ static int nl80211_del_interface(struct sk_buff *skb, struct genl_info *info)
{
struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct wireless_dev *wdev = info->user_ptr[1];
- struct sk_buff *msg;
- int status;
if (!rdev->ops->del_virtual_intf)
return -EOPNOTSUPP;
- msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
- if (msg && nl80211_send_iface(msg, 0, 0, 0, rdev, wdev, true) < 0) {
- nlmsg_free(msg);
- msg = NULL;
- }
-
/*
* If we remove a wireless device without a netdev then clear
* user_ptr[1] so that nl80211_post_doit won't dereference it
@@ -2929,15 +2921,7 @@ static int nl80211_del_interface(struct sk_buff *skb, struct genl_info *info)
if (!wdev->netdev)
info->user_ptr[1] = NULL;
- status = rdev_del_virtual_intf(rdev, wdev);
- if (status >= 0 && msg)
- genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy),
- msg, 0, NL80211_MCGRP_CONFIG,
- GFP_KERNEL);
- else
- nlmsg_free(msg);
-
- return status;
+ return rdev_del_virtual_intf(rdev, wdev);
}
static int nl80211_set_noack_map(struct sk_buff *skb, struct genl_info *info)
--
2.7.3
^ permalink raw reply related
* [PATCH v3 2/3] core: Always notify of new wireless netdevs
From: Denis Kenzior @ 2016-08-03 21:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Denis Kenzior
In-Reply-To: <1470261515-2830-1-git-send-email-denkenz@gmail.com>
This change alters the semantics of NL80211_CMD_NEW_INTERFACE events
by always sending this event whenever a new net_device object
associated with a wdev is registered. Prior to this change, this event
was only sent as a result of NL80211_CMD_NEW_INTERFACE command sent
from userspace. This allows userspace to reliably detect new wireless
interfaces (e.g. due to hardware hot-plug events, etc).
For wdevs created without an associated net_device object (e.g.
NL80211_IFTYPE_P2P_DEVICE), the NL80211_CMD_NEW_INTERFACE event is
still generated inside the relevant nl80211 command handler.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/core.c | 2 ++
net/wireless/nl80211.c | 23 +++++++++--------------
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7645e97..7758c0f 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1079,6 +1079,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
wdev->iftype == NL80211_IFTYPE_P2P_CLIENT ||
wdev->iftype == NL80211_IFTYPE_ADHOC) && !wdev->use_4addr)
dev->priv_flags |= IFF_DONT_BRIDGE;
+
+ nl80211_notify_iface(rdev, wdev, NL80211_CMD_NEW_INTERFACE);
break;
case NETDEV_GOING_DOWN:
cfg80211_leave(rdev, wdev);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c174770..591c3ab 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2787,7 +2787,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct vif_params params;
struct wireless_dev *wdev;
- struct sk_buff *msg, *event;
+ struct sk_buff *msg;
int err;
enum nl80211_iftype type = NL80211_IFTYPE_UNSPECIFIED;
u32 flags;
@@ -2891,20 +2891,15 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
return -ENOBUFS;
}
- event = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
- if (event) {
- if (nl80211_send_iface(event, 0, 0, 0,
- rdev, wdev, false) < 0) {
- nlmsg_free(event);
- goto out;
- }
-
- genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy),
- event, 0, NL80211_MCGRP_CONFIG,
- GFP_KERNEL);
- }
+ /*
+ * For wdevs which have no associated netdev object (e.g. of type
+ * NL80211_IFTYPE_P2P_DEVICE), emit the NEW_INTERFACE event here.
+ * For all other types, the event will be generated from the
+ * netdev notifier
+ */
+ if (!wdev->netdev)
+ nl80211_notify_iface(rdev, wdev, NL80211_CMD_NEW_INTERFACE);
-out:
return genlmsg_reply(msg, info);
}
--
2.7.3
^ permalink raw reply related
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