From: David Laight <David.Laight@ACULAB.COM>
To: 'Marcelo Ricardo Leitner' <marcelo.leitner@gmail.com>
Cc: "'linux-sctp@vger.kernel.org'" <linux-sctp@vger.kernel.org>,
"'netdev@vger.kernel.org'" <netdev@vger.kernel.org>
Subject: RE: Use of genradix in sctp
Date: Fri, 21 Aug 2020 21:39:23 +0000 [thread overview]
Message-ID: <11eafe393bc640a8bbddf33d0e784901@AcuMS.aculab.com> (raw)
In-Reply-To: <20200821204636.GO3399@localhost.localdomain>
From: 'Marcelo Ricardo Leitner'
> Sent: 21 August 2020 21:47
...
> > 3) Defer the allocation until the stream is used.
> > for outbound streams this could remove the extra buffer.
>
> This can be tricky. What should happen if it gets a packet on a stream
> that it couldn't allocate, and then another on a stream that was
> already allocated? Just a drop, it will retransmit and recover, and
> then again.. While, OTOH, if the application requested such amount of
> streams, it is likely going to use it. If not, that's an application
> bug.
You'd probably need to (effectively) drop the ethernet frame
that contained the chunk.
But the problem I see is that GFP flags are passed in.
So there must me a path where the allocation can't sleep.
Now allocating a couple of pages is fine but if the
maximum is just over 300 for each of 'in' and 'out'.
I can well imagine that is likely to fail.
I suspect this happens because the remote system can
(if my quick scan of the code is right) negotiate a
much larger number on an active connection.
I don't know what applications might be doing such things.
But I can imagine someone will try to negotiate 64k-1
streams just because that is the maximum.
And/or deciding to use stream 65535 for 'special' traffic.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2020-08-21 21:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-18 15:38 Use of genradix in sctp David Laight
2020-08-18 21:38 ` 'Marcelo Ricardo Leitner'
2020-08-18 21:38 ` 'Marcelo Ricardo Leitner'
2020-08-19 8:18 ` David Laight
2020-08-21 20:46 ` 'Marcelo Ricardo Leitner'
2020-08-21 20:46 ` 'Marcelo Ricardo Leitner'
2020-08-21 21:18 ` David Laight
2020-08-21 21:39 ` David Laight [this message]
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=11eafe393bc640a8bbddf33d0e784901@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=linux-sctp@vger.kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
/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.