Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Fedor Pchelkin <pchelkin@ispras.ru>
To:     =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>,
        Kalle Valo <kvalo@kernel.org>
Cc:     Fedor Pchelkin <pchelkin@ispras.ru>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Zekun Shen <bruceshenzk@gmail.com>,
        Joe Perches <joe@perches.com>,
        "John W. Linville" <linville@tuxdriver.com>,
        linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Alexey Khoroshilov <khoroshilov@ispras.ru>,
        lvc-project@linuxtesting.org
Subject: Re: [PATCH v2] wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails
Date:   Wed,  4 Jan 2023 01:30:52 +0300
Message-Id: <20230103223052.303666-1-pchelkin@ispras.ru>
In-Reply-To: <875ydn49h2.fsf@toke.dk>
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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