ath lor

[PseudoCylon]

On Sun, Aug 5, 2012 at 11:24 AM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> On 5 August 2012 06:37, PseudoCylon <moonlightakkiy at yahoo.ca> wrote:
>
>>> What's the path through the stack -> driver that leads to
>>> run_tx_free() being called with the driver lock held?
>>
>> This one was easy to spot.
>> USB stack calls run_bulk_tx_callbackN() with driver lock held,
>> ->run_tx_free() ->ieee80211_free_node() then locks node lock.
>
> Ah. Hm, does the USB stack need to hold any locks held?
> That seems like a recipe for disaster for drivers in general, not just wifi.

Not 100% sure, but yes. And, it is unsafe to unlock before all usb
related tasks have done. In this case, we should unlock somewhere
here.
http://fxr.watson.org/fxr/source/dev/usb/wlan/if_run.c#L2805

Caller can specify the lock when setting up usb transfers
http://fxr.watson.org/fxr/source/dev/usb/wlan/if_run.c#L568
If null is passed rather than ptr to mtx, usb stack will use giant lock.
http://fxr.watson.org/fxr/source/dev/usb/usb_transfer.c?im=10#L841

>
>>> And on the flip side, what's the path through the driver -> stack
>>> that's called with the driver lock held? The comlock shouldn't be held
>>> when TX/RX'ing packets up to the stack.
>>
>> I have not found it yet. I've been stuck here, but I'll keep looking
>> for this. Then I can patch usb/150189.
>
> Cool.
>
>>> Hm, maybe we should start a wiki page with all of the net80211/wifi
>>> driver LORs. Do you have wiki.freebsd.org access? If not, create an
>>> account and tell me what username you choose. If you do, create a page
>>> under http://wiki.freebsd.org/WiFi and let's start documenting the
>>> LORs that we see.
>>
>> run(4) calls ieee80211_runtask() because thread is non-sleepable or
>> avoid LOR. I think I can still track back LOR. Also, I saved LOR
>> outputs I saw long time ago. See if I can find them on old hard drive.
>
> Yes. Please, let's start a wiki page with all the wifi stack / driver
> related LORs that you find. I really want to find/fix/document/squish
> them as soon as possible.

Will do.

>
> Also, would you please push a patch to the mailing list for your
> current ieee80211_iterate_nodes() work, so Kim and I can try it out?
> That way we can provide testing and feedback (respectively.)

Attached
iter.patch (with if_print)
iter2.patch (with reverting change functions)
both diff against CURRENT

>
> Thanks for your work with this! I'm glad to have someone else working
> on improving things. (Ray, Bernard and Monthadar included as well. :-)

Grad to help some.


AK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iter.patch
Type: application/octet-stream
Size: 2798 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-wireless/attachments/20120806/8b4e706d/iter.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iter2.patch
Type: application/octet-stream
Size: 2975 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-wireless/attachments/20120806/8b4e706d/iter2.obj