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.
