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
| ||
|
Message-ID: <20220113180709.0dade123@xps13> Date: Thu, 13 Jan 2022 18:07:09 +0100 From: Miquel Raynal <miquel.raynal@...tlin.com> To: Alexander Aring <alex.aring@...il.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>, Michael Hennerich <michael.hennerich@...log.com>, Harry Morris <h.morris@...coda.com>, Varka Bhadram <varkabhadram@...il.com>, Xue Liu <liuxuenetmail@...il.com>, Alan Ott <alan@...nal11.us>, 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>, "linux-wireless@...r.kernel.org Wireless" <linux-wireless@...r.kernel.org> Subject: Re: [wpan-next v2 18/27] net: mac802154: Handle scan requests Hi Alexander, alex.aring@...il.com wrote on Wed, 12 Jan 2022 17:44:02 -0500: > Hi, > > On Wed, 12 Jan 2022 at 12:33, Miquel Raynal <miquel.raynal@...tlin.com> wrote: > ... > > + return 0; > > +} > > diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c > > index c829e4a75325..40656728c624 100644 > > --- a/net/mac802154/tx.c > > +++ b/net/mac802154/tx.c > > @@ -54,6 +54,9 @@ ieee802154_tx(struct ieee802154_local *local, struct sk_buff *skb) > > struct net_device *dev = skb->dev; > > int ret; > > > > + if (unlikely(mac802154_scan_is_ongoing(local))) > > + return NETDEV_TX_BUSY; > > + > > Please look into the functions "ieee802154_wake_queue()" and > "ieee802154_stop_queue()" which prevent this function from being > called. Call stop before starting scanning and wake after scanning is > done or stopped. Mmmh all this is already done, isn't it? - mac802154_trigger_scan_locked() stops the queue before setting the promiscuous mode - mac802154_end_of_scan() wakes the queue after resetting the promiscuous mode to its original state Should I drop the check which stands for an extra precaution? But overall I think I don't understand well this part. What is a bit foggy to me is why the (async) tx implementation does: *Core* *Driver* stop_queue() drv_async_xmit() ------- \------> do something ------- calls ieee802154_xmit_complete() wakeup_queue() <--------/ So we actually disable the queue for transmitting. Why?? > Also there exists a race which exists in your way and also the one > mentioned above. There can still be some transmissions going on... We > need to wait until "all possible" tx completions are done... to be > sure there are really no transmissions going on. However we need to be > sure that a wake cannot be done if a tx completion is done, we need to > avoid it when the scan operation is ongoing as a workaround for this > race. > > This race exists and should be fixed in future work? Yep, this is true, do you have any pointers? Because I looked at the code and for now it appears quite unpractical to add some kind of flushing mechanism on that net queue. I believe we cannot use the netif interface for that so we would have to implement our own mechanism in the ieee802154 core. Thanks, Miquèl
Powered by blists - more mailing lists