All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fedor Pchelkin <pchelkin@ispras.ru>
To: "Toke Høiland-Jørgensen" <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	[thread overview]
Message-ID: <20230103223052.303666-1-pchelkin@ispras.ru> (raw)
In-Reply-To: <875ydn49h2.fsf@toke.dk>

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

  reply	other threads:[~2023-01-03 22:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-28 22:40 [PATCH] wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails Fedor Pchelkin
2023-01-02 10:52 ` Toke Høiland-Jørgensen
2023-01-03 14:29   ` Fedor Pchelkin
2023-01-03 20:18     ` Toke Høiland-Jørgensen
2023-01-03 14:30   ` [PATCH v2] " Fedor Pchelkin
2023-01-03 21:03     ` Toke Høiland-Jørgensen
2023-01-03 22:30       ` Fedor Pchelkin [this message]
2023-01-03 23:38         ` Toke Høiland-Jørgensen
2023-01-04 12:36           ` [PATCH v3] " Fedor Pchelkin
2023-01-04 14:50             ` Toke Høiland-Jørgensen
2023-01-17 11:53             ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230103223052.303666-1-pchelkin@ispras.ru \
    --to=pchelkin@ispras.ru \
    --cc=bruceshenzk@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=joe@perches.com \
    --cc=khoroshilov@ispras.ru \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=lvc-project@linuxtesting.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=toke@toke.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.