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

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

[Stephen Torri]

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

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

[Arnaldo Carvalho de Melo]

This is not the case for at least some of these functions:

ChangeSet@1.2035.2.55, 2005-02-22 10:48:28-08:00, acme@conectiva.com.br
  [TCP]: Fix excessive stack usage resulting in OOPS with 4KSTACKS.

  Various routines were putting a full struct tcp_sock on
  the local stack.  What they really wanted was a subset
  of this information when doing TCP options processing
  when we only have a mini-socket (for example in SYN-RECVD
  and TIME_WAIT states).

  Therefore pull out the needed information into a sub-struct
  and use that in the TCP options processing routines.

  Signed-off-by: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
  Signed-off-by: David S. Miller <davem@davemloft.net>


On Mon, 28 Feb 2005 19:51:17 -0500, Stephen Torri <storri@torri.org> wrote:
> 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'.