Linux-kernel mailing list archive 1997-48,: Re: GPF in tcp_recvmsg in 2.0.32 -- patch attached

# Re: GPF in tcp_recvmsg in 2.0.32 -- patch attached

Bill Hawes (whawes@star.net)
Thu, 04 Dec 1997 23:06:28 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Andries.Brouwer@cwi.nl: "Another crash"
- Previous message: Tall cool one: "Re: 2.0.32 freezes."
- Maybe in reply to: Philip Gladstone: "GPF in tcp_recvmsg in 2.0.32 -- patch attached"

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

- Next message: Andries.Brouwer@cwi.nl: "Another crash"
- Previous message: Tall cool one: "Re: 2.0.32 freezes."
- Maybe in reply to: Philip Gladstone: "GPF in tcp_recvmsg in 2.0.32 -- patch attached"