netdev - Re: [PATCH] sendfile() and UDP socket

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]

Message-Id: <20080921.010458.216237442.davem@davemloft.net>
Date:	Sun, 21 Sep 2008 01:04:58 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	johaahn@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] sendfile() and UDP socket

From: Johann Baudy <johaahn@...il.com>
Date: Sun, 14 Sep 2008 12:25:56 +0200

> Sendfile() over UDP socket are currently limited to ~ 64KBytes file
> (max cork.length).  Indeed, if you run sendfile() with a file size >
> 64KBytes over UDP socket, system call will stop and return ~64KBytes
> without sending anything on the network.  This patch is pushing
> ongoing frames when frames buffer is full, to prevent overflow.
>
> Signed-off-by: Johann Baudy <johann.baudy@...il.com>

Applications which work over datagram protocols must perform their own
segmentation.  It is not like doing a send over a stream protocol like
TCP, where you can use whatever length you want for send calls and
segmentation is done for the application.

If you look, this is what things like NFS using SUNRPC over UDP do.
They have a transmission unit for the data transfer and use that for
each "send".

A sendfile() with length >= 64K is the same as a sendmsg() with such a
length, which is defined as:

	if (len > 0xFFFF)
		return -EMSGSIZE;

So we could technically even return an error for this sendfile() over
UDP case.
--
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