On Sat, 30 Jul 2005, Herbert Xu wrote: > > I've finished my patch based on your work. Unfortunately the result > isn't as clean as I would've liked. However, it does point out a couple > of problems with your patch more clearly. Perhaps you could work on > those and come up with a better solution. > > One problem is that you're not incrementing cp->seq for the first > fragment. This could lead to a significant deviation from the > desired maximum window.
I think you're referring, for example, when there would be several fragment queues (ipqs) sharing an ipc. Yes, the sequence count would get out of whack in this case. Easy enough to fix. > ... > I agree. Unfortunately, leaving ipc entires around opens us to > a potential DoS attack. By spoofing source addresses the attacker > could fill up our memory with these ipc entries. Sure, it's a possibility. > ... Granted we could > prune them in ip_evictor. However, that does add significant > complexity. > Depending on your definition of "significant" :-) > So overall I'd say that the kmalloc cost is small enough that this > isn't worth it. > > BTW, if we do this, then we really need to account the memory > consumed by the ipc structures so that they're kept in check. > I've done that in my patch. > Good. (There are comments about this in my patches.) > > I thought about this point, but I dislike reusing the same > > structure for such different purposes, so left this unchanged. > > I'm still undecided on this one. For now I've chosen to put them > in the same table as I couldn't see a lot of simplifications with > storing them separately. But I'm willing to be convinced otherwise > with a smaller ip_fragment.c :) > > > Another thing that I changed is to use only saddr to key ipc. > If we receive a long sequence of fragments from the same host, then > any fragment we have which are not part of that sequence are likely > to have been lost, regardless of the destination/protocol of packets > in that sequence. No argument there. -- Arthur - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
