From: Helmut Schaa <helmut.schaa@googlemail.com>
To: Pavel Roskin <proski@gnu.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org,
John Linville <linville@tuxdriver.com>,
Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel()
Date: Sat, 25 Jul 2009 20:15:06 +0200 [thread overview]
Message-ID: <200907252015.07010.helmut.schaa@googlemail.com> (raw)
In-Reply-To: <1248541636.2554.12.camel@ct>
Am Samstag, 25. Juli 2009 schrieb Pavel Roskin:
> On Sat, 2009-07-25 at 15:06 +0200, Helmut Schaa wrote:
>
> > Hmm, I'd prefer to keep the decision state as entry and exit point to
> > the scan state machine. The patch below should also fix this issue
> > by returning back to the decision state after every skipped channel.
>
> The patch is working and I'm fine with it.
Great, thanks a lot.
> We should fix that in the
> tree as soon as possible, or it will stand in the way of bisection.
Yes, you're right.
> I forgot to mention that the oops was happening in x86_64 with rt61pci
> and US regulatory domain. The device only works in the 2.4 GHz range.
>
> > In the long run I would like to move the channel selection also to
> > the decision state in order to implement various improvements (like
> > scanning multiple channels in a row or reordering the channel list).
>
> I don't know the code enough, but two things surprised me:
>
> Lack of SCAN_DONE in mac80211_scan_state. We exit scanning through the
> "entry point".
I also thought of a separate state SCAN_DONE or something similar but
dropped that idea as the only thing this state would have to do is the
call to ieee80211_scan_completed. So, once the scan is finished we
just stay in SCAN_DECISION as long as the scan state machine gets poked
again by a start_scan call.
> Use of "unsigned long" for bitwise fields, such as queue_stop_reasons
> and scanning. This reminds me of the good old days where long was
> always 32 bit, but int wasn't. I think "unsigned int" should be enough,
> and you can annotate it with __bitwise to make sparse catch some
> misuses.
No objections :)
Helmut
next prev parent reply other threads:[~2009-07-25 18:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-25 5:18 [PATCH] mac80211: fix oops in ieee80211_scan_state_set_channel() Pavel Roskin
2009-07-25 8:54 ` Johannes Berg
2009-07-25 9:20 ` Helmut Schaa
2009-07-25 13:06 ` Helmut Schaa
2009-07-25 17:07 ` Pavel Roskin
2009-07-25 18:15 ` Helmut Schaa [this message]
2009-07-25 18:34 ` Helmut Schaa
2009-07-25 21:44 ` Pavel Roskin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200907252015.07010.helmut.schaa@googlemail.com \
--to=helmut.schaa@googlemail.com \
--cc=Larry.Finger@lwfinger.net \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=proski@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.