[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190213172339.GJ13621@localhost.localdomain>
Date: Wed, 13 Feb 2019 15:23:39 -0200
From: 'Marcelo Ricardo Leitner' <marcelo.leitner@...il.com>
To: David Laight <David.Laight@...lab.com>
Cc: David Miller <davem@...emloft.net>,
"julien@...sta.com" <julien@...sta.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"nhorman@...driver.com" <nhorman@...driver.com>,
"vyasevich@...il.com" <vyasevich@...il.com>,
"lucien.xin@...il.com" <lucien.xin@...il.com>
Subject: Re: [PATCH net] sctp: make sctp_setsockopt_events() less strict
about the option length
On Wed, Feb 13, 2019 at 04:17:41PM +0000, David Laight wrote:
> From: Marcelo Ricardo Leitner
> > Sent: 10 February 2019 20:16
> ...
> > We have issues on read path too. 52ccb8e90c0a ("[SCTP]: Update
> > SCTP_PEER_ADDR_PARAMS socket option to the latest api draft.")
> > extended struct sctp_paddrparams and its getsockopt goes with:
>
> The API shouldn't change like this at all.
> Is this from the RFC or elsewhere??
I would think so. That commit is from 2005, pretty close to initial
SCTP RFCs.
>
> If the structure changes the socket option name and value
> should also change.
That's what is at the core of this thread.
Marcelo
>
> IMHO large chunks of the sctp rfc are just horrid.
> In particular all the places where is states that API functions are
> implemented using setsockopt() - that should be an implementation detail.
> Also ISTR that some of the structures are defined to have holes in them...
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
Powered by blists - more mailing lists