On Thu, Apr 10, 2008 at 05:47:21PM +0200, Johannes Berg wrote:
> On Thu, 2008-04-10 at 12:43 -0300, Marcelo Tosatti wrote:
> > On Tue, Apr 01, 2008 at 08:48:48AM +0200, Holger Schurig wrote:
> > > > Won't this call block? You can't block in the get_wireless
> > > > handler (it holds the rtnl lock). See wext_handle_ioctl.
> > >
> > > Yes, this blocks.
> > >
> > > So you mean that when I cannot get a current RSSI value at this
> > > time I have to re-use some old value?
> >
> > All I mean is that get_wireless_stats should not schedule() because it
> > holds the rtnl_lock. You get ugly hangs doing that.
>
> Of course you can schedule with the rtnl held. It's a mutex, after all.
True, my bad. The problem is:
dev_seq_start
read_lock(&dev_base_lock)
wireless_seq_show
wireless_seq_printf_stats
get_wireless_stats
dev->wireless_handlers->get_wireless_stats
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
