malloc(M_WAITOK) of "g_bio", forcing M_NOWAIT with non-sleepable locks held:

[Robert Watson]

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