>I'm curious about the other part. Changing prune_queue()'s behavior
The other part was bogus. Excuse me. It was only a guess and was wrong.
Now I know exactly which is the problem.
>For example, if we change tcp_data() to do the wakeup even if
>prune_queue() returns < 0 solve the select problem here?
The wakeup is completly unrelated. The problem is that we are not able to
get data in the receiver.
>If so just send me a patch which introduces a local variable 'ret' for
>the return value, and a goto to the wakeup code if prune_queue() says
>to toss the packet, and I'll put it in as this seems to be a safe
>change.
No the change you are proposing will fix nothing and is completly
unrelated. Even if we would pass select() we would then deadlock in
recv(2). I'll send you my real fix that I finished now though (hoping
you'll agree that I did a right choice but that choice looks the only safe
choice to avoid a receiver deadlocking to me).
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/