netdev - Re: [PATCH net-next 2/2] sctp: add support for MSG

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:   Sat, 25 Mar 2017 00:09:09 +0800
From:   Xin Long <lucien.xin@...il.com>
To:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Cc:     David Laight <David.Laight@...lab.com>,
        network dev <netdev@...r.kernel.org>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        Neil Horman <nhorman@...driver.com>,
        Vlad Yasevich <vyasevich@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH net-next 2/2] sctp: add support for MSG_MORE

On Fri, Mar 24, 2017 at 12:42 AM, Marcelo Ricardo Leitner
<marcelo.leitner@...il.com> wrote:
> On Thu, Mar 23, 2017 at 12:35:46PM +0800, Xin Long wrote:
>> On Thu, Mar 23, 2017 at 1:33 AM, Marcelo Ricardo Leitner
>> <marcelo.leitner@...il.com> wrote:
>> > On Wed, Mar 22, 2017 at 02:07:37PM +0000, David Laight wrote:
>> >> Regardless of the MSG_MORE flags associated with any specific send()
>> >> request there will always be protocol effects (like retransmissions
>> >> or flow control 'on') that will generate different 'chunking'.
>> >
>> > Yes, those are the ones that may lead to some confusion on how it
>> > actually works, and mangling them is not really desired for the
>> > sideeffects that it might have.
>> >
>> > Sooner or later we could have bug reports like "hey this chunk shouldn't
>> > have been packed with that." if we stick with the initial proposition,
>> > while with David's view, we are only promising to not send packets with
>> > a single chunk and as long as the application send more data fast enough.
>> >
>> > David, are we on the same page now? ;-)
>> >
>> > Xin, what do you think?
>> If we insist that MSG_MORE means not to send  ANY data, I compromise.
>> does ANY include retransmission DATA? should MSG_MORE block
>> retransmission ?
>
> That's not really what he meant by that, I think. That "ANY" in there is
> a way to refer to the entire buf and not that msg sendmsg is sending.
> Later I explained what I got from his explanation, which should be more
> like:
> "If MSG_MORE was used, and there are no packets in flight, do not send a
> packet right away because the application is going to send more data."
> Would have to handle the (Not-)Nagle situation too:
> "If not using Nagle and using MSG_MORE, try to not generate a packet
> right away." (because this may send packets with a single chunk even if
> in_flight != 0)
> In both cases, if the flush is generated by other triggers, it's okay.
>
> Because if there are chunks already queued, they will be sent as soon as
> in_flight reaches 0 or some other break is lifted (flow control).
> Holding the chunk that was queued with MSG_MORE and sending a partial
> packet in this case because of MSG_MORE is not good, it's possibly not
> saving anything.

Makes sence, thanks for making this clear, will post a new fix.