> Hmm, so in the other error cases (if SKB allocation fails), we just > 'goto err' and call the receive handler for the packets already in > skb_pool. Why can't we do the same here? If SKB allocation fails, then the packets already in skb_pool should be processed by htc rx handler, yes. About the other two cases: if pkt_tag or pkt_len is invalid, then the whole SKB is considered invalid and dropped. That is what the statistics macros tell. So I think we should not process packets from skb_pool which are associated with a dropped SKB. And so just free them instead. > Also, I think there's another bug in that function, which this change > will make worse? Specifically, in the start of that function, > hif_dev->remain_skb is moved to skb_pool[0], but not cleared from > hif_dev itself. So if we then hit the invalid check and free it, the > next time the function is called, we'll get the same remain_skb pointer, > which has now been freed. Sorry, I missed that somehow. Moving 'hif_dev->rx_remain_len = index - MAX_RX_BUF_SIZE;' after "ath9k_htc: RX memory allocation error\n" error path should be done, too. hif_dev->rx_remain_len is zeroed after remain_skb processing, so we cannot reference hif_dev->remain_skb unless we explicitly allocate successfully a new one (making rx_remain_len non zero). > So I think we'll need to clear out hif_dev->remain_skb after moving it > to skb_pool. Care to add that as well? Yes, this must be done. I'll add it to patch v3.
