netdev - Re: [PATCH v3 27/41] net: mac802154: Introduce a tx queue flushing mechanism

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]

Date:   Tue, 18 Jan 2022 18:16:59 -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>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        "linux-wireless@...r.kernel.org Wireless" 
        <linux-wireless@...r.kernel.org>,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Michael Hennerich <michael.hennerich@...log.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Varka Bhadram <varkabhadram@...il.com>,
        Xue Liu <liuxuenetmail@...il.com>, Alan Ott <alan@...nal11.us>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v3 27/41] net: mac802154: Introduce a tx queue flushing mechanism

Hi,

On Tue, 18 Jan 2022 at 13:14, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> Hi Alexander,
>
> alex.aring@...il.com wrote on Mon, 17 Jan 2022 17:43:49 -0500:
>
> > Hi,
> >
> > On Mon, 17 Jan 2022 at 06:55, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> > ...
> > >
> > >         /* stop hardware - this must stop RX */
> > > diff --git a/net/mac802154/ieee802154_i.h b/net/mac802154/ieee802154_i.h
> > > index 0291e49058f2..37d5438fdb3f 100644
> > > --- a/net/mac802154/ieee802154_i.h
> > > +++ b/net/mac802154/ieee802154_i.h
> > > @@ -122,6 +122,7 @@ extern struct ieee802154_mlme_ops mac802154_mlme_wpan;
> > >
> > >  void ieee802154_rx(struct ieee802154_local *local, struct sk_buff *skb);
> > >  void ieee802154_xmit_sync_worker(struct work_struct *work);
> > > +void ieee802154_sync_tx(struct ieee802154_local *local);
> > >  netdev_tx_t
> > >  ieee802154_monitor_start_xmit(struct sk_buff *skb, struct net_device *dev);
> > >  netdev_tx_t
> > > diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
> > > index de5ecda80472..d1fd2cc67cbe 100644
> > > --- a/net/mac802154/tx.c
> > > +++ b/net/mac802154/tx.c
> > > @@ -48,6 +48,7 @@ void ieee802154_xmit_sync_worker(struct work_struct *work)
> > >
> > >         kfree_skb(skb);
> > >         atomic_dec(&local->phy->ongoing_txs);
> > > +       wake_up(&local->phy->sync_txq);
> >
> > if (atomic_dec_and_test(&hw->phy->ongoing_txs))
> >       wake_up(&hw->phy->sync_txq);
>
> As we test this condition in the waiting path I assumed it was fine to
> do it this way, but the additional check does not hurt, so I'll add it.

it's just a nitpick... to avoid scheduling and this triggers a
checking if the condition is true in cases we know it can't....

although we can talk about this because ongoing_txs should never be
higher than 1... so any atomic_dec() should make the condition true...

- Alex