Re: [PATCH net-next 11/15] sctp: add udphdr to overhead when udp_port is set

[Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>]

On Sat, Oct 03, 2020 at 08:24:34PM +0800, Xin Long wrote:
> On Sat, Oct 3, 2020 at 7:23 PM Xin Long <lucien.xin@gmail.com> wrote:
> >
> > On Sat, Oct 3, 2020 at 4:12 PM Xin Long <lucien.xin@gmail.com> wrote:
> > >
> > > On Sat, Oct 3, 2020 at 12:08 PM Marcelo Ricardo Leitner
> > > <marcelo.leitner@gmail.com> wrote:
> > > >
> > > > On Wed, Sep 30, 2020 at 03:00:42AM +0800, kernel test robot wrote:
> > > > > Hi Xin,
> > > > >
> > > > > Thank you for the patch! Yet something to improve:
> > > >
> > > > I wonder how are you planning to fix this. It is quite entangled.
> > > > This is not performance critical. Maybe the cleanest way out is to
> > > > move it to a .c file.
> > > >
> > > > Adding a
> > > > #if defined(CONFIG_IP_SCTP) || defined(CONFIG_IP_SCTP_MODULE)
> > > > in there doesn't seem good.
> > > >
> > > > >    In file included from include/net/sctp/checksum.h:27,
> > > > >                     from net/netfilter/nf_nat_proto.c:16:
> > > > >    include/net/sctp/sctp.h: In function 'sctp_mtu_payload':
> > > > > >> include/net/sctp/sctp.h:583:31: error: 'struct net' has no member named 'sctp'; did you mean 'ct'?
> > > > >      583 |   if (sock_net(&sp->inet.sk)->sctp.udp_port)
> > > > >          |                               ^~~~
> > > > >          |                               ct
> > > > >
> > > Here is actually another problem, I'm still thinking how to fix it.
> > >
> > > Now sctp_mtu_payload() returns different value depending on
> > > net->sctp.udp_port. but net->sctp.udp_port can be changed by
> > > "sysctl -w" anytime. so:

Good point.

> > >
> > > In sctp_packet_config() it gets overhead/headroom by calling
> > > sctp_mtu_payload(). When 'udp_port' is 0, it's IP+MAC header
> > > size. Then if 'udp_port' is changed to 9899 by 'sysctl -w',
> > > udphdr will also be added to the packet in sctp_v4_xmit(),
> > > and later the headroom may not be enough for IP+MAC headers.
> > >
> > > I'm thinking to add sctp_sock->udp_port, and it'll be set when
> > > the sock is created with net->udp_port. but not sure if we should
> > > update sctp_sock->udp_port with  net->udp_port when sending packets?

I don't think so,

> > something like:
...
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 6614c9fdc51e..c96b13ec72f4 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -91,6 +91,14 @@ void sctp_packet_config(struct sctp_packet *packet,
> __u32 vtag,
>         if (asoc) {
>                 sk = asoc->base.sk;
>                 sp = sctp_sk(sk);
> +
> +               if (unlikely(sp->udp_port != sock_net(sk)->sctp.udp_port)) {

RFC6951 has:

6.1.  Get or Set the Remote UDP Encapsulation Port Number
      (SCTP_REMOTE_UDP_ENCAPS_PORT)
...
   sue_assoc_id:  This parameter is ignored for one-to-one style
      sockets.  For one-to-many style sockets, the application may fill
      in an association identifier or SCTP_FUTURE_ASSOC for this query.
      It is an error to use SCTP_{CURRENT|ALL}_ASSOC in sue_assoc_id.

   sue_address:  This specifies which address is of interest.  If a
      wildcard address is provided, it applies only to future paths.

So I'm not seeing a reason to have a system wide knob that takes
effect in run time like this.
Enable, start apps, and they keep behaving as initially configured.
Need to disable? Restart the apps/sockets.

Thoughts?

> +                       __u16 port = sock_net(sk)->sctp.udp_port;
> +
> +                       if (!sp->udp_port || !port)
> +                               sctp_assoc_update_frag_point(asoc);
> +                       sp->udp_port = port;
> +               }
>         }