From: Vladislav Yasevich <vladislav.yasevich@hp.com>
To: netdev@vger.kernel.org, davem@davemloft.net,
Wei Yongjun <yjwei@cn.fujitsu.com>,
Sridhar Samudrala <sri@us.ibm.com>,
linux-sctp@vger.kernel.org
Subject: Re: [PATCH] sctp: ABORT if receive queue is not empty while closing
Date: Thu, 30 Jun 2011 16:27:10 +0000 [thread overview]
Message-ID: <4E0CA3DE.7010205@hp.com> (raw)
In-Reply-To: <20110630161938.GD24074@canuck.infradead.org>
On 06/30/2011 12:19 PM, Thomas Graf wrote:
> On Thu, Jun 30, 2011 at 10:11:06AM -0400, Vladislav Yasevich wrote:
>> On 06/30/2011 09:31 AM, Thomas Graf wrote:
>>> On Wed, Jun 29, 2011 at 12:14:41PM -0400, Vladislav Yasevich wrote:
>>>> Right. The lack of ABORT from the receive of data is a bug. I was trying to point out
>>>> that instead of modified the sender of data to send the ABORT, you modify the receiver
>>>> to send the ABORT when it is being closed while having data queued.
>>>
>>> Is this what you had in mind?
>>
>> Almost. It could really be a simple true/false condition about recvqueue or inqueue
>> being non-empty. If that's the case, trigger abort.
>
> What would be the advantage of that?
>
Wrt to true/false, it's simpler to test for non-empty then it is to go through and count
the data (but I perfectly ok with either way). WRT to testing the inqueue, as you stated,
not everything may be in receive queue.
-vlad
WARNING: multiple messages have this Message-ID (diff)
From: Vladislav Yasevich <vladislav.yasevich@hp.com>
To: netdev@vger.kernel.org, davem@davemloft.net,
Wei Yongjun <yjwei@cn.fujitsu.com>,
Sridhar Samudrala <sri@us.ibm.com>,
linux-sctp@vger.kernel.org
Subject: Re: [PATCH] sctp: ABORT if receive queue is not empty while closing socket
Date: Thu, 30 Jun 2011 12:27:10 -0400 [thread overview]
Message-ID: <4E0CA3DE.7010205@hp.com> (raw)
In-Reply-To: <20110630161938.GD24074@canuck.infradead.org>
On 06/30/2011 12:19 PM, Thomas Graf wrote:
> On Thu, Jun 30, 2011 at 10:11:06AM -0400, Vladislav Yasevich wrote:
>> On 06/30/2011 09:31 AM, Thomas Graf wrote:
>>> On Wed, Jun 29, 2011 at 12:14:41PM -0400, Vladislav Yasevich wrote:
>>>> Right. The lack of ABORT from the receive of data is a bug. I was trying to point out
>>>> that instead of modified the sender of data to send the ABORT, you modify the receiver
>>>> to send the ABORT when it is being closed while having data queued.
>>>
>>> Is this what you had in mind?
>>
>> Almost. It could really be a simple true/false condition about recvqueue or inqueue
>> being non-empty. If that's the case, trigger abort.
>
> What would be the advantage of that?
>
Wrt to true/false, it's simpler to test for non-empty then it is to go through and count
the data (but I perfectly ok with either way). WRT to testing the inqueue, as you stated,
not everything may be in receive queue.
-vlad
next prev parent reply other threads:[~2011-06-30 16:27 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-29 13:57 [PATCH] sctp: Enforce maximum retransmissions during shutdown Thomas Graf
2011-06-29 13:57 ` Thomas Graf
2011-06-29 14:20 ` Vladislav Yasevich
2011-06-29 14:20 ` Vladislav Yasevich
2011-06-29 14:36 ` Thomas Graf
2011-06-29 14:36 ` Thomas Graf
2011-06-29 14:58 ` Vladislav Yasevich
2011-06-29 14:58 ` Vladislav Yasevich
2011-06-29 15:48 ` Thomas Graf
2011-06-29 15:48 ` Thomas Graf
2011-06-29 16:14 ` Vladislav Yasevich
2011-06-29 16:14 ` Vladislav Yasevich
2011-06-30 8:49 ` Thomas Graf
2011-06-30 8:49 ` Thomas Graf
2011-06-30 14:08 ` Vladislav Yasevich
2011-06-30 14:08 ` Vladislav Yasevich
2011-06-30 16:17 ` Thomas Graf
2011-06-30 16:17 ` Thomas Graf
2011-07-04 13:50 ` [PATCHv2] sctp: Enforce retransmission limit " Thomas Graf
2011-07-04 13:50 ` Thomas Graf
2011-07-06 7:24 ` David Miller
2011-07-06 7:24 ` David Miller
2011-07-06 12:15 ` Neil Horman
2011-07-06 12:15 ` Neil Horman
2011-07-06 13:16 ` Thomas Graf
2011-07-06 13:16 ` Thomas Graf
2011-07-06 14:19 ` Neil Horman
2011-07-06 14:19 ` Neil Horman
2011-07-06 13:42 ` Vladislav Yasevich
2011-07-06 13:42 ` Vladislav Yasevich
2011-07-06 14:18 ` Thomas Graf
2011-07-06 14:18 ` Thomas Graf
2011-07-06 14:31 ` Vladislav Yasevich
2011-07-06 14:31 ` Vladislav Yasevich
2011-07-06 15:49 ` Thomas Graf
2011-07-06 15:49 ` Thomas Graf
2011-07-06 16:23 ` Vladislav Yasevich
2011-07-06 16:23 ` Vladislav Yasevich
2011-07-06 21:58 ` Thomas Graf
2011-07-06 21:58 ` Thomas Graf
2011-07-07 10:28 ` [PATCHv3] " Thomas Graf
2011-07-07 10:28 ` Thomas Graf
2011-07-07 13:36 ` Vladislav Yasevich
2011-07-07 13:36 ` Vladislav Yasevich
2011-07-07 21:09 ` David Miller
2011-07-07 21:09 ` David Miller
2011-06-30 13:31 ` [PATCH] sctp: ABORT if receive queue is not empty while closing Thomas Graf
2011-06-30 13:31 ` [PATCH] sctp: ABORT if receive queue is not empty while closing socket Thomas Graf
2011-06-30 14:11 ` [PATCH] sctp: ABORT if receive queue is not empty while closing Vladislav Yasevich
2011-06-30 14:11 ` [PATCH] sctp: ABORT if receive queue is not empty while closing socket Vladislav Yasevich
2011-06-30 16:19 ` [PATCH] sctp: ABORT if receive queue is not empty while closing Thomas Graf
2011-06-30 16:19 ` [PATCH] sctp: ABORT if receive queue is not empty while closing socket Thomas Graf
2011-06-30 16:27 ` Vladislav Yasevich [this message]
2011-06-30 16:27 ` Vladislav Yasevich
2011-07-08 10:57 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing Thomas Graf
2011-07-08 10:57 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing socket Thomas Graf
2011-07-08 13:49 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing Vladislav Yasevich
2011-07-08 13:49 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing socket Vladislav Yasevich
2011-07-08 14:29 ` [PATCHv2] sctp: ABORT if receive queue is not empty while Thomas Graf
2011-07-08 14:29 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing socket Thomas Graf
2011-07-08 14:37 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is Thomas Graf
2011-07-08 14:37 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is not empty while closing socket Thomas Graf
2011-07-08 16:37 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering David Miller
2011-07-08 16:37 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is not empty while closing socket David Miller
2011-07-08 16:43 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue Vladislav Yasevich
2011-07-08 16:43 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is not empty while closing socket Vladislav Yasevich
2011-07-08 16:53 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering David Miller
2011-07-08 16:53 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is not empty while closing socket David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E0CA3DE.7010205@hp.com \
--to=vladislav.yasevich@hp.com \
--cc=davem@davemloft.net \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sri@us.ibm.com \
--cc=yjwei@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.