netdev - RE: [PATCH net-next v3 3/3] net: 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:	Tue, 22 Jul 2014 13:45:37 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Vlad Yasevich' <vyasevich@...il.com>,
	"Linux Networking Development Mailing List" <netdev@...r.kernel.org>,
	"'linux-sctp@...r.kernel.org'" <linux-sctp@...r.kernel.org>
CC:	David Miller <davem@...emloft.net>
Subject: RE: [PATCH net-next v3 3/3] net: sctp: Add support for MSG_MORE on
 SCTP

From: Vlad Yasevich 
> On 07/22/2014 04:59 AM, David Laight wrote:
> > If MSG_MORE is set then the data chunk will be buffered until either
> > a full packet would be generated, or something causes a chunk to be
> > sent (eg data without MSG_MORE or a heartbeat).
> 
> heartbeat will not cause a data flush.  Only SACKs do that as they control
> congestion and flow.

Experimentally heartbeats cause data to be sent.
I'd only got one IP address at each end - so don't know what happens to
any 'probe' HBs.
I frigged my code to set MSG_MORE if the data chunk was over 200 bytes.
A single long fragment would be collected by a short one, or by a heartbeat.
I did wonder if that was a bug - but it would happen for data delayed by Nagle.

> That's might actually be a good solution to the problem of the an incorrectly
> using MSG_MORE.  When a SACK drops inflight to 0, clear MSG_MORE from the
> association thus allowing any queued data (even less then MTU) to be flushed.
> 
> This way, when the data flow just starts, you can use MSG_MORE to control
> bundling.  However, the app stops sending, even if it forgot to clear MSG_MORE,
> we'll clear it ourselves once inflight drops to 0.

That will only work if there is enough data to actually send something.
So more likely to cause confusion than be useful.

All this is really defining the behaviour for 'broken' apps.
It wouldn't be completely unreasonable if a single message sent with 'MSG_MORE'
never actually got sent.

> > The MSG_MORE flag is saved 'per association' along with a copy
> > of the SCTP_NODELAY/Nagle flag.
> >
> > It is expected that an application will only set MSG_MORE when it
> > has an additional data chunk ready to send. The sends could be done
> > with a single sendmmsg() system call.
> 
> Is that really true?  If the application has 5 messages and it sends all
> 5 with the sendmmsg(), then MSG_MORE will never get cleared and a flush
> would not get triggered.

Hmmm.... I was thinking that each entry in msgvec[] had its own flags field.
But I guess that is only used for receive.

I looked at that code at the beginning to see if it made sense to just bundle
data sent with sendmmsg() - and decided it wasn't worth the effort because
semdmmsg() is mostly a system call saver, I'd still need to implement the
same code inside sctp.
This is made more difficult for 1-many sockets because the buffers for sendmmsg()
can all have different addresses.

One option for sendmmsg() is set a different flag on all but the last buffer
if there are no addresses present, and treat it the same as MSG_MORE for sctp.

I'm on holiday for the next 2 weeks. I'll probably manage to read netdev, but
won't be able to repost the patches from here - and certainly can't test
anything.

It would be nice to get the current patches (especially 1/3 and 2/3) in now.

	David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html