ath lor

[PseudoCylon]

> ------------------------------
>
> Message: 3
> Date: Sat, 28 Jul 2012 19:36:38 -0700
> From: Adrian Chadd <adrian.chadd at gmail.com>
> Subject: Re: ath lor
> To: Kim Culhan <w8hdkim at gmail.com>
> Cc: freebsd-wireless at freebsd.org
> Message-ID:
>         <CAJ-VmonVdu8QEETKeBF6HOY5DTzxT4OH6z8xJecUGZgmQ58grw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hm, if someone's up for a bit of coding, here's my suggestIon:
>
> * create an iterator struct which just contains an array of
> ieee80211_node entries;
> * write an iterator function that _just_ populates that iterator
> struct with ieee80211 node entries, but after having locked them;
> * then, once the call to ieee80211_iterate_node() is done, the
> iterator struct will have a list of nodes to iterate over;
> * then just call the original callback over each member of that
> iterator struct node array, derefing nodes as you go along.
>

Do you want to change the above to C code? I can do that if no one does it.

Do you want an iterator struct node *array* or a linked list? The
standard allows 2007 stations to associate an AP, so the array will be
that big. Or, use even dirtier trick to make the array size variable?

> That avoids calling any callbacks with the iterator node table lock held.
>
> It's dirty and I would prefer the use of something more modern, like
> transactional memory or generation counts, but I'd really like this
> bug squished so kim and others can continue hacking/testing this
> stuff. It'd also eliminate a rather annoying LOR from the TODO list.
>

We still need to look after comlock LOR. LOR between scanlock and
comlock is the original problem of this thread. And, comlock is
causing dead locks all over run(4). I've been working on it, but kinda
stuck. Hence no solution, yet.

Also, for USB devices, because usbd_do_request_flags() may sleep,
hopefully ieee80211 stack understands the driver has to unlock or call
taskqueue, even though comlock (or other locks) need to be held during
driver functions being executed.
http://fxr.watson.org/fxr/source/dev/usb/usb_request.c#L346


AK