From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Ricardo Leitner Subject: Re: [PATCH net-next 3/5] sctp: add spp_ipv6_flowlabel and spp_dscp for sctp_paddrparams Date: Mon, 25 Jun 2018 13:31:59 -0300 Message-ID: <20180625163157.GA542@localhost.localdomain> References: <20180625.163126.1464757436422028440.davem@davemloft.net> <20180625112847.GB16772@hmswarspite.think-freely.org> <20180625130319.GA820@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Neil Horman , David Miller , lucien.xin@gmail.com, netdev@vger.kernel.org, linux-sctp@vger.kernel.org, yoshfuji@linux-ipv6.org To: =?utf-8?B?5ZCJ6Jek6Iux5piO?= Return-path: Received: from mail-qt0-f195.google.com ([209.85.216.195]:34603 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932073AbeFYQcE (ORCPT ); Mon, 25 Jun 2018 12:32:04 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Hi, On Tue, Jun 26, 2018 at 01:12:00AM +0900, 吉藤英明 wrote: > Hi, > > 2018-06-25 22:03 GMT+09:00 Marcelo Ricardo Leitner : > > On Mon, Jun 25, 2018 at 07:28:47AM -0400, Neil Horman wrote: > >> On Mon, Jun 25, 2018 at 04:31:26PM +0900, David Miller wrote: > >> > From: Xin Long > >> > Date: Mon, 25 Jun 2018 10:14:35 +0800 > >> > > >> > > struct sctp_paddrparams { > >> > > @@ -773,6 +775,8 @@ struct sctp_paddrparams { > >> > > __u32 spp_pathmtu; > >> > > __u32 spp_sackdelay; > >> > > __u32 spp_flags; > >> > > + __u32 spp_ipv6_flowlabel; > >> > > + __u8 spp_dscp; > >> > > } __attribute__((packed, aligned(4))); > >> > > >> > I don't think you can change the size of this structure like this. > >> > > >> > This check in sctp_setsockopt_peer_addr_params(): > >> > > >> > if (optlen != sizeof(struct sctp_paddrparams)) > >> > return -EINVAL; > >> > > >> > is going to trigger in old kernels when executing programs > >> > built against the new struct definition. > > > > That will happen, yes, but do we really care about being future-proof > > here? I mean: if we also update such check(s) to support dealing with > > smaller-than-supported structs, newer kernels will be able to run > > programs built against the old struct, and the new one; while building > > using newer headers and running on older kernel may fool the > > application in other ways too (like enabling support for something > > that is available on newer kernel and that is not present in the older > > one). > > We should not break existing apps. > We still accept apps of pre-2.4 era without sin6_scope_id > (e.g., net/ipv6/af_inet6.c:inet6_bind()). Yes. That's what I tried to say. That is supporting an old app built with old kernel headers and running on a newer kernel, and not the other way around (an app built with fresh headers and running on an old kernel). > > > > >> > > >> I think thats also the reason its a packed aligned attribute, it can't be > >> changed, or older kernels won't be able to fill it out properly. > >> Neil > > > > It's more for supporting running 32-bits apps on 64-bit kernels > > (according to 20c9c825b12fc). > > > > Marcelo