On Thu, 31 Aug 2006, Václav Haisman wrote:
I found this in logs of 6.1 box that I admin this morning. The machine keeps running after that.
Indeed, there does appear to be a problem in the TCP socket option code with respect to performing copyin/copyout while holding the inpcb lock. This problem is not present in the IP layer socket option code. However, the code between HEAD and 6-STABLE here differs significantly, so fixing this will require different changes in the two branches. Could you file a problem report on this, and forward me the PR receipt? I'm on travel in India currently, with mixed connectivity, so it may be a little bit before I can get to fixing the problem.
In principle, the risk here is a deadlock, but the fix is a little complicated as if we release the lock there, the state of the TCP socket can change, so when the code picks up from the copyin/copyout, it needs to validate that the operation is still valid on the socket (i.e., the connection hasn't been reset during the system call -- perhaps while the application is blocked waiting on disk i/o for a paged out page that contains the socket option). This is very unlikely to trigger in practice, the warning there is quite conservative, but needs to be addressed properly.
Thanks for the report, Robert N M Watson Computer Laboratory University of Cambridge
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
