Re: mwifiex: no wr_port available

[James Cameron <quozl@laptop.org>]

On Tue, May 13, 2014 at 08:54:53PM -0700, Bing Zhao wrote:
> Hi James,
> [...]
> > You may be interested that rd_port also has possible leak when skb
> > cannot be allocated.  See mwifiex_process_int_status:
> > 
> > 		skb = dev_alloc_skb(rx_len);
> > 		if (!skb)
> > 			return -1;
> > 
> > We have a hack in OLPC production arm-3.5 kernel which restores
> > rd_port bit, restores int_status.
> > 
> > http://dev.laptop.org/git/olpc-kernel/commit/?h=arm-3.5&id=59fcaf10cce5bbdc370ec1c262b12aeb66ed1dca
> 
> The rd_port/int_status change looks correct. But what issue did you
> encounter prior to applying the change "cache the read bitmap at the
> time of the interrupt rather than when the interrupt status bits are
> handled"?

No specific issue, instead ensuring that all effects are rolled back.
The effects of a call to mwifiex_process_int_status that returned -1
due to dev_alloc_skb fail were:

- change to curr_rd_port,

- bits cleared in mp_rd_bitmap,

So both effects were rolled back.  Perhaps not needed?

I'm not recommending this as the right solution, because the patch
caused CPU loop during memory exhaustion, the interrupt came
back immediately.  I added a hack to reduce impact of that:

http://dev.laptop.org/git/olpc-kernel/commit/?h=arm-3.5&id=491188ebd4721f3c8804b7fa626e63d6fdd2ed09

I did not have the experience to find out _why_ we could not
dev_alloc_skb, but at least was able to let the driver continue rather
than timeout.

-- 
James Cameron
http://quozl.linux.org.au/