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:	Tue, 03 Mar 2015 07:56:15 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Christian Seiler <christian@...kd.de>
Cc:	David Miller <davem@...emloft.net>, 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

On Tue, 2015-03-03 at 16:05 +0100, Christian Seiler wrote:

> Doesn't this assume a typical datagram size of 256 bytes? Isn't that
> something that should be left up to the user? Also, suddenly the RCVBUF
> size of UNIX domain sockets suddenly becomes relevant, even though it
> is never actually checked when it comes to queuing the messages (only
> the SNDBUF size of the sending socket is checked). This creates really
> inconsistent semantics in my eyes where the receive buffer is useful
> for some things, but not for others.

Simple : If limit is expressed in term of packets, not in term of memory
usage, then the limit is in number of packets, not in bytes.

This is the reason we have pfifo and bfifo qdisc :
Admin can choose what he wants to limit on a device : packets or bytes.

If you want to allow the limitation being done in same SO_RCVBUF spirit,
you need to submit a patch for that.

(Using skb_set_owner_r() and tracking sk->sk_rmem_alloc instead of
skb_queue_len(&sk->sk_receive_queue) )


--
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