Re: memory clobber in rx path, maybe related to ath9k.

[Ben Greear <greearb@candelatech.com>]

On 10/11/2010 11:10 PM, Luis R. Rodriguez wrote:
> On Mon, Oct 11, 2010 at 8:27 PM, Ben Greear<greearb@candelatech.com>  wrote:

>> Another thing I was thinking about:  Maybe the queue of skbs and dma
>> addresses
>> in ath9k is getting corrupted by multiple VIFs trying to write at once?
>>   Maybe
>> some locking is needed in the xmit path?
>
> That was my second hunch. My first shot was to use spin_lock_irqsave()
> over the the uses of the rxbuf list and that seemed to help but I
> still managed to get a poison eventually. My next item to check for is
> of the permissibility of creating too much pressure to the point we
> end up looping over the rxbuf list and race against mac80211 free'ing
> a buffer. Will test that tomorrow if nothing else comes up creeping my
> priority queue.

This code looks weird to me.  One of the paprd branches
deletes the skb, the other doesn't appear to.  Neither
null out bf->bf_mpdu, which would appear to leave a dangling
pointer in at least the dev_kfree_skb_any() branch.

ath_tx_complete frees it's skb in all cases, so another
bf->bf_mpdu dangling pointer issue.

Maybe at the least we should null out bf->bf_mpdu when
skb is consumed?

static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
				struct ath_txq *txq, struct list_head *bf_q,
				struct ath_tx_status *ts, int txok, int sendbar)
{
	struct sk_buff *skb = bf->bf_mpdu;
	unsigned long flags;
	int tx_flags = 0;

	if (sendbar)
		tx_flags = ATH_TX_BAR;

	if (!txok) {
		tx_flags |= ATH_TX_ERROR;

		if (bf_isxretried(bf))
			tx_flags |= ATH_TX_XRETRY;
	}

	dma_unmap_single(sc->dev, bf->bf_dmacontext, skb->len, DMA_TO_DEVICE);

	if (bf->bf_state.bfs_paprd) {
		if (time_after(jiffies,
			       bf->bf_state.bfs_paprd_timestamp +
			       msecs_to_jiffies(ATH_PAPRD_TIMEOUT)))
			dev_kfree_skb_any(skb);
		else
			complete(&sc->paprd_complete);
	} else {
		ath_tx_complete(sc, skb, bf->aphy, tx_flags);
		ath_debug_stat_tx(sc, txq, bf, ts);
	}


>
>    Luis


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com