On Tue, Nov 14, 2017 at 08:52:56PM +0800, Xin Long wrote:
> On Tue, Nov 14, 2017 at 8:43 PM, Neil Horman wrote:
> > On Mon, Nov 13, 2017 at 11:29:49PM +0800, Xin Long wrote:
> >> On Mon, Nov 13, 2017 at 10:46 PM, Neil Horman
> >> wrote:
> >> > On
On Tue, Nov 14, 2017 at 8:43 PM, Neil Horman wrote:
> On Mon, Nov 13, 2017 at 11:29:49PM +0800, Xin Long wrote:
>> On Mon, Nov 13, 2017 at 10:46 PM, Neil Horman wrote:
>> > On Mon, Nov 13, 2017 at 12:43:50PM +0800, Xin Long wrote:
>> >> Now in
On Mon, Nov 13, 2017 at 11:29:49PM +0800, Xin Long wrote:
> On Mon, Nov 13, 2017 at 10:46 PM, Neil Horman wrote:
> > On Mon, Nov 13, 2017 at 12:43:50PM +0800, Xin Long wrote:
> >> Now in sctp_sendmsg sctp_wait_for_sndbuf could schedule out without
> >> holding sock sk. It
On Mon, Nov 13, 2017 at 10:46 PM, Neil Horman wrote:
> On Mon, Nov 13, 2017 at 12:43:50PM +0800, Xin Long wrote:
>> Now in sctp_sendmsg sctp_wait_for_sndbuf could schedule out without
>> holding sock sk. It means the current asoc can be freed elsewhere,
>> like when
On Mon, Nov 13, 2017 at 12:43:50PM +0800, Xin Long wrote:
> Now in sctp_sendmsg sctp_wait_for_sndbuf could schedule out without
> holding sock sk. It means the current asoc can be freed elsewhere,
> like when receiving an abort packet.
>
> If the asoc is just created in sctp_sendmsg and
Now in sctp_sendmsg sctp_wait_for_sndbuf could schedule out without
holding sock sk. It means the current asoc can be freed elsewhere,
like when receiving an abort packet.
If the asoc is just created in sctp_sendmsg and sctp_wait_for_sndbuf
returns err, the asoc will be freed again due to