| Message ID | 52FE407C.3080002@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Feb 14, 2014 at 04:12:44PM +0000, Ivaylo Dimitrov wrote: > On 13.02.2014 21:29, Will Deacon wrote: > > > > Can you try hacking crypto/memneq.c so that it doesn't use > > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS please? That would at least point the > > finger at net/mac80211/rx.c or similar. > > > > Well, I am lazy so I hacked net/mac80211/rx.c first: No problem, thanks for having a go. > index c24ca0d..6839c77 100644 > --- a/net/mac80211/rx.c > +++ b/net/mac80211/rx.c > @@ -1963,7 +1963,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx) > } > } > > -#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > +//#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > if (skb) { > /* 'align' will only take the values 0 or 2 here since all > * frames are required to be aligned to 2-byte boundaries > @@ -1987,7 +1987,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx) > } > } > } > -#endif > +//#endif > > if (skb) { > /* deliver to local stack */ > > > and that seems to fix the problem. > > I am not sure whom I should forward the problem. Well, we probably need a bit more to go on, because I doubt that this code is to blame. More likely, the issue is in the caller. Looking at drivers/net/wireless/ti/wl1251/rx.c:182 /* The actual length doesn't include the target's alignment */ skb->len = desc->length - PLCP_HEADER_LENGTH; fc = (u16 *)skb->data; if ((*fc & IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_BEACON) beacon = 1; wl1251_rx_status(wl, desc, &status, beacon); wl1251_debug(DEBUG_RX, "rx skb 0x%p: %d B %s", skb, skb->len, beacon ? "beacon" : ""); memcpy(IEEE80211_SKB_RXCB(skb), &status, sizeof(status)); ieee80211_rx_ni(wl->hw, skb); I wonder whether that first line (with the comment about alignment) is assuming some behaviour from the mac80211 layer. You could try putting back the UNALIGNED_ACCESS in net/mac80211/rx.c and commenting out the skb->len = desc->length - PLCP_HEADER_LENGTH; line above. Adding the original author (I think) and John Linville, since I'm well out of my depth in this code! Will
On 14.02.2014 18:24, Will Deacon wrote: > > You could try putting back the UNALIGNED_ACCESS in net/mac80211/rx.c and > commenting out the skb->len = desc->length - PLCP_HEADER_LENGTH; line > above. This seems to fix the issue too, but I am afraid there is more to be done, as I see Feb 14 18:33:46 Nokia-N900 kernel: [ 88.599853] wlan0: authenticate with 00:23:cd:17:86:d0 Feb 14 18:33:46 Nokia-N900 kernel: [ 88.781860] wlan0: send auth to 00:23:cd:17:86:d0 (try 1/3) Feb 14 18:33:46 Nokia-N900 kernel: [ 88.799804] wlan0: authenticated Feb 14 18:33:46 Nokia-N900 kernel: [ 88.806243] wlan0: associating with AP with corrupt probe response Feb 14 18:33:46 Nokia-N900 kernel: [ 88.814544] wlan0: associate with 00:23:cd:17:86:d0 (try 1/3) Feb 14 18:33:46 Nokia-N900 kernel: [ 88.826416] wlan0: RX AssocResp from 00:23:cd:17:86:d0 (capab=0x431 status=0 aid=2) spit in dmesg log. AFAIR this is the first time I see "associating with AP with corrupt probe response" in dmesg, no matter of the kernel version. Despite of that error message, wlan seems to work as it should, so far. I guess we need the driver's author saying on the issue. Thanks, Ivo
On 14.02.2014 19:11, Ivaylo Dimitrov wrote: > > > On 14.02.2014 18:24, Will Deacon wrote: >> >> You could try putting back the UNALIGNED_ACCESS in net/mac80211/rx.c and >> commenting out the skb->len = desc->length - PLCP_HEADER_LENGTH; line >> above. > > This seems to fix the issue too, but I am afraid there is more to be > done, as I see > > Feb 14 18:33:46 Nokia-N900 kernel: [ 88.599853] wlan0: authenticate > with 00:23:cd:17:86:d0 > Feb 14 18:33:46 Nokia-N900 kernel: [ 88.781860] wlan0: send auth to > 00:23:cd:17:86:d0 (try 1/3) > Feb 14 18:33:46 Nokia-N900 kernel: [ 88.799804] wlan0: authenticated > Feb 14 18:33:46 Nokia-N900 kernel: [ 88.806243] wlan0: associating > with AP with corrupt probe response > Feb 14 18:33:46 Nokia-N900 kernel: [ 88.814544] wlan0: associate with > 00:23:cd:17:86:d0 (try 1/3) > Feb 14 18:33:46 Nokia-N900 kernel: [ 88.826416] wlan0: RX AssocResp > from 00:23:cd:17:86:d0 (capab=0x431 status=0 aid=2) > > spit in dmesg log. AFAIR this is the first time I see "associating with > AP with corrupt probe response" in dmesg, no matter of the kernel > version. Despite of that error message, wlan seems to work as it should, > so far. I guess we need the driver's author saying on the issue. > > Thanks, > Ivo ping?
Will Deacon <will.deacon@arm.com> writes: > Well, we probably need a bit more to go on, because I doubt that this code > is to blame. More likely, the issue is in the caller. > Looking at drivers/net/wireless/ti/wl1251/rx.c:182 > > /* The actual length doesn't include the target's alignment */ > skb->len = desc->length - PLCP_HEADER_LENGTH; > > fc = (u16 *)skb->data; > > if ((*fc & IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_BEACON) > beacon = 1; > > wl1251_rx_status(wl, desc, &status, beacon); > > wl1251_debug(DEBUG_RX, "rx skb 0x%p: %d B %s", skb, skb->len, > beacon ? "beacon" : ""); > > memcpy(IEEE80211_SKB_RXCB(skb), &status, sizeof(status)); > ieee80211_rx_ni(wl->hw, skb); > > I wonder whether that first line (with the comment about alignment) is > assuming some behaviour from the mac80211 layer. > > You could try putting back the UNALIGNED_ACCESS in net/mac80211/rx.c and > commenting out the skb->len = desc->length - PLCP_HEADER_LENGTH; line > above. > > Adding the original author (I think) and John Linville, since I'm well out > of my depth in this code! I haven't touched wl1251 for years. You should send questions to linux-wireless list and CC people who have worked on it recently.
Hi! > >>You could try putting back the UNALIGNED_ACCESS in net/mac80211/rx.c and > >>commenting out the skb->len = desc->length - PLCP_HEADER_LENGTH; line > >>above. > > > >This seems to fix the issue too, but I am afraid there is more to be > >done, as I see > > > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.599853] wlan0: authenticate > >with 00:23:cd:17:86:d0 > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.781860] wlan0: send auth to > >00:23:cd:17:86:d0 (try 1/3) > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.799804] wlan0: authenticated > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.806243] wlan0: associating > >with AP with corrupt probe response > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.814544] wlan0: associate with > >00:23:cd:17:86:d0 (try 1/3) > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.826416] wlan0: RX AssocResp > >from 00:23:cd:17:86:d0 (capab=0x431 status=0 aid=2) > > > >spit in dmesg log. AFAIR this is the first time I see "associating with > >AP with corrupt probe response" in dmesg, no matter of the kernel > >version. Despite of that error message, wlan seems to work as it should, > >so far. I guess we need the driver's author saying on the issue. > > ping? If Will does not respond, we should simply revert dce5c9e35bc4085bd33eccdb8c9ec5a643507a14 . Regressions are not acceptable. Pavel
On Tue, Feb 25, 2014 at 10:44:44AM +0000, Pavel Machek wrote: > > >>You could try putting back the UNALIGNED_ACCESS in net/mac80211/rx.c and > > >>commenting out the skb->len = desc->length - PLCP_HEADER_LENGTH; line > > >>above. > > > > > >This seems to fix the issue too, but I am afraid there is more to be > > >done, as I see > > > > > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.599853] wlan0: authenticate > > >with 00:23:cd:17:86:d0 > > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.781860] wlan0: send auth to > > >00:23:cd:17:86:d0 (try 1/3) > > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.799804] wlan0: authenticated > > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.806243] wlan0: associating > > >with AP with corrupt probe response > > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.814544] wlan0: associate with > > >00:23:cd:17:86:d0 (try 1/3) > > >Feb 14 18:33:46 Nokia-N900 kernel: [ 88.826416] wlan0: RX AssocResp > > >from 00:23:cd:17:86:d0 (capab=0x431 status=0 aid=2) > > > > > >spit in dmesg log. AFAIR this is the first time I see "associating with > > >AP with corrupt probe response" in dmesg, no matter of the kernel > > >version. Despite of that error message, wlan seems to work as it should, > > >so far. I guess we need the driver's author saying on the issue. > > > > ping? > > If Will does not respond, we should simply revert > dce5c9e35bc4085bd33eccdb8c9ec5a643507a14 . Regressions are not > acceptable. Seriously Pavel, give me a break. I already responded pretty quickly to this bug report, took a look at where the issue could be and proposed a fix (which Ivaylo tested successfully). Now, wireless drivers are *waay* outside my area of expertise, so I added some other folks to CC in the hope that they could help turn my fix into something upstreamable. Meanwhile, Ivaylo looks like he has something better than what I came up with already. If you care about this driver, why don't you help us fix it rather than making unhelpful suggestions from the sidelines? Will
--- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -1963,7 +1963,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx) } } -#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS +//#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS if (skb) { /* 'align' will only take the values 0 or 2 here since all * frames are required to be aligned to 2-byte boundaries @@ -1987,7 +1987,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx) } } } -#endif +//#endif if (skb) { /* deliver to local stack */