Re: [RFC Patch v2] Unify mpp/mesh_path handling for Mac 802.11s

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2014-05-28 at 12:34 +0200, Henning Rogge wrote:
> Hi,
> 
> I looked a little bit more into the 802.11s mesh code to see if there is still
> a chance for unifying some code without forcing the issue as the last patch
> did.
> 
> The result was the attached patch, which still needs one "if (mpp) ... else"
> block but unifies most of the code for mpp_path_add() and mesh_path_add().
> 
> If this is still too much I would suggest leaving the mesh_pathtbl code as it is.
> 
> While looking through the code I noticed that there seems to be no code-path
> that removes stall mpp_path entries (except for the removal of the mesh
> interface) ! Unless I overlooked something this would be a way to use up all
> existing memory of the kernel by sending it 802.11s packets with changing
> proxied addresses.
> 
> I have added an atomic counter to restrict the number of proxied paths
> (similar to the restriction of the mesh paths), but I am not convinced that
> this would be enough. There needs to be some timeout mechanism, but resetting
> the timeout of a MPP every times we receive an unicast from it sounds
> expensive.

Can you not do everything in one patch? :)

Also - I think reporting the MPPs to userspace like the mesh paths is
probably not a good idea? And I think that happens now since you didn't
touch the code in cfg?

johannes

johannes