On Wed, Feb 05, 2003 at 09:28:49PM -0800, Jouni Malinen wrote:
> On Tue, Feb 04, 2003 at 11:36:37PM -0800, Joshua Kwan wrote:
>
> > However, a combination of running said kernel, hostap_cs, and X11 produces
> > this nasty infinite string of errors:
> >
> > bad: scheduling while atomic!
> > Call Trace:
>
> > [<d2948a30>] hfa384x_get_rid+0x36/0x2d6b7606 [hostap_cs]
>
> That will sleep, so it better not be called while in interrupt context
> or apparently also, while atomic with preemptive kernels(?).
>
> > [<d29388b5>] hostap_get_wireless_stats+0xa6/0x2d6c77f1 [hostap]
>
> That's the dev->get_wireless_stats handler. I have assumed that it is
> allowed to sleep there, but apparently that is not the case with Linux
> 2.5.x (at least with CONFIG_PREEMPT). I added a workaround for this into
> Host AP CVS, but you will not get signal quality statistics in that
> case. I'll do a proper fix if that function is indeed not allowed to
> sleep (e.g., by collecting the statistics before and just copying the
> values here).
>
> Jean, do you have a comment on this? This happens, e.g., when executing
> 'cat /proc/net/wireless':
>
> > [<c0168f45>] seq_printf+0x45/0x56
> > [<c02bd9b6>] wireless_seq_show+0xd6/0xf7
> > [<c0141dd5>] do_mmap_pgoff+0x40e/0x6dc
> > [<c0168a56>] seq_read+0x1c9/0x2ee
> > [<c014d20f>] vfs_read+0xbc/0x127
> > [<c014d496>] sys_read+0x3e/0x55
> > [<c01093cb>] syscall_call+0x7/0xb
I had an argument with David a few month ago on the subject
(you can ask him how it ended). I believe that it's not a good
practice to "schedule" in any of the ioctl, and that seem to also
apply to get_wireless_stats. On the other hand, you can perfectly take
a spinlock, disable irq and do your job.
For the ioctl, on the way down you grab the rtnetlink
semaphore, which mean that all ioctl and rtnetlink operation will be
blocked until you return. That's the reason I deprecated the old
APLIST ioctl and designed the SCAN support as a *pair* of ioctl (+ an
event).
For get_wireless_stats, check what I did in Orinoco. I
basically get (under spinlock) the stuff I can get immediately (RSSI),
start a request for the counters and return the result of the
*previous* request. That's the best I can think, because I don't want
to run permanently a thread that poll the counters and this way the
counter polling rate is adapted to what the user so.
Note that in your case, the issue is slightly different. I
believe that the probability of having the BAD busy is not that
high. In that case, just return the last polled value, and set the
updated flag to 0 (now you understand why there is an updated flag).
> Jouni Malinen PGP id EFC895FA
Have fun...
Jean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 07 2003 - 22:00:20 EST