Hi Pablo, On Thu, 23 Feb 2012, Pablo Neira Ayuso wrote: > On Tue, Feb 21, 2012 at 04:06:59PM +0100, Jozsef Kadlecsik wrote: > > Or do I miss something else here? > > I just noticed one problem. > > With your approach, we may lose race if one packet inserts same conntrack > entry while we're adding one conntrack. Thus resulting in two conntracks > with the same tuples in the table. Yes, you're right, that race condition is possible. > One possible solution would be to check if it already exists before > adding it to the list, but this will add too many extra cycles for > each conntrack that is added via ctnetlink. Actually, netfilter for normal conntrack entries does the same in __nf_conntrack_confirm. So entries added via ctnetlink would not be penalized if the same checking were added to ctnetlink_create_conntrack in the locked region. Shall I send a patch over the previous one? > I'm also considering disabling early_drop from ctnetlink and to return > -ENOMEM instead. Not sure if it makes sense the early drop mechanism > via ctnetlink. If we hit ENOMEM from user-space while adding one new > conntrack, we can iterate over the table and delete conntrack based on > some criteria, then retry. There are advantages in early drop too: it's a good dice playing, which can be sufficient in many cases. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
