headers
Johannes Berg | 1 May 02:34
Favicon

Re: putting ieee80211_tx_control into skb->cb?

On Wed, 2008-04-30 at 17:47 +0200, Johannes Berg wrote:
> With my patch to shrink ieee80211_tx_control, I can now put that into
> skb->cb.
> 
> Do we want to use that as the interface to drivers as well? Many drivers
> could benefit from that a lot since we could save all the extra copies
> done here.

Yes, we do.

Proof-of-concept code
here: http://johannes.sipsolutions.net/patches/kernel/all/2008-05-01-00:32/041-mac80211-tx-info-skb-cb.patch

If you want to give it a try, beware! I changed a number of patches this
is based on, the GSO-fragmentation one is among them, so you really want
to pull all those from there rather than using the versions I posted.

Will have to update all the other drivers now (done b43 so far)... But
I'll let this simmer in my tree for a while and test with AP mode etc.,
I think we should do one thing at a time ;)

johannes
Permalink | Reply | 0 comments |
headers
John W. Linville | 1 May 02:43
Favicon

pull request: wireless-2.6 2008-04-30

David,

Here is another volley of fixes for 2.6.26.  It all seems fairly
straight-forward.

Thanks,

John

---

Individual patches are available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/

---

The following changes since commit 809917903127804c2b2ac76342ab0f29f4b394d3:
  Pavel Emelyanov (1):
        ipv6: Compilation fix for compat MCAST_MSFILTER sockopts.

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master

Harvey Harrison (1):
      mac80211: incorrect shift direction

Holger Schurig (1):
      libertas: fix use-before-check violation
(Continue reading)

Permalink | Reply | 1 comment |
headers
Johannes Berg | 1 May 04:02
Favicon

mac80211 truesize bugs

Hi,

Whenever you run a monitor interface in mac80211, you can see lots of
truesize bugs:

SKB BUG: Invalid truesize (464) len=307, sizeof(sk_buff)=176

It appears to be caused by mac80211's re-injection of the transmitted
frame. For those not familiar, here's what happens:

When a frame comes in on say wlan0's hard_start_xmit(), it is prepared
for transmission by the code there (802.11 headers added etc.) and then
scheduled to the master interface. Once it arrives on the master
(wmaster0) interface's hard_start_xmit(), it is modified again and
finally handed to the driver.

When the driver has transmitted the frame (successfully or not) it
reports the status of the transmission to mac80211 including the skb the
driver was given. At that point, things go different depending on
circumstances.

If no monitor interfaces are present, mac80211 simply orphans the skb
and destroys it. If there are monitor interfaces, it pushes some data
into the skb (the radiotap transmit status) and hands clones of the skb
to netif_rx() for each monitor interface, or the skb itself for the last
interface in the list.

All this is in net/mac80211/main.c:ieee80211_tx_status.

Now, the thing is that the skb truesize bug ONLY occurs when the last
(Continue reading)

Permalink | Reply | 134 comments |
headers
Ivo van Doorn | 1 May 10:21
Picon

Re: [RFC/RFT 4/4] mac80211: use multi-queue master netdevice

On Wednesday 30 April 2008, Johannes Berg wrote:
> Turns out there was something missing (last hunk of this updated
> version) from the rt2x00 part of the patch that I accidentally didn't
> quilt edit, here's an updated version if anybody wants to test on rt2x00
> hw.

I've tested the following patch series:

mac80211: clean up get_tx_stats callback
mac80211: remove queue info from ieee80211_tx_status
mac80211: QoS related cleanups
mac80211: use rate index in TX control
GSO: generalize for mac80211
mac80211: use GSO for fragmentation
mac80211: use multi-queue master netdevice

My rt61 card (4 TX queues) seems to work correctly, it uses
queue 3 as default queue, and a few packets seem to go
over queue 1.

Ivo

> johannes
> 
> Subject: mac80211: use multi-queue master netdevice
> 
> This patch updates mac80211 and drivers to be multi-queue aware and
> use that instead of the internal queue mapping.
> 
> Signed-off-by: Johannes Berg <johannes@...>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ivo van Doorn | 1 May 10:29
Picon

Re: Please pull 'upstream' branch of rt2x00

Hi John,

> Finally a new official rt2x00 release,
> off course I have send a lot of patches over the past few weeks
> with several bugfixes, but now I am bumping the versions to 2.1.5.
> 
> Please consider this patch series for the 2.6.26 kernel,

Was this patch series in time for the 2.6.26 merge window?

If not, please consider merging at least the following patches since
they are real bugfixes:

>       rt2x00: Don't enable short preamble for 1MBs
>       rt2x00: Fix quality/activity led handling
>       rt2x00: Clarify supported chipsets in Kconfig

The others are code cleanups which are "nice to have", but could otherwise
wait for 2.6.27.

>       rt2x00: Support hardware RTS and CTS-to-self frames
>       rt2x00: Remove DRIVER_SUPPORT_MIXED_INTERFACES
>       rt2x00: Use rt2x00 queue numbering
>       rt2x00: Add helper macros
>       rt2x00: Fix kernel-doc
>       rt2x00: Release rt2x00 2.1.5

Thanks,

Ivo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 May 10:54
Favicon

Re: [RFC/RFT 4/4] mac80211: use multi-queue master netdevice


> I've tested the following patch series:
> 
> mac80211: clean up get_tx_stats callback
> mac80211: remove queue info from ieee80211_tx_status
> mac80211: QoS related cleanups
> mac80211: use rate index in TX control
> GSO: generalize for mac80211
> mac80211: use GSO for fragmentation
> mac80211: use multi-queue master netdevice
> 
> My rt61 card (4 TX queues) seems to work correctly, it uses
> queue 3 as default queue, and a few packets seem to go
> over queue 1.

Nice, thanks for testing!

johannes
Permalink | Reply | 0 comments |
headers
Michael Buesch | 1 May 10:58
Picon
Favicon

Re: mac80211 truesize bugs

On Thursday 01 May 2008 04:02:48 Johannes Berg wrote:
> Hi,
> 
> Whenever you run a monitor interface in mac80211, you can see lots of
> truesize bugs:
> 
> SKB BUG: Invalid truesize (464) len=307, sizeof(sk_buff)=176
> 
> It appears to be caused by mac80211's re-injection of the transmitted
> frame. For those not familiar, here's what happens:
> 
> When a frame comes in on say wlan0's hard_start_xmit(), it is prepared
> for transmission by the code there (802.11 headers added etc.) and then
> scheduled to the master interface. Once it arrives on the master
> (wmaster0) interface's hard_start_xmit(), it is modified again and
> finally handed to the driver.
> 
> When the driver has transmitted the frame (successfully or not) it
> reports the status of the transmission to mac80211 including the skb the
> driver was given. At that point, things go different depending on
> circumstances.
> 
> If no monitor interfaces are present, mac80211 simply orphans the skb
> and destroys it. If there are monitor interfaces, it pushes some data
> into the skb (the radiotap transmit status) and hands clones of the skb
> to netif_rx() for each monitor interface, or the skb itself for the last
> interface in the list.

Hm, unrelated to this...
But I am wondering what happens if the driver adds a device header to the skb.
(Continue reading)

Permalink | Reply | 130 comments |
headers
Johannes Berg | 1 May 11:08
Favicon

Re: mac80211 truesize bugs


> Hm, unrelated to this...
> But I am wondering what happens if the driver adds a device header to the skb.
> Is that header then also passed up netif_rx()?
> This doesn't happen for b43, as we use the DMA fragmentation to transmit the header,
> but it might happen for zd1211rw and others.

Hmm. I thought we said that it was supposed to be removed again by the
hardware before TX status reporting. That's what most drivers seem to do
anyway.

I'm considering turning off this transmit status reporting for now but
that will make hostapd not work.

> Seems the skb->destructor messes it up.

Actually, it seems to be outside of mac80211, I put in a WARN_ON() and
got this:

Badness at include/linux/skbuff.h:392
NIP: c026ea14 LR: c0273d54 CTR: c026e9e4
REGS: edfc7c00 TRAP: 0700   Not tainted  (2.6.25-wl-06841-g6b3d5c6-dirty)
MSR: 00029032 <EE,ME,IR,DR>  CR: 82022444  XER: 00000000
TASK = edf50e20[3453] 'tcpdump' THREAD: edfc6000
GPR00: 00000001 edfc7cb0 edf50e20 edfd7700 edfd7700 00000002 edfc7e75 03230306 
GPR08: 02000100 00000168 4dff0200 00000150 22022442 100a6290 100783f8 10078e18 
GPR16: 10078e14 10078e10 100a0000 00000000 00000000 bfe2c9d2 1004d320 bfe2c4b0 
GPR24: 10165070 edfd7724 00000060 00000020 ed8157f0 edfd7700 ed8157f0 edfd7700 
NIP [c026ea14] sock_rfree+0x30/0x94
LR [c0273d54] skb_release_all+0x98/0x128
(Continue reading)

Permalink | Reply | 128 comments |
headers
David Miller | 1 May 11:20
Favicon

Re: mac80211 truesize bugs

From: Johannes Berg <johannes@...>
Date: Thu, 01 May 2008 11:08:06 +0200

> > Seems the skb->destructor messes it up.
> 
> Actually, it seems to be outside of mac80211, I put in a WARN_ON() and
> got this:

You're just seeing who freed it last here.

It could have had it's ->truesize put into an illegal state
elsewhere.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 122 comments |
headers
Michael Buesch | 1 May 11:32
Picon
Favicon

Re: mac80211 truesize bugs

On Thursday 01 May 2008 11:08:06 Johannes Berg wrote:
> 
> > Hm, unrelated to this...
> > But I am wondering what happens if the driver adds a device header to the skb.
> > Is that header then also passed up netif_rx()?
> > This doesn't happen for b43, as we use the DMA fragmentation to transmit the header,
> > but it might happen for zd1211rw and others.
> 
> Hmm. I thought we said that it was supposed to be removed again by the
> hardware before TX status reporting. That's what most drivers seem to do
> anyway.

Ok. I was not aware of that. Is that documented somewhere? I guess we can't WARN_ON()?

> > Seems the skb->destructor messes it up.
> 
> Actually, it seems to be outside of mac80211, I put in a WARN_ON() and
> got this:

Yeah looks like the destructor messes with the data/sizes and disagrees
with the way mac80211 handles stuff, in some way.

> Badness at include/linux/skbuff.h:392
> NIP: c026ea14 LR: c0273d54 CTR: c026e9e4
> REGS: edfc7c00 TRAP: 0700   Not tainted  (2.6.25-wl-06841-g6b3d5c6-dirty)
> MSR: 00029032 <EE,ME,IR,DR>  CR: 82022444  XER: 00000000
> TASK = edf50e20[3453] 'tcpdump' THREAD: edfc6000
> GPR00: 00000001 edfc7cb0 edf50e20 edfd7700 edfd7700 00000002 edfc7e75 03230306 
> GPR08: 02000100 00000168 4dff0200 00000150 22022442 100a6290 100783f8 10078e18 
> GPR16: 10078e14 10078e10 100a0000 00000000 00000000 bfe2c9d2 1004d320 bfe2c4b0
(Continue reading)

Permalink | Reply | 2 comments |

Gmane