* [PATCH] sctp: Honour SCTP_PARTIAL_DELIVERY_POINT even under memory pressure
@ 2020-09-01 9:00 Petr Malat
2020-09-02 14:58 ` Marcelo Ricardo Leitner
0 siblings, 1 reply; 4+ messages in thread
From: Petr Malat @ 2020-09-01 9:00 UTC (permalink / raw)
To: linux-sctp; +Cc: vyasevich, nhorman, marcelo.leitner, davem, kuba, Petr Malat
Command SCTP_CMD_PART_DELIVER issued under memory pressure calls
sctp_ulpq_partial_delivery(), which tries to fetch and partially deliver
the first message it finds without checking if the message is longer than
SCTP_PARTIAL_DELIVERY_POINT. According to the RFC 6458 paragraph 8.1.21.
such a behavior is invalid. Fix it by returning the first message only if
its part currently available is longer than SCTP_PARTIAL_DELIVERY_POINT.
Signed-off-by: Petr Malat <oss@malat.biz>
---
net/sctp/ulpqueue.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index 1c6c640607c5..cada0b7f1548 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -610,6 +610,7 @@ static struct sctp_ulpevent *sctp_ulpq_retrieve_first(struct sctp_ulpq *ulpq)
struct sctp_ulpevent *cevent;
__u32 ctsn, next_tsn;
struct sctp_ulpevent *retval;
+ size_t pd_point, pd_len = 0;
/* The chunks are held in the reasm queue sorted by TSN.
* Walk through the queue sequentially and look for a sequence of
@@ -633,8 +634,9 @@ static struct sctp_ulpevent *sctp_ulpq_retrieve_first(struct sctp_ulpq *ulpq)
first_frag = pos;
next_tsn = ctsn + 1;
last_frag = pos;
+ pd_len = pos->len;
} else
- goto done;
+ goto check;
break;
case SCTP_DATA_MIDDLE_FRAG:
@@ -643,15 +645,19 @@ static struct sctp_ulpevent *sctp_ulpq_retrieve_first(struct sctp_ulpq *ulpq)
if (ctsn = next_tsn) {
next_tsn++;
last_frag = pos;
+ pd_len += pos->len;
} else
- goto done;
+ goto check;
break;
case SCTP_DATA_LAST_FRAG:
if (!first_frag)
return NULL;
- else
+ if (ctsn = next_tsn) {
+ last_frag = pos;
goto done;
+ } else
+ goto check;
break;
default:
@@ -659,6 +665,11 @@ static struct sctp_ulpevent *sctp_ulpq_retrieve_first(struct sctp_ulpq *ulpq)
}
}
+check:
+ pd_point = sctp_sk(ulpq->asoc->base.sk)->pd_point;
+ if (pd_point && pd_point > pd_len)
+ return NULL;
+
/* We have the reassembled event. There is no need to look
* further.
*/
--
2.20.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] sctp: Honour SCTP_PARTIAL_DELIVERY_POINT even under memory pressure
2020-09-01 9:00 [PATCH] sctp: Honour SCTP_PARTIAL_DELIVERY_POINT even under memory pressure Petr Malat
@ 2020-09-02 14:58 ` Marcelo Ricardo Leitner
2020-09-03 11:21 ` Petr Malat
0 siblings, 1 reply; 4+ messages in thread
From: Marcelo Ricardo Leitner @ 2020-09-02 14:58 UTC (permalink / raw)
To: Petr Malat; +Cc: linux-sctp, vyasevich, nhorman, davem, kuba
On Tue, Sep 01, 2020 at 11:00:07AM +0200, Petr Malat wrote:
> Command SCTP_CMD_PART_DELIVER issued under memory pressure calls
> sctp_ulpq_partial_delivery(), which tries to fetch and partially deliver
> the first message it finds without checking if the message is longer than
> SCTP_PARTIAL_DELIVERY_POINT. According to the RFC 6458 paragraph 8.1.21.
> such a behavior is invalid. Fix it by returning the first message only if
> its part currently available is longer than SCTP_PARTIAL_DELIVERY_POINT.
Okay but AFAICT this patch then violates the basic idea behind partial
delivery. It will cause such small message to just not be delivered
anymore, and keep using the receive buffer which it is trying to free
some bits at this moment.
Btw, you also need to Cc netdev@vger.kernel.org for patches to
actually get applied by DaveM.
Marcelo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] sctp: Honour SCTP_PARTIAL_DELIVERY_POINT even under memory pressure
2020-09-02 14:58 ` Marcelo Ricardo Leitner
@ 2020-09-03 11:21 ` Petr Malat
2020-09-03 17:18 ` Marcelo Ricardo Leitner
0 siblings, 1 reply; 4+ messages in thread
From: Petr Malat @ 2020-09-03 11:21 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: linux-sctp, vyasevich, nhorman, davem, kuba, netdev
Hi!
On Wed, Sep 02, 2020 at 11:58:35AM -0300, Marcelo Ricardo Leitner wrote:
> On Tue, Sep 01, 2020 at 11:00:07AM +0200, Petr Malat wrote:
> > Command SCTP_CMD_PART_DELIVER issued under memory pressure calls
> > sctp_ulpq_partial_delivery(), which tries to fetch and partially deliver
> > the first message it finds without checking if the message is longer than
> > SCTP_PARTIAL_DELIVERY_POINT. According to the RFC 6458 paragraph 8.1.21.
> > such a behavior is invalid. Fix it by returning the first message only if
> > its part currently available is longer than SCTP_PARTIAL_DELIVERY_POINT.
>
> Okay but AFAICT this patch then violates the basic idea behind partial
> delivery. It will cause such small message to just not be delivered
> anymore, and keep using the receive buffer which it is trying to free
> some bits at this moment.
By default the pd_point is set to 0, so there will not be a change in the
behavior, but if the user changes it to some other value, it should be
respected by the stack - for example when the largest message the user
exchanges is 1kB and the user sets it to 1kB, his application is not
prepared to handle fragmented messages at all and it's not a good idea to
pass such a message to the app.
> Btw, you also need to Cc netdev@vger.kernel.org for patches to
> actually get applied by DaveM.
Thanks, I will add it to this message and bounce the original patch message
as well.
Petr
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] sctp: Honour SCTP_PARTIAL_DELIVERY_POINT even under memory pressure
2020-09-03 11:21 ` Petr Malat
@ 2020-09-03 17:18 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 4+ messages in thread
From: Marcelo Ricardo Leitner @ 2020-09-03 17:18 UTC (permalink / raw)
To: Petr Malat; +Cc: linux-sctp, vyasevich, nhorman, davem, kuba, netdev
Hi!
On Thu, Sep 03, 2020 at 01:21:48PM +0200, Petr Malat wrote:
> Hi!
> On Wed, Sep 02, 2020 at 11:58:35AM -0300, Marcelo Ricardo Leitner wrote:
> > On Tue, Sep 01, 2020 at 11:00:07AM +0200, Petr Malat wrote:
> > > Command SCTP_CMD_PART_DELIVER issued under memory pressure calls
> > > sctp_ulpq_partial_delivery(), which tries to fetch and partially deliver
> > > the first message it finds without checking if the message is longer than
> > > SCTP_PARTIAL_DELIVERY_POINT. According to the RFC 6458 paragraph 8.1.21.
> > > such a behavior is invalid. Fix it by returning the first message only if
> > > its part currently available is longer than SCTP_PARTIAL_DELIVERY_POINT.
> >
> > Okay but AFAICT this patch then violates the basic idea behind partial
> > delivery. It will cause such small message to just not be delivered
> > anymore, and keep using the receive buffer which it is trying to free
> > some bits at this moment.
> By default the pd_point is set to 0, so there will not be a change in the
> behavior, but if the user changes it to some other value, it should be
> respected by the stack - for example when the largest message the user
> exchanges is 1kB and the user sets it to 1kB, his application is not
> prepared to handle fragmented messages at all and it's not a good idea to
> pass such a message to the app.
Then, if it doesn't support fragmented messages at all, the app just
shouldn't be setting pd_point at all. :-) Anyhow, I see how the patch
works now.
The fix is also needed on sctp_intl_retrieve_first() and
sctp_intl_retrieve_first_uo(). Same issue is in there, but for stream
interleaving.
Thanks.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-03 17:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-01 9:00 [PATCH] sctp: Honour SCTP_PARTIAL_DELIVERY_POINT even under memory pressure Petr Malat
2020-09-02 14:58 ` Marcelo Ricardo Leitner
2020-09-03 11:21 ` Petr Malat
2020-09-03 17:18 ` Marcelo Ricardo Leitner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).