Hi Florian: You are correct in your observation that certain TIPC socket routines may sleep while holding the socket lock; the code is written this way with the intent of ensuring that the state of the socket does not change in the middle of an operation. My expectation is that a sleeping copy_to_user() will only delay other threads from starting up new operations on the socket for a short period of time. (This is in contrast to the case where a receive operation sleeps because there is no data in the socket's receive queue; since this condition may continue indefinitely the TIPC socket code is careful to release the socket lock, and then rechecks the state of the socket when it awakes to ensure it has an up-to-date view of the socket.) Please let me know if I'm wrong in this expectation ... a prolonged delay in copy_to_user() might require me to rethink things (although I'm not sure it's a big issue, since most TIPC users seem to only use a single thread of control on any given socket anyway).
There may be a risk that the data validated by dest_name_check() may be out-dated by the time it is actually copied into the message created by TIPC, but the risk of this seems minimal. If someone wants to initiate a send operation on a socket, and then have a second thread of control modify the buffer area being used in the send, then they've created a race condition that seems beyond TIPC's control to overcome. Again, I can't imagine that this is something that typical users will want to do ... but if I'm wrong about this, please let me know! Regards, Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Florian Westphal Sent: Tuesday, June 05, 2007 3:52 PM To: [email protected] Subject: [tipc-discussion] tipc may sleep with sk lock hold Hello everyone, whilst reading tipc_socket.c (1.7.3) I noticed that that TIPC calls functions which might sleep with the sk lock hold. Examples: - recv_msg and recv_stream calling copy_to_user() after lock_sock(sk) - send_msg calling dest_name_check (which calls copy_from_user) dest_name_check() looks even worse becuase this seems to be some kind of security check, but the actual data read is discarded after evaluation. If this check passes -- is there any guarantee that the userdata is still the same when we call tipc_msg_build()? I don't think there is, but maybe i misinterpret things. Comments? Thanks, Florian ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
