On December 14, 2017 4:04:28 PM Marcelo Ricardo Leitner
<marcelo.leitner@xxxxxxxxx> wrote:
> On Tue, Dec 12, 2017 at 05:24:46PM -0500, Paul Moore wrote:
>> On Tue, Dec 12, 2017 at 4:56 PM, Marcelo Ricardo Leitner
>> <marcelo.leitner@xxxxxxxxx> wrote:
>> > On Tue, Dec 12, 2017 at 04:33:03PM -0500, Paul Moore wrote:
>> >> On Tue, Dec 12, 2017 at 11:08 AM, Marcelo Ricardo Leitner
>> >> <marcelo.leitner@xxxxxxxxx> wrote:
>> >> > Hi Richard,
>> >> >
>> >> > On Mon, Nov 27, 2017 at 07:31:21PM +0000, Richard Haines wrote:
>> >> > ...
>> >> >> --- a/net/sctp/socket.c
>> >> >> +++ b/net/sctp/socket.c
>> >> >> @@ -3123,8 +3123,10 @@ static int sctp_setsockopt_maxseg(struct sock
>> *sk, char __user *optval, unsigned
>> >> >>
>> >> >> if (asoc) {
>> >> >> if (val == 0) {
>> >> >> + struct sctp_af *af = sp->pf->af;
>> >> >> val = asoc->pathmtu;
>> >> >> - val -= sp->pf->af->net_header_len;
>> >> >> + val -= af->ip_options_len(asoc->base.sk);
>> >> >> + val -= af->net_header_len;
>> >> >> val -= sizeof(struct sctphdr) +
>> >> >> sizeof(struct sctp_data_chunk);
>> >> >> }
>> >> >
>> >> > Right below here there is a call to sctp_frag_point(). That function
>> >> > also needs this tweak.
>> >> >
>> >> > Yes, we should simplify all these calculations. I have a patch to use
>> >> > sctp_frag_point on where it is currently recalculating it on
>> >> > sctp_datamsg_from_user(), but probably should include other places as
>> >> > well.
>> >>
>> >> FYI: Richard let me know he is occupied with another project at the
>> >> moment and likely won't be able to do another respin until next week
>> >> at the earliest.
>> >
>> > Okay, thanks. I can do a follow-up patch if it helps.
>>
>> I'll leave that up to you, I think your comments are pretty
>> straightforward and should be easy for Richard to incorporate, and
>> there is a lot to be said for including the fix in the original patch,
>> but if you would prefer to send a separate patch I think that's fine
>> too.
>
> This patchset conflicts with the stream schedulers patchset (on
> sctp.h) and will also conflict with the stream interleaving patchsets
> from Xin (other files).
>
> I rebased the patchset upon current crypto tree but the last patchset
> on stream interleaving is still to be accepted via net-next.
>
> I'm unsure on how to proceed here. Please advise.
>
> Thanks,
> Marcelo
I still believe the right course of action is to merge this via the SELinux
tree (based on Linus' tree). Due to the nature of SELinux we often have to
deal with conflicts like this; I haven't seen the conflicts your talking
about (I'm currently traveling with limited access) but Linus should be
able to handle the trivial fixes, if it is more complex we can provide
guidance about how to resolve it.
--
paul moore
www.paul-moore.com
