Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Limit queue lengths for batman and broadcast packets

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

Hey Sven,

you are right, this might be indeed a problem. I'll send an updated patch
which removes the problem by employing atomic_add_unless().

Marek also pointed out that global variables are not very pretty as we are
moving all the global stuff into bat_priv to allow multiple mesh soft 
interfaces later. However I'd first send the patch with globals as is and
move them later in another patch.

best regards,
	Simon

On Mon, Apr 05, 2010 at 01:21:36PM +0200, Sven Eckelmann wrote:
> 
> It should be possible to have multiple events accessing these functions at the 
> same time, or am I wrong?
> 
> Just say we have following situation (queue is full; full == 1):
> 
>  * bcast comes in and we start add_bcast_packet_to_list  and
>    dec_test(left) == 1 -> damn, no room left for us
> -> for easier understanding: someone steals our cpu or the processing is
>     otherwise interleaved with following
>  * another bcast comes in and wants attention (left is now 0):
>    dec_test(left) == 0 (because left is now -1... or 0xfff....fff). Lets enqueue
>    it and do the rest
>  * first bcast continues and and does atomic_inc(left) -> now it is 0
>  * now a storm of bcasts comes in and all do atomic_dec_and_test... each one
>     will be accepted because left is already zero and needs a looooong time to
>     be 0 again (or enough bcast packets were processed from the queue to get
>    positive again)
> 
> I am not 100% sure if this really can happen, but I thought that it was a hard 
> requirement for TCP port passed processor selection for parallel processing of 
> incoming packets on multicore/multiprocessor architectures. 
> 
> Best regards,
> 	Sven



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]