netdev - Re: [PATCH] sctp: set ooo_okay properly for Transmit Packet Steering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 31 Oct 2019 09:11:40 +0800
From:   Wei Zhao <wallyzhao@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     vyasevich@...il.com, nhorman@...driver.com,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        davem@...emloft.net, linux-sctp@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        wally.zhao@...ia-sbell.com
Subject: Re: [PATCH] sctp: set ooo_okay properly for Transmit Packet Steering

On Thu, Oct 31, 2019 at 3:03 AM Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>
>
> On 10/30/19 9:07 AM, Wally Zhao wrote:
> > Unlike tcp_transmit_skb,
> > sctp_packet_transmit does not set ooo_okay explicitly,
> > causing unwanted Tx queue switching when multiqueue is in use;
> > Tx queue switching may cause out-of-order packets.
> > Change sctp_packet_transmit to allow Tx queue switching only for
> > the first in flight packet, to avoid unwanted Tx queue switching.
> >
>
> While the patch seems fine, the changelog is quite confusing.
>
> When skb->ooo_olay is 0 (which is the default for freshly allocated skbs),
> the core networking stack will stick to whatever TX queue was chosen
> at the time the dst_entry was attached to the (connected) socket.
>
> This means no reorder can happen at all by default.
>
> By setting ooo_okay carefully (as you did in your patch), you allow
> core networking stack to _switch_ to another TX queue based on
> current CPU  (XPS selection)
>
> So even without your fix, SCTP should not experience out-of-order packets.

Yes, you are right, as Marcelo also pointed out.
The changelog was given based on incorrect observation of a test
result, as I replied to Marcelo.
Since ooo_okay is default to 0, this is good enough; no need for any
patch from my side.
Thank you for your time on this.


>
> > Signed-off-by: Wally Zhao <wallyzhao@...il.com>
> > ---
> >  net/sctp/output.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/net/sctp/output.c b/net/sctp/output.c
> > index dbda7e7..5ff75cc 100644
> > --- a/net/sctp/output.c
> > +++ b/net/sctp/output.c
> > @@ -626,6 +626,10 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp)
> >       /* neighbour should be confirmed on successful transmission or
> >        * positive error
> >        */
> > +
> > +     /* allow switch tx queue only for the first in flight pkt */
> > +     head->ooo_okay = asoc->outqueue.outstanding_bytes == 0;
> > +
> >       if (tp->af_specific->sctp_xmit(head, tp) >= 0 &&
> >           tp->dst_pending_confirm)
> >               tp->dst_pending_confirm = 0;
> >