netdev - Re: [net-next 1/1] tipc: sockopt(TIPC_SO_RCVBUF) for setting receive buffer

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20180228.113542.1150218451982102408.davem@davemloft.net>
Date:   Wed, 28 Feb 2018 11:35:42 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     jon.maloy@...csson.com
Cc:     netdev@...r.kernel.org,
        mohan.krishna.ghanta.krishnamurthy@...csson.com,
        tung.q.nguyen@...tech.com.au, hoang.h.le@...tech.com.au,
        canh.d.luu@...tech.com.au, ying.xue@...driver.com,
        tipc-discussion@...ts.sourceforge.net
Subject: Re: [net-next 1/1] tipc: sockopt(TIPC_SO_RCVBUF) for setting
 receive buffer

From: Jon Maloy <jon.maloy@...csson.com>
Date: Tue, 27 Feb 2018 20:47:09 +0100

> From: Hoang Le <hoang.h.le@...tech.com.au>
> 
> We introduce a set/getsockopt for setting socket receive buffer per
> individual socket. This has turned out to sometimes be necessary for
> anycast and multicast receivers when used without flow control.
> 
> Signed-off-by: Hoang Le <hoang.h.le@...tech.com.au>
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>

I really don't want things to start going down this road.

The semantics for foo_rmem[] is that the [1] value indicates
the default on a new socket, and [2] determines how large
sk->sk_rcvbuf will grow through automatic receive buffer
autosizing as done by TCP.

It is not a limit value to impose upon the user's request.

Furthermore, the user can just do a SO_RCVBUF setsockopt to bypass
these limits.

So this change is undesirable on many levels.

I'm not applying this, sorry.  Please get TIPC sockets to behave
and enforce limits just like other socket families do, avoid
custom family specific behavior at all costs.

Thank you.