mcr at sandelman.ottawa.on.ca
Thu Feb 16 10:29:51 CET 2006
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Ankit" == Ankit Desai <ankit at elitecore.com> writes:
Ankit> yes as i said i just tried to remove the recursion in
Ankit> code. Other than that as i understand the two functions
Ankit> ensures that the task is performed uninterruptible.
>> In my copy of the code, I do not agree that pfkey_remove_socket()
>> is called with a lock.
Ankit> pfkey_release takes lock "write_lock_bh(&pfkey_sock_lock)"
My copy doesn't do that.
Ankit> and then calls "pfkey_destroy_socket(sk)" which in turn calls
Ankit> " pfkey_remove_socket(sk)", that is what i meant by
Ankit> pfkey_remove_socket is called after taking lock.
So, you are saying that we have a call graph that looks like:
Ankit> so the best i could think was to implement the lock before
Ankit> pfkey_insert_socket and remove the locking unlocking from
Ankit> of_grab() and _ungrab(). Best would be to remove locking
Ankit> before remove_socket is called but i am very much a newbie to
Ankit> understand the complexity and implications of that.
Please don't under-estimate yourself.
Your analysis is very good so far! New eyes are often better than
eyes that read what they expect.
You need to probably move the call to pfkey_sock_list_grab() out a bit
in the call tree.
I have placed my copy of pfkey_v2.c at
Please try using git to get a copy of our #public.
I don't think that my tree has any changes relative to that.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys
-----END PGP SIGNATURE-----
More information about the Dev