netdev - Re: [wpan-next v2 8/9] net: mac802154: Explain the use of ieee802154_wake/stop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAB_54W6dCoEinhdq-HAQj0CQ9_wf-xK9ESOfvB6K4JMwHo7Vaw@mail.gmail.com>
Date:   Sun, 23 Jan 2022 15:56:22 -0500
From:   Alexander Aring <alex.aring@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Xue Liu <liuxuenetmail@...il.com>,
        Marcel Holtmann <marcel@...tmann.org>,
        Harry Morris <harrymorris12@...il.com>,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [wpan-next v2 8/9] net: mac802154: Explain the use of ieee802154_wake/stop_queue()

Hi,

On Thu, 20 Jan 2022 at 06:21, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> It is not straightforward to the newcomer that a single skb can be sent
> at a time and that the internal process is to stop the queue when
> processing a frame before re-enabling it. Make this clear by documenting
> the ieee802154_wake/stop_queue() helpers.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> ---
>  include/net/mac802154.h | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/include/net/mac802154.h b/include/net/mac802154.h
> index d524ffb9eb25..94b2e3008e77 100644
> --- a/include/net/mac802154.h
> +++ b/include/net/mac802154.h
> @@ -464,6 +464,12 @@ void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb,
>   * ieee802154_wake_queue - wake ieee802154 queue
>   * @hw: pointer as obtained from ieee802154_alloc_hw().
>   *
> + * Tranceivers have either one transmit framebuffer or one framebuffer for both
> + * transmitting and receiving. Hence, the core only handles one frame at a time

this is not a fundamental physical law, they might exist but not supported yet.

> + * for each phy, which means we had to stop the queue to avoid new skb to come
> + * during the transmission. The queue then needs to be woken up after the
> + * operation.
> + *
>   * Drivers should use this function instead of netif_wake_queue.

It's a must.

>   */
>  void ieee802154_wake_queue(struct ieee802154_hw *hw);
> @@ -472,6 +478,12 @@ void ieee802154_wake_queue(struct ieee802154_hw *hw);
>   * ieee802154_stop_queue - stop ieee802154 queue
>   * @hw: pointer as obtained from ieee802154_alloc_hw().
>   *
> + * Tranceivers have either one transmit framebuffer or one framebuffer for both
> + * transmitting and receiving. Hence, the core only handles one frame at a time
> + * for each phy, which means we need to tell upper layers to stop giving us new
> + * skbs while we are busy with the transmitted one. The queue must then be
> + * stopped before transmitting.
> + *
>   * Drivers should use this function instead of netif_stop_queue.
>   */
>  void ieee802154_stop_queue(struct ieee802154_hw *hw);

Same for stop, stop has something additional here... it is never used
by any driver because we do that on mac802154 layer. Simply, they
don't use this function.

Where is the fix here?

- Alex