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-next>] [day] [month] [year] [list]
Date:	Fri, 27 Jun 2008 03:37:59 -0500
From:	"Kiran Kotla" <kotlakiran@...il.com>
To:	linux-kernel@...r.kernel.org, linux-net@...r.kernel.org
Subject: setting ICSK_CA_PRIV_SIZE larger than 16 * sizeof(u32)

Hi guys,

We have a recently implemented our Congestion control algorithm named
PERT (Probabilistic early response TCP), in the linux kernel.

As a part of it, we needed to define some variables in the private
variables part ( __u32 icsk_ca_priv[16] ) of per flow structure
(struct inet_connection_sock) in the file
"include/net/inet_connection_sock.h"

As you can see the limit on the number of private variables has been
imposed to 16 u32 variables. However, our protocol requires that we
have more than 16 say upto 25 u32 variables.
We tried changing the size of icsk_ca_priv from 16 to a larger value
and correspondingly changed the #define  ICSK_CA_PRIV_SIZE to a larger
value which was initially set to  "16 * sizeof(u32)".

We have searched the entire kernel code but did not find any other
dependency on the size of "icsk_ca_priv". We compiled the code and
rebooted the machine with the new image and we see a kernel crash
(Panic) at the very piece of code where this structure is being
initialized. We reset it back to 16 and it worked perfectly fine.

I just wanted to ask if there is a way to change the size of this
private variable array "icsk_ca_priv".

The only other option we have to get the kernel running with our
protocol is to reduce the number of private variables and this is not
possible without affecting the behavior of our protocol.

It would be great if someone of you who have used this structure
sometime shedded light on this.

Your replies are very well appreciated.

Thanks a ton in advance.

best wishes
Kiran Kotla
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ