Re: Fix for thread+network crashes in 2.0/2.1?

A.N.Kuznetsov (
Sun, 1 Mar 1998 16:46:26 +0300

In article <> you wrote:
: However, if there is a second instance of struct sock that refers the
: inode or if destruction of struct sock is delayed, there are still references
: to the inode (indirectly by means of sock::sleep or sock::socket) are still
: references. But i_count doesn't know about that that and the i_node may be
: freed leaving wild pointers in a struckt sock instance.

Before "struct socket" is destoyed all the references from transport
records (struct sock) are invalidated. If x25 does not make it,
it is bug in x25.

: What I've done in af_x25.c was increasing the socket inode's i_count each time
: when a new struct sock::sleep is set and doing an iput just before
: sk_free() is called. This cures the at least the symptoms (even if I remove
: the i_count++ and iput() from net/socket.c).

Seems, it is wrong approach. If you failed to destroy a "struct sock" during
sock_release by any reason, you cannot iput from timer. iput is not soft
interrupt safe (at least, it was not earlier before major VFS changes)
So that the problem is solved in another way.

Just set sk->dead=1, and that's all. Is it simple?

Actually, I must say one thing, which apparently remained unnoticed
It was me who moved sock->wait to private inode area in early 2.1.
In 2.0 it was located in inode->wait (which normally used for inode locking).
The reason for this change was the following: if sk->sleep points
to inode->wait, VFS maintains this wait queue until inode really destroyed.
It results in random crashes, but they was too rare to debug them :-)
So that I moved this pointer to private area and crashes became to occur
every day :-) :-) It allowed to catch all invalid sock->release in IPv4
and IPv6 (they did not sk->dead=1 sometimes or even made
wake_up_interruptible(sk->sleep) directly without checking sk->dead).

Apparently, another protocols should be cleaned too.
Directories ipv4,ipv6,unix,packet and netlink are clean, but
I do not know anything about another ones.

Alexey Kuznetsov

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to