- 07 3月, 2008 6 次提交
-
-
由 Luis Carlos Cobo 提交于
Postponing the deletion is not really useful anymore. Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis Carlos Cobo 提交于
This avoids dereferencing a no longer existing struct mesh_path. Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Luis pointed out that this path is going to be freed right away anyway so there's no point in assigning next_hop. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Cc: Luis Carlos Cobo <luisca@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
This makes access to the STA hash table/list use RCU to protect against freeing of items. However, it's not a true RCU, the copy step is missing: whenever somebody changes a STA item it is simply updated. This is an existing race condition that is now somewhat understandable. This patch also fixes the race key freeing vs. STA destruction by making sure that sta_info_destroy() is always called under RTNL and frees the key. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
This needs to be exported because rate control algorithms can be modular. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis Carlos Cobo 提交于
The mesh path table associates destinations with the next hop to reach them. The table is a hash of linked lists protected by rcu mechanisms. Every mesh path contains a lock to protect the mesh path state. Each outgoing mesh frame requires a look up into this table. Therefore, the table it has been designed so it is not necessary to hold any lock to find the appropriate next hop. If the path is determined to be active within a rcu context we can safely dereference mpath->next_hop->addr, since it holds a reference to the sta next_hop. After a mesh path has been set active for the first time it next_hop must always point to a valid sta. If this is not possible the mpath must be deleted or replaced in a RCU safe fashion. Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-