On 16-10-25 06:34 AM, Marcelo Ricardo Leitner wrote:
On Tue, Oct 25, 2016 at 05:05:41PM +0800, Xin Long wrote:
in case [1], user can't see the ENOMEM, ENOMEM is more like
Thing is, it may lead to duplicate messages in Application layer, as the
msg that was errored out may have been actually
On Tue, Oct 25, 2016 at 05:05:41PM +0800, Xin Long wrote:
> >> in case [1], user can't see the ENOMEM, ENOMEM is more like
> >> a internal err.
> >>
> >
> > Still not clear. Are you saying, say an old kernel like 3.11 would
> > not return the user ENOMEN for the use case[1] you fixed? I am not
> >
>> in case [1], user can't see the ENOMEM, ENOMEM is more like
>> a internal err.
>>
>
> Still not clear. Are you saying, say an old kernel like 3.11 would
> not return the user ENOMEN for the use case[1] you fixed? I am not
> talking post your fix.
Sorry for confusing you.
3.11 would return the u
On 16-10-24 02:30 AM, Xin Long wrote:
in case [1], user can't see the ENOMEM, ENOMEM is more like
a internal err.
Still not clear. Are you saying, say an old kernel like 3.11 would
not return the user ENOMEN for the use case[1] you fixed? I am not
talking post your fix.
in case [2], user wi
On Mon, Oct 24, 2016 at 02:30:07PM +0800, Xin Long wrote:
> [1]
> >> This patch doesn't ignore all the ENOMEN cases, only after msg is
> >> enqueued in out queue/send queue, in the lower layer, when alloc
> >> new skb and copy data from old skb, if it fails to alloc new skb, sctp
> >> will ignore t
[1]
>> This patch doesn't ignore all the ENOMEN cases, only after msg is
>> enqueued in out queue/send queue, in the lower layer, when alloc
>> new skb and copy data from old skb, if it fails to alloc new skb, sctp
>> will ignore this ENOMEM, as this msg will be taken care by retransmit
>> mechanis
On 16-10-23 02:20 PM, Xin Long wrote:
This patch doesn't ignore all the ENOMEN cases, only after msg is
enqueued in out queue/send queue, in the lower layer, when alloc
new skb and copy data from old skb, if it fails to alloc new skb, sctp
will ignore this ENOMEM, as this msg will be taken care
> I think the specific use case this patch addresses
> seems to have bitten us in an older kernel sctp (3.11?).
> A send() on a loaded network box caused the skb to
> alloc in what appears to be this code path and fail (problem
> is intermittent, so not 100% sure). errno seen was ENOMEM.
> Unfortun
Sorry - I didnt mean to remove the mailing lists.
Please reply to this email instead.
cheers,
jamal
Forwarded Message
Subject: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not
return ENOMEM err back in sctp_packet_transmit
Date: Sun, 23 Oct 2016 11:03:36 -0400
As David and Marcelo's suggestion, ENOMEM err shouldn't return back to
user in transmit path. Instead, sctp's retransmit would take care of
the chunks that fail to send because of ENOMEM.
This patch is only to do some release job when alloc_skb fails, not to
return ENOMEM back any more.
Besides,
10 matches
Mail list logo
