linux-stable.git/net/mac80211/offchannel.c, branch linux-4.7.y

mac80211: avoid ROC during hw restart

2016-01-14T10:10:14+00:00

Defer ROC requests during hw restart, as the driver
might not be fully configured in this stage (e.g.
channel contexts were not added yet)

Signed-off-by: Eliad Peller 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg

mac80211: fix remain-on-channel cancellation

2016-01-14T10:10:10+00:00

Ilan's previous commit 1b894521e60c ("mac80211: handle HW
ROC expired properly") neglected to take into account that
hw_begun was now always set in the software implementation
as well as the offloaded case.

Fix hw_begun to only apply to the offloaded case to make
the check in Ilan's commit safe and correct.

Reported-by: Jouni Malinen 
Signed-off-by: Johannes Berg

mac80211: recalculate SW ROC only when needed

2016-01-14T10:10:09+00:00

The current (new) code recalculates the new work timeout
for software remain-on-channel whenever any item started.
In two of the callers of ieee80211_handle_roc_started(),
this is completely pointless since they're for hardware
and will skip the recalculation entirely; it's necessary
only in the case of having just added a new item to the
list, as in the last remaining case the recalculation had
just been done.

This last case, however, is also problematic - if one of
the items on the list actually expires during the recalc
the list iteration outside becomes corrupted and crashes.

Fix this by moving the recalculation to the only place
where it's required.

Signed-off-by: Johannes Berg

mac80211: handle HW ROC expired properly

2015-12-07T10:06:37+00:00

In case of HW ROC, when the driver reports that the ROC expired,
it is not sufficient to purge the ROCs based on the remaining
time, as it possible that the device finished the ROC session
before the actual requested duration.

To handle such cases, in case of ROC expired notification from
the driver, complete all the ROCs which are marked with hw_begun,
regardless of the remaining duration.

Signed-off-by: Ilan Peer 
Signed-off-by: Johannes Berg

mac80211: reject zero cookie in mgmt-tx/roc cancel

2015-12-04T13:43:32+00:00

When cancelling, you can cancel "any" (first in list) mgmt-tx
or remain-on-channel operation by using the value 0 for the
cookie along with the *opposite* operation, i.e.
 * cancel the first mgmt-tx by cancelling roc with 0 cookie
 * cancel the first roc by cancelling mgmt-tx with 0 cookie

This isn't really that bad since userspace should only pass
cookies that we gave it, but could lead to hard-to-debug
issues so better prevent it and reject zero values since we
never hand those out.

Signed-off-by: Johannes Berg

mac80211: rewrite remain-on-channel logic

2015-12-04T13:43:32+00:00

Jouni found a bug in the remain-on-channel logic: when a short item
is queued, a long item is combined with it extending the original
one, and then the long item is deleted, the timeout doesn't go back
to the short one, and the short item ends up taking a long time. In
this case, this showed as blocking scan when running two test cases
back to back - the scan from the second was delayed even though all
the remain-on-channel items should long have been gone.

Fixing this with the current data structures turns out to be a bit
complicated, we just remove the long item from the dependents list
right now and don't recalculate the timeouts.

There's a somewhat similar bug where we delete the short item and
all the dependents go with it; to fix this we'd have to move them
from the dependents to the real list.

Instead of trying to do that, rewrite the code to not have all this
complexity in the data structures: use a single list and allow more
than one entry in it being marked as started. This makes the code a
bit more complex, the worker needs to understand that it might need
to just remove one of the started items, while keeping the device
off-channel, but that's not more complicated than the nested data
structures.

This then fixes both issues described, and makes it easier to also
limit the overall off-channel time when combining.

TODO: as before, with hardware remain-on-channel, deleting an item
after combining results in cancelling them all - we can keep track
of the time elapsed and only cancel after that to fix this.

Signed-off-by: Johannes Berg

mac80211: simplify ack_skb handling

2015-12-04T13:43:32+00:00

Since the cookie is assigned inside ieee80211_make_ack_skb()
now, we no longer need to return the ack_skb as the cookie
and can simplify the function's return and the callers. Also
rename it to ieee80211_attach_ack_skb() to more accurately
reflect its purpose.

Signed-off-by: Johannes Berg

mac80211: move off-channel/mgmt-tx code to offchannel.c

2015-12-04T13:43:32+00:00

This is quite a bit of code that logically depends here since
it has to deal with all the remain-on-channel logic.

Signed-off-by: Johannes Berg

mac80211: fix mgmt-tx abort cookie and leak

2015-12-04T13:43:32+00:00

If a mgmt-tx operation is aborted before it runs, the wrong
cookie is reported back to userspace, and the ack_skb gets
leaked since the frame is freed directly instead of freeing
it using ieee80211_free_txskb(). Fix that.

Fixes: 3b79af973cf4 ("mac80211: stop using pointers as userspace cookies")
Signed-off-by: Johannes Berg

mac80211: use bool argument to ieee80211_send_nullfunc

2015-09-29T13:56:52+00:00

Instead of int with 0/1, use bool with false/true for the
powersave argument to ieee80211_send_nullfunc().

Signed-off-by: Johannes Berg