Stephens, Allan <[EMAIL PROTECTED]> wrote:
[copy_to_user with sk lock held]
> 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.
I asked because the 'locking policy' comment in tipc_socket.c
gave the impression that locks would always be released before processes
need to sleep, so i wanted to make sure that these copy_from/to cases
were intentional. Thanks for the clarification.
Actually, reading the locking policy again, the "need to sleep"
probably implies "explicit" waits -- i missed that. Sorry.
> 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.
Well... what is the purpose of that CAP_()-check if it
can be circumvented?
Better to not have it at all than a known-to-be-insufficient solution.
YMMV...
Disclaimer: I do not understand the implications and/or intentions of that
check.
> 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.
The obvious solution is to not copy that data a second time :)
But yes, it looks difficult to do this right. I neither see
an easy way to do such a check in msg_build or to tell msg_build to skip
that part of the user buffer.
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
