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?
--
Ciao
Stefano
-
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
