On Mon, May 30, 2011 at 11:03 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Mon, 2011-05-30 at 09:55 +0200, Helmut Schaa wrote:
>
>> > >> AFAICT not all tx calls from mac80211 are protected by local_bh_disable/enable. I believe
>> > >> that this is the case for the "process" context tx calls from
>> > >
>> > >> ieee80211_subif_start_xmit
>> > >
>> > > This should only be called from the network softirq and thus doesn't require bottom halves
>> > > to be disabled (AFAIK).
>> > >
>> > >> and
>> > >> ieee80211_monitor_start_xmit.
>> > >
>> > > Same here.
>> >
>> > Hmm, are you sure about this?
>>
>> Maybe Johannes can clarify this for us ;)
>
> The above assertion ("not all TX calls are protected") is wrong.
>
>> Johannes, are all calls to the drivers tx callback done in softirq context or
>> adequately protected by local_bh_disable/enable? Or is this presumption wrong?
>
> All of them are invoked with BHs disabled.
>
> Cf. ieee80211_tx_skb(), which is the only function that can be called
> from process context. The _start_xmit functions listed above are called
> by the networking layer and always invoked with BHs disabled.
>
OK. Thanks for the clarification. I'll update the patch to use
spin_lock / spin_unlock instead
of spin_lock_bh / spin_unlock_bh when I return home on Wednesday.
As a follow-up question, is it valid that mac80211 calls the driver's
tx function simultaneously
for multiple frames, or are we experiencing an issue with mac80211 here?
We are experiencing in rt2x00 that our tx function is called while it
is already running, leading
to races in the queue handling when enqueuing the frame for the hw.
---
Gertjan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
