Robert Watson wrote, On 1.9.2006 11:46:
> 
> 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

Here is the PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=102752

--
Vaclav Haisman

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to