From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamal Hadi Salim Subject: Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit Date: Mon, 24 Oct 2016 08:38:45 -0400 Message-ID: <369b7b2c-d1fb-5dd2-30b9-4f54400aa770@mojatatu.com> References: <2fa21505-59c2-fb8b-6e89-11fccc953d25@mojatatu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "netdev@vger.kernel.org" , Marcelo Ricardo Leitner , Vlad Yasevich , Daniel Borkmann , David Miller , "linux-sctp@vger.kernel.org" , Michael Tuexen , Eric Dumazet , Brenda Butler , gabor@mojatatu.com To: Xin Long Return-path: Received: from mail-yw0-f196.google.com ([209.85.161.196]:33280 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935973AbcJXMit (ORCPT ); Mon, 24 Oct 2016 08:38:49 -0400 Received: by mail-yw0-f196.google.com with SMTP id w3so9112380ywg.0 for ; Mon, 24 Oct 2016 05:38:49 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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 will got the ENOMEM, they should resend this msg, > It's the the general case mentioned-above > I am trying to see if we can avoid backporting this fix to 3.11. In [1], is ENOMEM propagated to user space (dont talk about your fix, I mean pre-your-fix). > here sctp's behavior is actually same with tcp's, in tcp, tcp_transmit_skb > also may fail to alloc skb, but it doesn't return any err to user, just like > sctp_packet_transmit. That's why I don't think we should change something > in manpage, as here sctp is consistent with tcp now. > > make sense ? No ;-> The manpage is bad. Go look at it. In the case of ENOBUFS or EMSGSIZE it is clear what needs to be done. If the answer is _on ENOMEM_ user must resend then thats what we need to say. cheers, jamal From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamal Hadi Salim Date: Mon, 24 Oct 2016 12:38:45 +0000 Subject: Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack Message-Id: <369b7b2c-d1fb-5dd2-30b9-4f54400aa770@mojatatu.com> List-Id: References: <2fa21505-59c2-fb8b-6e89-11fccc953d25@mojatatu.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Xin Long Cc: "netdev@vger.kernel.org" , Marcelo Ricardo Leitner , Vlad Yasevich , Daniel Borkmann , David Miller , "linux-sctp@vger.kernel.org" , Michael Tuexen , Eric Dumazet , Brenda Butler , gabor@mojatatu.com 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 will got the ENOMEM, they should resend this msg, > It's the the general case mentioned-above > I am trying to see if we can avoid backporting this fix to 3.11. In [1], is ENOMEM propagated to user space (dont talk about your fix, I mean pre-your-fix). > here sctp's behavior is actually same with tcp's, in tcp, tcp_transmit_skb > also may fail to alloc skb, but it doesn't return any err to user, just like > sctp_packet_transmit. That's why I don't think we should change something > in manpage, as here sctp is consistent with tcp now. > > make sense ? No ;-> The manpage is bad. Go look at it. In the case of ENOBUFS or EMSGSIZE it is clear what needs to be done. If the answer is _on ENOMEM_ user must resend then thats what we need to say. cheers, jamal