A N Kuznetsov <kuznet@ms2.inr.ac.ru> writes:
>> sock->wait wait are supressed. But what happens if the task is
>> awoken up by means of another wait queue (likely to occur in
>> select, as this is made for waiting waiting on multiple
>> different fd's).
> Protocols do not sleep (with one exception - netlink) on socket
> owned by another process, so that get_fd()...put_fd()
Well, I was thinking of a task creating a socket, then doing a fork,
and then both tasks doing a select involving the common socket and some
non-common files. Then the poll tables of both tasks would both refer
the shared socket's sock->wait, won't they?
As with the x.25 problem: I've checked by means of printk()'s at the very end
of x25_release(), that the socket's wait queue is empty before exiting
and the the socket->inode->i_count is always 2. Nevertheless,
it crashes with corrupted sock->wait wait queue in select()'s free_wait().
The select also monitors a pty file descriptor. Maybe the problem is not
caused by af_x25 but by somethink else. Are there certain kinds of bugs
that are known to likly cause socket wait queue corruptions?
Henner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu