From: Kalle Valo <kvalo@codeaurora.org>
To: Erik Stromdahl <erik.stromdahl@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 6/6] ath10k: sdio: replace skb_trim with explicit set of skb->len
Date: Tue, 01 Oct 2019 15:21:26 +0300 [thread overview]
Message-ID: <875zl864hl.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <deca77d1-f171-e0cd-b571-89c2f8bafc87@gmail.com> (Erik Stromdahl's message of "Mon, 15 Apr 2019 17:11:27 +0200")
+ johannes
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> On 4/12/19 3:17 PM, Kalle Valo wrote:
>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>>
>>> This patch fixes a bug with padding of the skb data buffer.
>>> Since skb_trim can only be used to reduce the skb len, it is useless when
>>> we pad (increase the length of) the skb. Instead we must set skb->len
>>> directly.
>>>
>>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/sdio.c | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
>>> index 3eb241cb8a25..989e3f563f3d 100644
>>> --- a/drivers/net/wireless/ath/ath10k/sdio.c
>>> +++ b/drivers/net/wireless/ath/ath10k/sdio.c
>>> @@ -1496,7 +1496,12 @@ static int ath10k_sdio_hif_tx_sg(struct ath10k *ar, u8 pipe_id,
>>> skb = items[i].transfer_context;
>>> padded_len = ath10k_sdio_calc_txrx_padded_len(ar_sdio,
>>> skb->len);
>>> - skb_trim(skb, padded_len);
>>> + /* FIXME: unsure if just extending the skb len is the right
>>> + * thing to do since we might read outside the skb->data
>>> + * buffer. But we really don't want to realloc the skb just to
>>> + * pad the length.
>>> + */
>>> + skb->len = padded_len;
>>
>> Good catch! But I don't think you can modify skb->len directly like
>> that. There is skb_pad() but that doesn't change skb->len, so that most
>> likely needs more changes. So maybe skb_put() is the safest here?
>>
> I have tried a few different solutions for this, but none seems to be
> bullet proof.
>
> skb_pad() raises a BUG() if there is not enough space in skb->data.
>
> The best candidate so far has been skb_put_padto(). It pads and reallocates
> the skb if needed.
>
> The problem is that it also cause a panic if there is more than one reference
> to the skb (skb_shared() returns true).
>
> Some of the management frames via nl80211 have a refcount of 2.
> In this case it is not possible to free and allocate the skb since there are
> other users/references.
>
> I think I will have to make some kind of solution where I copy the content of
> the skb to an internal buffer instead.
Sorry for the late reply, I see that you also tried a different (and
more complex) approach here:
https://patchwork.kernel.org/patch/10906011/
In my opinion the cleanest approach would be to add extra_tx_tailroom to
struct ieee80211_hw, similarly like we have extra_tx_headroom, and that
way ath10k could easily add the padding with skb_pad(). Or what do you
think?
Of course I don't know what Johannes thinks as it would need several
changes in mac80211, but at least struct net_device has needed_tailroom
as well. And I would imagine that there is some other hardware which
needs to do padding like this, or are ath10k SDIO devices really the
first mac80211 drivers needing tailroom?
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Erik Stromdahl <erik.stromdahl@gmail.com>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [PATCH 6/6] ath10k: sdio: replace skb_trim with explicit set of skb->len
Date: Tue, 01 Oct 2019 15:21:26 +0300 [thread overview]
Message-ID: <875zl864hl.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <deca77d1-f171-e0cd-b571-89c2f8bafc87@gmail.com> (Erik Stromdahl's message of "Mon, 15 Apr 2019 17:11:27 +0200")
+ johannes
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> On 4/12/19 3:17 PM, Kalle Valo wrote:
>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>>
>>> This patch fixes a bug with padding of the skb data buffer.
>>> Since skb_trim can only be used to reduce the skb len, it is useless when
>>> we pad (increase the length of) the skb. Instead we must set skb->len
>>> directly.
>>>
>>> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/sdio.c | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
>>> index 3eb241cb8a25..989e3f563f3d 100644
>>> --- a/drivers/net/wireless/ath/ath10k/sdio.c
>>> +++ b/drivers/net/wireless/ath/ath10k/sdio.c
>>> @@ -1496,7 +1496,12 @@ static int ath10k_sdio_hif_tx_sg(struct ath10k *ar, u8 pipe_id,
>>> skb = items[i].transfer_context;
>>> padded_len = ath10k_sdio_calc_txrx_padded_len(ar_sdio,
>>> skb->len);
>>> - skb_trim(skb, padded_len);
>>> + /* FIXME: unsure if just extending the skb len is the right
>>> + * thing to do since we might read outside the skb->data
>>> + * buffer. But we really don't want to realloc the skb just to
>>> + * pad the length.
>>> + */
>>> + skb->len = padded_len;
>>
>> Good catch! But I don't think you can modify skb->len directly like
>> that. There is skb_pad() but that doesn't change skb->len, so that most
>> likely needs more changes. So maybe skb_put() is the safest here?
>>
> I have tried a few different solutions for this, but none seems to be
> bullet proof.
>
> skb_pad() raises a BUG() if there is not enough space in skb->data.
>
> The best candidate so far has been skb_put_padto(). It pads and reallocates
> the skb if needed.
>
> The problem is that it also cause a panic if there is more than one reference
> to the skb (skb_shared() returns true).
>
> Some of the management frames via nl80211 have a refcount of 2.
> In this case it is not possible to free and allocate the skb since there are
> other users/references.
>
> I think I will have to make some kind of solution where I copy the content of
> the skb to an internal buffer instead.
Sorry for the late reply, I see that you also tried a different (and
more complex) approach here:
https://patchwork.kernel.org/patch/10906011/
In my opinion the cleanest approach would be to add extra_tx_tailroom to
struct ieee80211_hw, similarly like we have extra_tx_headroom, and that
way ath10k could easily add the padding with skb_pad(). Or what do you
think?
Of course I don't know what Johannes thinks as it would need several
changes in mac80211, but at least struct net_device has needed_tailroom
as well. And I would imagine that there is some other hardware which
needs to do padding like this, or are ath10k SDIO devices really the
first mac80211 drivers needing tailroom?
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2019-10-01 12:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 19:08 [PATCH 0/6] ath10k: SDIO and high latency patches from Silex Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-09 19:08 ` [PATCH 1/6] ath10k: use clean packet headers Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-12 12:54 ` Kalle Valo
2019-04-12 12:54 ` Kalle Valo
2019-04-09 19:08 ` [PATCH 2/6] ath10k: high latency fixes for beacon buffer Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-09 19:08 ` [PATCH 3/6] ath10k: sdio: read RX packets in bundles Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-12 13:08 ` Kalle Valo
2019-04-12 13:08 ` Kalle Valo
2019-04-09 19:08 ` [PATCH 4/6] ath10k: sdio: add MSDU ID allocation in HTT TX path Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-09 19:08 ` [PATCH 5/6] ath10k: sdio: add missing error check Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-09 19:08 ` [PATCH 6/6] ath10k: sdio: replace skb_trim with explicit set of skb->len Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-12 13:17 ` Kalle Valo
2019-04-12 13:17 ` Kalle Valo
2019-04-15 15:11 ` Erik Stromdahl
2019-04-15 15:11 ` Erik Stromdahl
2019-10-01 12:21 ` Kalle Valo [this message]
2019-10-01 12:21 ` Kalle Valo
2019-10-01 12:49 ` Johannes Berg
2019-10-01 12:49 ` Johannes Berg
2019-04-12 12:36 ` [PATCH 0/6] ath10k: SDIO and high latency patches from Silex Kalle Valo
2019-04-12 12:36 ` Kalle Valo
2019-04-14 16:53 ` Erik Stromdahl
2019-04-14 16:53 ` Erik Stromdahl
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=875zl864hl.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=erik.stromdahl@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/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.