netdev - Re: [PATCH] net: add SO_MAX_DGRAM_QLEN for AF_UNIX SOCK

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:	Mon, 02 Mar 2015 21:38:07 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	christian@...kd.de
Cc:	netdev@...r.kernel.org, dan@...dstab.net, edumazet@...gle.com,
	hannes@...essinduktion.org, linux-api@...r.kernel.org
Subject: Re: [PATCH] net: add SO_MAX_DGRAM_QLEN for AF_UNIX SOCK_DGRAM
 sockets

From: Christian Seiler <christian@...kd.de>
Date: Tue,  3 Mar 2015 01:32:54 +0100

> Rationale: applications may want to control how many datagrams the
> kernel buffers before senders are blocked. A prominent example would be
> to create a socket for syslog early at boot but only consume messages
> once enough of the system has been set up. The default queue length of
> 11 messages (= 10 + 1) is too low for this kind of application.

I never like arguments that talk about forcing the kernel to do
excessive buffering for an application.

Queue this stuff in the userspace side, then you can have as many
messages backlogged as you like _without_ consuming unswappable kernel
memory.

I'm tossing this, you're going to have to do a much better job
explaining to me why userspace cannot take upon itself the burdon of
queueing data until it can be sent.
--
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