Em 21-12-2015 07:56, Xin Long escreveu:
On Sat, Dec 19, 2015 at 12:23 AM, Marcelo Ricardo Leitner
<marcelo.leitner@xxxxxxxxx> wrote:
On Fri, Dec 18, 2015 at 09:08:46AM -0500, Vlad Yasevich wrote:
On 12/17/2015 02:33 PM, Vlad Yasevich wrote:
On 12/17/2015 02:01 PM, Marcelo Ricardo Leitner wrote:
...
There is a check on sctp_cmd_delete_tcb() that avoids calling that on temp assocs on
listening sockets, but that condition is false due to the check on sk_shutdown so it will
call those two functions anyway.
The condition I am a bit concerned about is one thread waiting in sctp_wait_for_sndbuf
while another does an abort.
I think this is OK though. I need to look a bit more...
I think the only time this ends up biting us is if SO_SNDTIMEO was used and we ran out
of send buffer. It looks to me like schedule_timeout() will wait until timer expired and
depending on the timer value, you could wait quite a while.
With this path, since you don't transition state, the asoc->wait wait queue is never
notified and it could be hanging around for quite a while.
do you think it makes sense if we have this condition judgment there ?
if (waitqueue_active(&asoc->wait))
wake_up_interruptible(&asoc->wait);
No, because later if there is something else like this that we need to
handle on this situation, we will have to update both places and we may
forget to update one of them. It's better to just skip the packet
transmission/CMD_REPLY if chunk is NULL and let rest execute, as Vlad
suggested.
It will also be better for troubleshooting, as it may generate debug
msgs about the state transition.
Marcelo
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
