Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit b5c34f66 authored by Johannes Berg's avatar Johannes Berg Committed by John W. Linville
Browse files

mac80211: fix some key comments and code 



The key documentation is slightly out of date, fix
that. Also, the list entry in the key struct is no
longer used that way, so list_del_init() isn't
necessary any more there.

Finally, ieee80211_key_link() is no longer invoked
under RCU read lock, but rather with an appropriate
station lock held.

Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
parent cc721287

net/mac80211/key.c

+17 −21
Original line number Original line Diff line number Diff line
@@ -30,19 +30,20 @@ 
 * keys and per-station keys. Since each station belongs to an interface,

 * keys and per-station keys. Since each station belongs to an interface,

 * each station key also belongs to that interface.

 * each station key also belongs to that interface.

 *

 *

 * Hardware acceleration is done on a best-effort basis, for each key

 * Hardware acceleration is done on a best-effort basis for algorithms

 * that is eligible the hardware is asked to enable that key but if

 * that are implemented in software,  for each key the hardware is asked

 * it cannot do that they key is simply kept for software encryption.

 * to enable that key for offloading but if it cannot do that the key is

 * There is currently no way of knowing this except by looking into

 * simply kept for software encryption (unless it is for an algorithm

 * debugfs.

 * that isn't implemented in software).

 * There is currently no way of knowing whether a key is handled in SW

 * or HW except by looking into debugfs.

 *

 *

 * All key operations are protected internally.

 * All key management is internally protected by a mutex. Within all

 *

 * other parts of mac80211, key references are, just as STA structure

 * Within mac80211, key references are, just as STA structure references,

 * references, protected by RCU. Note, however, that some things are

 * protected by RCU. Note, however, that some things are unprotected,

 * unprotected, namely the key->sta dereferences within the hardware

 * namely the key->sta dereferences within the hardware acceleration

 * acceleration functions. This means that sta_info_destroy() must

 * functions. This means that sta_info_destroy() must remove the key

 * remove the key which waits for an RCU grace period.

 * which waits for an RCU grace period.

 */

 */





static const u8 bcast_addr[ETH_ALEN] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };

static const u8 bcast_addr[ETH_ALEN] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
@@ -279,13 +280,8 @@ static void __ieee80211_key_replace(struct ieee80211_sub_if_data *sdata, 
							 new->conf.keyidx);

							 new->conf.keyidx);

	}

	}





	if (old) {

	if (old)

		/*

		list_del(&old->list);

		 * We'll use an empty list to indicate that the key

		 * has already been removed.

		 */

		list_del_init(&old->list);

	}

}

}





struct ieee80211_key *ieee80211_key_alloc(u32 cipher, int idx, size_t key_len,

struct ieee80211_key *ieee80211_key_alloc(u32 cipher, int idx, size_t key_len,
@@ -420,8 +416,8 @@ int ieee80211_key_link(struct ieee80211_key *key, 
			struct sta_info *ap;

			struct sta_info *ap;





			/*

			/*

			 * We're getting a sta pointer in,

			 * We're getting a sta pointer in, so must be under

			 * so must be under RCU read lock.

			 * appropriate locking for sta_info_get().

			 */

			 */





			/* same here, the AP could be using QoS */

			/* same here, the AP could be using QoS */