#162: failed assertion in rate-sample, race condition bringing interfaces up
----------------------------------+-----------------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: defect | Status: new
Priority: minor | Milestone: version 0.9.3
Component: madwifi: driver | Version: trunk
Resolution: | Keywords:
Patch_attached: 1 |
----------------------------------+-----------------------------------------
Comment (by [EMAIL PROTECTED]):
Hi, mrenzmann!
I'm not even sure what the right solution is. Its been a while since I've
looked at this, and my memory isn't what it used to be :) Since I'm so
clue-deprived, I guess I'd better start asking questions.
The way I see it, there are a few possible ways to fix this:
1. change the API, allow ath_rate_findrate to return an error if it can't
find its state
2. use a multicast rate if state hasn't been set up, as suggested by
[EMAIL PROTECTED]
3. figure out why the state wasn't set up yet, and fix that problem
instead
My first patch, rate_sample_race.diff, implements (1). It isn't complete,
the API change needs to be applied to the other rate plugins as well. I'm
happy to perform this cleanup, if that's what you want.
I think my second patch, sample-plugin-kassert.diff, implements (2). Rate
number 0 is the multicast rate, right? I'm unsure of this. In any case,
with the added conditional in this patch, the KASSERT below is now only
really checking for an invalid sn->num_rates value, so it can probably be
simplified a bit.
The patch provided by Dan seems to do a little of both... it changes the
API so ath_rate_findrate can return an error, and patches the caller to
use the multicast rate. I don't really understand this patch, but I'm
willing to figure it out. Reading this patch brings up another question:
it looks like there was already some code to handle the case where "rix"
got set to 0xff. Is this an already-existing way for the rate plugin to
report an error? Is the KASSERT in the sample plugin there to prevent
this from ever happening? How does this change tie into that stuff?
What I'd really love to see is a fix for (3), because I'm afraid other
race conditions elsewhere may also exist. (It begs the question, why are
packets coming in from the rest of the kernel if we aren't ready for them
yet?) But I wouldn't know where to start, with that.
So, are you asking for a cleaned up patch for (1), or for (2)? What did
you think about Dan's stuff? My first patch just returned -EIO and
dropped the packet; do you think sending with the multicast rate is
better? I'm happy to issue a new patch, I just need some guidance.
Mark
--
Ticket URL: <http://madwifi.org/ticket/162>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Madwifi-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-tickets
