Hi Alex, aahringo@xxxxxxxxxx wrote on Fri, 3 Jun 2022 21:50:15 -0400: > Hi, > > On Fri, Jun 3, 2022 at 1:55 PM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > > Hi Stefan, Alex, > > > > stefan@xxxxxxxxxxxxxxxxxx wrote on Wed, 1 Jun 2022 23:01:51 +0200: > > > > > Hello. > > > > > > On 01.06.22 05:30, Alexander Aring wrote: > > > > Hi, > > > > > > > > On Thu, May 19, 2022 at 11:06 AM Miquel Raynal > > > > <miquel.raynal@xxxxxxxxxxx> wrote: > > > >> > > > >> Hello, > > > >> > > > >> This series brings support for that famous synchronous Tx API for MLME > > > >> commands. > > > >> > > > >> MLME commands will be used during scan operations. In this situation, > > > >> we need to be sure that all transfers finished and that no transfer > > > >> will be queued for a short moment. > > > >> > > > > > > > > Acked-by: Alexander Aring <aahringo@xxxxxxxxxx> > > > > > > These patches have been applied to the wpan-next tree. Thanks! > > > > > > > There will be now functions upstream which will never be used, Stefan > > > > should wait until they are getting used before sending it to net-next. > > > > > > Indeed this can wait until we have a consumer of the functions before pushing this forward to net-next. Pretty sure Miquel is happy to finally move on to other pieces of his puzzle and use them. :-) > > > > Next part is coming! > > > > In the mean time I've experienced a new lockdep warning: > > > > All the netlink commands are executed with the rtnl taken. > > In my current implementation, when I configure/edit a scan request or a > > beacon request I take a scan_lock or a beacons_lock, so they may only > > be taken after the rtnl in this case, which leads to this sequence of > > events: > > - the rtnl is taken (by the net core) > > - the beacon's lock is taken > > > > But now in a beacon's work or an active scan work, what happens is: > > - work gets woken up > > - the beacon/scan lock is taken > > - a beacon/beacon-request frame is transmitted > > - the rtnl lock is taken during this transmission > > > > Lockdep then detects a possible circular dependency: > > [ 490.153387] CPU0 CPU1 > > [ 490.153391] ---- ---- > > [ 490.153394] lock(&local->beacons_lock); > > [ 490.153400] lock(rtnl_mutex); > > [ 490.153406] lock(&local->beacons_lock); > > [ 490.153412] lock(rtnl_mutex); So after a lot of thinking and different tries, I've opted for a slightly different approach regarding the rtnl being taken in the mlme tx path. What we want there is actually to be sure that the device won't be turned off during the transmission. Either this is done before, and the transmission will just return an error (and this is fine) or there is no ndo_close() call and we are actually safe. So I've actually introduced a mutex for serializing accesses to the "stop the device" section which actually what we care about. It works well, avoid keeping the rtnl in all the scan/beacons works (which would have been a crazy thing to do IMHO) and allows to keep a beacons/scan mutex for the configuration of these specific parts. I'll propose this change in the upcoming series. Thanks, Miquèl
