From: Zach Brown <[EMAIL PROTECTED]>
Date: Mon, 10 Apr 2006 09:49:34 -0700
>
> > I got tired of waiting for Zach to cook up a patch so I tossed
> > the following into my tree :-)
>
> Haha, sorry, I didn't realize I was racing the clock :). We disappeared
> this weekend.
No worries. Linus came
> I got tired of waiting for Zach to cook up a patch so I tossed
> the following into my tree :-)
Haha, sorry, I didn't realize I was racing the clock :). We disappeared
this weekend.
That matches what I came up with, but did we miss the IPv6 part? Here's
that half if you still need it.
Herbe
On Sun, Apr 09, 2006 at 10:44:24PM -0700, David S. Miller wrote:
>
> I got tired of waiting for Zach to cook up a patch so I tossed
> the following into my tree :-)
Thanks David :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://go
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 08 Apr 2006 13:46:25 +1000
> David S. Miller <[EMAIL PROTECTED]> wrote:
> > From: Zach Brown <[EMAIL PROTECTED]>
> > Date: Fri, 07 Apr 2006 16:59:01 -0700
> >
> >> b) Just calculate the hashes under the lock, we're already doing lots of
> >> work th
David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Zach Brown <[EMAIL PROTECTED]>
> Date: Fri, 07 Apr 2006 16:59:01 -0700
>
>> b) Just calculate the hashes under the lock, we're already doing lots of
>> work there anyway.
>
> I think this is the best way to go. Then we don't need to think
> abou
> I think this is the best way to go. Then we don't need to think
> about it, and frankly I think the "recheck hash rnd after getting
> lock" idea would turn out to be more expensive :)
OK :). I'll throw that together..
- z
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
From: Zach Brown <[EMAIL PROTECTED]>
Date: Fri, 07 Apr 2006 16:59:01 -0700
> b) Just calculate the hashes under the lock, we're already doing lots of
> work there anyway.
I think this is the best way to go. Then we don't need to think
about it, and frankly I think the "recheck hash rnd after get
I noticed that ip_find() calculates the hash bucket for the incoming
fragment using ipfrag_hash_rnd outside the ipfrag_lock. So it can race
with ipfrag_secret_rebuild() and end up putting a frag in the previous
bucket instead of the new bucket that ipfrag_secret_rebuild() has put
the previous frag
