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/ -- 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
