Re: GPF in tcp_recvmsg in 2.0.32 -- patch attached

[Bill Hawes]

Philip Gladstone wrote:
> 
> It turns out that there is a nasty problem with cloned processes
> in that one process (aka thread) can close a socket while another
> is operating on it. For example, say one thread is blocked in a
> tcp_recvmsg call, and another thread closes the socket. The first
> thing that happens is that the kernel panics. The attached patch
> will fix that problem, but I suspect that it is the wrong
> solution.
> 
> I don't know what the right solution is, but I'm hoping that
> the assembled wisdom will think of something.

Hi Philip,
Unfortunately I think this is a generic problem with having a files
structure shared among clone processes. I've been pondering this since
Ingo posted a report about problems with using CLONE_FILES a few days
ago, and I don't see any way that the files can be shared safely unless
the set of files is totally static (i.e. none are ever closed.)

The root of the problem is that when accessing a file, the fd is checked
to be in a valid range, then a check is made for a file in that slot.
After that, the process uses the file pointer without bumping the use
count. So if any other clone decides to close the file, you've got
trouble (as you noted.)

The only general short-term fix I've thought of would be to just copy
the files structure even if CLONE_FILES is specified.

Regards,
Bill