Understanding the reason for placing a tcp_sock on stack in tcp network functions

[Stephen Torri <storri@torri.org>]

[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

I am trying to help out reducing the stack size of functions in the
kernel. The function names and values below, with comments and
questions, was obtained of the linux-2.6 kernel kept at bkbits.net when
I did 'make checkstack'.

I have one main question: must the variable 'sk' remained
unchanged in all these functions?

If so then copying the user_mss variable from that input struct 'sk' to
the tcp_sock created on the stack is ok. Otherwise why do we not use the
socket pointer 'sk'given as an argument via tcp_sk to cast the pointer
type to a tcp_sock pointer?

Stephen

--- Notes ---
# Status: Puts a tcp_sock on the stack each time the function
#         is executed. I don't know if the cost of a kmalloc
#         and free of a tcp_sock is more expensive in time
#         than creating a tcp_sock on the stack. The requirements
#         memory is most likely to the same for each (guess).
0xc025ac5c tcp_check_req:                               1208

# Status: Same report as tcp_check_req. Only question I have is
#         the tcp_sock contained in the struct sock* pointer 'sk'
#         need to be unmodified in this call? The reason I ask
#         is that there is supposedly a struct sock* pointer sent
#         to this function is a tcp_sock pointer. Calling tcp_sk(sk)
#         will cast the tcp_sock pointer. If its not required to
#         maintain 'sk' unchanged through this function then we
#         can skip adding one to the stack for the sole purpose of
#         copying the use_mms to it.
0xc02573da tcp_v4_conn_request:                         1192

# Status: Same report as tcp_check_req. Only comment here is that the
# struct sk_buff contains a reference to the socket that it is owned
# by. Again as with the comments with tcp_v4_conn_request, can we use
# the socket 'sk' contained in the sk_buff with tcp_sk(sk) to get a
# pointer to a tcp_sock? If we can then we are reusing a socket rather
# than creating one on the stack.

0xc02599c3 tcp_timewait_state_process:                  1176
0xc0259c9f tcp_timewait_state_process:                  1176

# Status: As the comments say in tcp_ipv6.c, this function is
# incredibly similar to the version in tcp_ipv4.c. Again why do have
# to create a tcp_sock header on the stack.

0x0001c713 tcp_v6_conn_request:                         1176

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]