Le jeudi 22 avril 2010 à 16:36 +0200, Eric Dumazet a écrit : > If one hash slot is under attack, then there is a bug somewhere. > > If we cannot avoid this, we can fallback to a secure mode at the second > retry, and take the spinlock. > > Tis way, most of lookups stay lockless (one pass), and some might take > the slot lock to avoid the possibility of a loop. > > I suspect a bug elsewhere, quite frankly ! > > We have a chain that have an end pointer that doesnt match the expected > one. > On normal situation, we always finish the lookup : 1) If we found the thing we were looking at. 2) We get the list end (item not found), we then check if it is the expected end. It is _not_ the expected end only if some writer deleted/inserted an element in _this_ chain during our lookup. Because our lookup is lockless, we then have to redo it because we might miss the object we are looking for. If we can do the 'retry' a 10 times, it means the attacker was really clever enough to inject new packets (new conntracks) at the right moment, in the right hash chain, and this sounds so higly incredible that I cannot believe it at all :) -- 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
