Hi Jamal: Great! White space comments only this time, almost :) No need for these prototypes since they're already in xfrm.h. How about letting these guys stay where they are? The move was necessary
Good catch. Changed - dont see what the harm was as they were in that patch though. [..] [..] There was really not even a need for that hold given the likelihood of anything like this happening. Any
Please see below. All I wanted was to leave these lines as is so that they didn't appear in the patch at all (except as conext) :) When reviewing patches the most annoying thing is to see things move
Ok, fair enough. It annoys me too when i review patches ;-> So i will fix this before final. Goody - now we can have Masahide run his full test. cheers, jamal
Just one more thing, can you please remove the _bh's that you added to the read_lock for xfrm_km_list? It turns out that they're not necessary since the write_lock()'s are only held in process contex
If you only take write_lock() from process context, only the write_lock()'s need BH disabling. read_lock() takers can then nest arbitrarily, BH or not.
Hello Jamal, I've tested normal cases below with the latest patch and it works fine. I think you can go ahead. tested cases: o netlink (using iproute2 "ip xfrm monitor" to confirm it) - add/del/flush
[..] Thanks a lot Masahide! Ok, heres the patch i will shoot to Dave if no further comments. cheers, jamal Attachment: ipsec-event-take2-5 Description: Text document
Thanks for your great work Jamal. Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home
I have a feeling that Dave is not following this thread. All along we have been testing against 2.6.11.6; I just tested against -rc2 and found the patch applies with some fuzz. I fixed that as well a
Impressive ;-> After the 10th email it seemed to me only Herbert and myself would still be reading this ;-> Did you see the bit about Elvis? ;-> cheers, jamal
Hi Jamal: Great! White space comments only this time, almost :) No need for these prototypes since they're already in xfrm.h. How about letting these guys stay where they are? The move was necessary
Herbert, Good catch. Changed - dont see what the harm was as they were in that patch though. [..] [..] There was really not even a need for that hold given the likelihood of anything like this happen
Please see below. All I wanted was to leave these lines as is so that they didn't appear in the patch at all (except as conext) :) When reviewing patches the most annoying thing is to see things move