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] [day] [month] [year] [list]
Message-ID: <20110705113446.GA2959@hmsreliant.think-freely.org>
Date:	Tue, 5 Jul 2011 07:34:46 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Max Matveev <makc@...hat.com>
Cc:	linux-sctp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] Update description of net.sctp.sctp_rmem and
 net.sctp.sctp_wmem tunables

On Tue, Jul 05, 2011 at 12:00:19PM +1000, Max Matveev wrote:
> On Mon, 4 Jul 2011 10:54:54 -0400, Neil Horman wrote:
> 
>  nhorman> On Mon, Jun 20, 2011 at 06:08:10PM +1000, Max Matveev wrote:
> 
>  >> sctp_rmem - vector of 3 INTEGERs: min, default, max
>  >> -	See tcp_rmem for a description.
>  >> +	Only the first value ("min") is used, "default" and "max" are
>  >> +	ignored and may be removed in the future versions.
>  >> +
> 
>  nhorman> Its accurate to say that only the first value is usd
>  nhorman> currently, but because of the way this sysctl is contructed
>  nhorman> (its used by the sysctl_rmem pointer in the sctp_prot
>  nhorman> struct, which expects an array of three integers in the
>  nhorman> commong __sk_mem_schedule function), we wont' be removing
>  nhorman> the other two values.
> 
> Technically it can be just a single integer - UDP does use it 
> that way but I'm not going to argue, v2 of the patch removed
> that bit.
> 
Yeah, but the only reason udp gets away with it is because the common code in
__sk_mem_schedule only happens to touch the first element in the array.  I
suppose we could just drop the array semantics in the common code and save the
sizeof(int) bytes per protocol, but then individual protocols may (or may not)
access other elements of the array.  Hmm, odd situation.  I'd just as soon leave
the sctp elements in place, they probably have use for ongoing work to fix up
sctp's buffer accounting.

Anywho, thanks!
Acked-by: Neil Horman <nhorman@...driver.com>

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ