All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xin Long <lucien.xin@gmail.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	Vlad Yasevich <vyasevic@redhat.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	David Miller <davem@davemloft.net>,
	"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>,
	Michael Tuexen <Michael.Tuexen@lurchi.franken.de>,
	Eric Dumazet <edumazet@google.com>,
	Brenda Butler <bjb@mojatatu.com>,
	gabor@mojatatu.com
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 02:20:51 +0800	[thread overview]
Message-ID: <CADvbK_ci-aaX6-mgXTgR0mJm9ww7+48DmXH+m5R+-0PyMDH16g@mail.gmail.com> (raw)
In-Reply-To: <daecd6b5-47cf-c5de-90f5-445e0038dfce@mojatatu.com>

> 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.
> Unfortunately the manpage for sendxxx sucks.
> It says "no memory available".
> [We'll fix the manpage if there is an appropriate answer].
>
> Two questions:
> a) Seems like we can safely ignore ENOMEM in user space
> at least for this use case. i.e the kernel will retry and
> eventually send this message. Is there any other scenario
> where we have to worry about ENOMEM showing up in user space?
>
> b) What is the general view of what sendXXX reaction oughta
> be from user space in presence of ENOMEM?
>
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
mechanism, it's reasonable and also safe, user can't feel that.

But for the cases before enqueue, like in sctp_sendmsg,
sctp_datamsg_from_user may return ENOMEM, this err will return
back to user, and can't be ignored.

So I don't really think we should change something in manpage, what
do you think ? maybe a little explanation there is also nice, :)

WARNING: multiple messages have this Message-ID (diff)
From: Xin Long <lucien.xin@gmail.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	Vlad Yasevich <vyasevic@redhat.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	David Miller <davem@davemloft.net>,
	"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>,
	Michael Tuexen <Michael.Tuexen@lurchi.franken.de>,
	Eric Dumazet <edumazet@google.com>,
	Brenda Butler <bjb@mojatatu.com>,
	gabor@mojatatu.com
Subject: Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack
Date: Sun, 23 Oct 2016 18:20:51 +0000	[thread overview]
Message-ID: <CADvbK_ci-aaX6-mgXTgR0mJm9ww7+48DmXH+m5R+-0PyMDH16g@mail.gmail.com> (raw)
In-Reply-To: <daecd6b5-47cf-c5de-90f5-445e0038dfce@mojatatu.com>

> 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.
> Unfortunately the manpage for sendxxx sucks.
> It says "no memory available".
> [We'll fix the manpage if there is an appropriate answer].
>
> Two questions:
> a) Seems like we can safely ignore ENOMEM in user space
> at least for this use case. i.e the kernel will retry and
> eventually send this message. Is there any other scenario
> where we have to worry about ENOMEM showing up in user space?
>
> b) What is the general view of what sendXXX reaction oughta
> be from user space in presence of ENOMEM?
>
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
mechanism, it's reasonable and also safe, user can't feel that.

But for the cases before enqueue, like in sctp_sendmsg,
sctp_datamsg_from_user may return ENOMEM, this err will return
back to user, and can't be ignored.

So I don't really think we should change something in manpage, what
do you think ? maybe a little explanation there is also nice, :)

  reply	other threads:[~2016-10-23 18:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-23 15:03 send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_t Jamal Hadi Salim
2016-10-23 15:32 ` Fwd: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit Jamal Hadi Salim
2016-10-23 15:32   ` Fwd: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pac Jamal Hadi Salim
2016-10-23 18:20   ` Xin Long [this message]
2016-10-23 18:20     ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack Xin Long
2016-10-23 19:52     ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit Jamal Hadi Salim
2016-10-23 19:52       ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack Jamal Hadi Salim
2016-10-24  6:30       ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit Xin Long
2016-10-24  6:30         ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack Xin Long
2016-10-24 11:48         ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit Marcelo Ricardo Leitner
2016-10-24 11:48           ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack Marcelo Ricardo Leitner
2016-10-24 12:38         ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit Jamal Hadi Salim
2016-10-24 12:38           ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack Jamal Hadi Salim
2016-10-25  9:05           ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit Xin Long
2016-10-25  9:05             ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack Xin Long
2016-10-25 10:34             ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit Marcelo Ricardo Leitner
2016-10-25 10:34               ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack Marcelo Ricardo Leitner
2016-10-25 11:04               ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit Jamal Hadi Salim
2016-10-25 11:04                 ` send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_pack Jamal Hadi Salim

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=CADvbK_ci-aaX6-mgXTgR0mJm9ww7+48DmXH+m5R+-0PyMDH16g@mail.gmail.com \
    --to=lucien.xin@gmail.com \
    --cc=Michael.Tuexen@lurchi.franken.de \
    --cc=bjb@mojatatu.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gabor@mojatatu.com \
    --cc=jhs@mojatatu.com \
    --cc=linux-sctp@vger.kernel.org \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevic@redhat.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.