On Mon, 2007-12-10 at 09:08 +0100, Stefano Brivio wrote:
> On Sun, 09 Dec 2007 23:25:50 +0100
> Mattias Nissler <mattias.nissler@xxxxxx> wrote:
>
> > > static void *rate_control_pid_alloc(struct ieee80211_local *local)
> > > {
> > > struct rc_pid_info *pinfo;
> > > + struct rc_pid_rateinfo *rinfo;
> > > + struct ieee80211_hw_mode *mode;
> > > + int i, j, tmp;
> > > + bool s;
> > >
> > > pinfo = kmalloc(sizeof(*pinfo), GFP_ATOMIC);
> > > + if (!pinfo)
> > > + return NULL;
> > > +
> > > + mode = local->oper_hw_mode;
> > > + rinfo = kmalloc(sizeof(*rinfo) * mode->num_rates, GFP_ATOMIC);
> > > + if (!rinfo) {
> > > + kfree(pinfo);
> > > + return NULL;
> > > + }
> >
> > What if the mode is changed? Have you checked the rate control algorithm
> > gets reinitialized? If not, we're scheduling a crash here, when
> > mode->num_rates changes.
>
> After a discussion on IRC with Michael (Wu), we came to the conclusion that
> it doesn't make sense for mode->num_rates to change, because:
> 1) if the AP drops supported rates, it'll drop the association as well,
> then everything here will be destroyed and created again;
> 2) that can be changed in userspace, but we couldn't figure out a scenario
> where it would make any sense. Johannes, any comments? Wouldn't it make
> sense to just forbid to change this in userspace?
I don't agree. For example, what if you have some broken 802.11b only
hardware that you desperately need to get going, but it freaks out on
802.11g encoded frames. Now if your AP is hostapd on a Linux machine,
you'll want to change the mode. Hence, also the number of available
rates change.
Moreover, I think we can do better than just disallowing changes to the
rate set, don't you think?
Mattias
-
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
