linux.git/net/mac80211/offchannel.c, branch v6.7

wifi: mac80211: fix a expired vs. cancel race in roc

2023-10-23T09:45:17+00:00

When the remain on channel is removed at the time it should
have expired, we have a race: the driver could be handling
the flow of the expiration while mac80211 is cancelling
that very same remain on channel request.

This wouldn't be problem in itself, but since mac80211
can send the next request to the driver in the cancellation
flow, we can get to the following situation:

           CPU0                             CPU1
expiration of roc in driver
ieee80211_remain_on_channel_expired()
                                         Cancellation of the roc
schedules a worker (hw_roc_done)
                                         Add next roc
hw_roc_done_wk runs and ends
the second roc prematurely.

Since, by design, there is only one single request sent to the
driver at a time, we can safely assume that after the cancel()
request returns from the driver, we should not handle any worker
that handles the expiration of the request.

Cancel the hw_roc_done worker after the cancellation to make
sure we start the next one with a clean slate.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230928172905.4e4469be20ac.Iab0525f5cc4698acf23eab98b8b1eec02099cde0@changeid
Signed-off-by: Johannes Berg

wifi: mac80211: Do not force off-channel for management Tx with MLO

2023-09-11T10:33:54+00:00

When user space transmits a management frame it is expected to use
the MLD addresses if the connection is an MLD one. Thus, in case
the management Tx is using the MLD address and no channel is configured
off-channel should not be used (as one of the active links would be used).

Signed-off-by: Ilan Peer 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230827135854.73c8efce252f.Ie4b0a842debb24ef25c5e6cb2ad69b9f46bc4b2a@changeid
Signed-off-by: Johannes Berg

wifi: cfg80211: remove wdev mutex

2023-09-11T09:27:23+00:00

Since we're now protecting everything with the wiphy mutex
(and were really using it for almost everything before),
there's no longer any real reason to have a separate wdev
mutex. It may feel better, but really has no value.

Signed-off-by: Johannes Berg

wifi: mac80211: reduce iflist_mtx

2023-09-11T09:27:22+00:00

We now hold the wiphy mutex everywhere that we use or
needed the iflist_mtx, so we don't need this mutex any
more in mac80211. However, drivers may also iterate,
and in some cases (e.g. mt76) do so from high-priority
contexts. Thus, keep the mutex around but remove its
usage in mac80211 apart from those driver-visible parts
that are still needed.

Most of this change was done automatically with spatch,
with the parts that are still needed as described above
reverted manually.

Signed-off-by: Johannes Berg

wifi: mac80211: remove local->mtx

2023-09-11T09:27:22+00:00

We now hold the wiphy mutex everywhere that we use or
needed the local->mtx, so we don't need this mutex any
more. Remove it.

Most of this change was done automatically with spatch.

Signed-off-by: Johannes Berg

wifi: mac80211: move dynamic PS to wiphy work

2023-09-11T09:27:20+00:00

Along with everything else, move the dynamic PS work
to be a wiphy work, to simplify locking later.

Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg

wifi: mac80211: move offchannel works to wiphy work

2023-09-11T09:27:20+00:00

Make the offchannel works wiphy works to have the
wiphy locked for executing them.

Signed-off-by: Johannes Berg

wifi: mac80211: pass roc->sdata to drv_cancel_remain_on_channel()

2023-06-14T10:20:08+00:00

In suspend flow "sdata" is NULL, destroy all roc's which are started.
pass "roc->sdata" to drv_cancel_remain_on_channel() to avoid NULL
dereference and destroy that roc

Signed-off-by: Anjaneyulu 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20230608163202.c678187a308c.Ic11578778655e273931efc5355d570a16465d1be@changeid
Signed-off-by: Johannes Berg

wifi: mac80211: expand ieee80211_mgmt_tx() for MLO

2022-07-22T12:28:35+00:00

There are a couple of new things that should be possible
with MLO:
 * selecting the link to transmit to a station by link ID,
   which a previous patch added to the nl80211 API
 * selecting the link by frequency, similarly
 * allowing transmittion to an MLD without specifying any
   channel or link ID, with MLD addresses

Enable these use cases. Also fix the address comparison
in client mode to use the AP (MLD) address.

Signed-off-by: Johannes Berg

wifi: mac80211: RCU-ify link/link_conf pointers

2022-07-15T09:43:14+00:00

Since links can be added and removed dynamically, we need to
somehow protect the sdata->link[] and vif->link_conf[] array
pointers from disappearing when accessing them without locks.
RCU-ify the pointers to achieve this, which requires quite a
bit of rework.

Signed-off-by: Johannes Berg