2001-02-23 20:40:05

by Sourav Ghosh

[permalink] [raw]
Subject: creation of sock

Hello,

I'm using linux 2.2.15 kernel on redhat.
I have added some variables (pointers) on "sock" data structure.
I was initializing them to NULL in sk_alloc() function.

But it seems some sock structures are allocated for TCP bypassing this
sk_alloc() and due to this my added pointers are not initialized to NULL
all the time.

Can anyone tell me which function is being called for generating sock
for TCP connections ( I guess for a aprticular TCP packet type, not for
all, as I'm getting into this problem intermittently, esp., when I try
access some specified website from my PC) ?

Thanks
--
Sourav


2001-02-23 21:53:36

by Jacob L E Blain Christen

[permalink] [raw]
Subject: Re: creation of sock

im a kernel newbie here so pardon "the blind leading the blind" ...

doing a quick search for all calls to sk_alloc in the entire kernel
sources
yields only one call that sets the "zero out the allocated struct"
boolean
to false and that is:
net/ipv4/tcp_minisocks.c:tcp_create_openreq_child().
this funtion in turn is only ever called from:
net/ipv[46]/tcp_ipv[46].c:tcp_v[46]_syn_recv_sock()

the comment above the ipv4 version is (verbatim):

/*
* The three way handshake has completed - we got a valid synack -
* now create the new socket.
*/

so if you need those experimental values of yours zeroed out on socket
creation i suggest replacing this snippet from
net/core/sock.c:sk_alloc()

if(sk && zero_it) {
memset(sk, 0, sizeof(struct sock));
sk->family = family;
sock_lock_init(sk);
}

with

if( sk ) {
/* set your NULL init values here */
if( zero_it ) {
memset(sk, 0, sizeof(struct sock));
sk->family = family;
sock_lock_init(sk);
}
}

doh! i just re-read your mail and realized youre using the 2.2.15
kernel.
my examples are from the 2.4.2 sources...

looking at the 2.2.16 source (i have only 2.2.1[46] and not 2.2.15 for
the
2.2 series) the (roughly) congruent if block of code is:

if(sk) {
if (zero_it)
memset(sk, 0, sizeof(struct sock));
sk->family = family;
}

and so if you're setting your init values to NULL under the "zero_it"
condition you would get the behavior that you reported.

hope that helps.

2001-02-23 22:11:53

by Jacob L E Blain Christen

[permalink] [raw]
Subject: Re: creation of sock

looking further at
net/ipv4/tcp_ipv4.c:tcp_create_openreq_child() (for 2.2.16)
and
net/ipv4/tcp_minisocks.c:tcp_create_openreq_child() (for 2.4.x)

immediately after the sk_alloc() call (if it successful) it calls
memcpy(newsk, sk, sizeof(*newsk))
i suggest setting your NULL initial values immediately after this line.

sorry for the premature email

2001-02-24 00:31:45

by Sourav Ghosh

[permalink] [raw]
Subject: Re: creation of sock

Jacob L E Blain Christen wrote:

> looking further at
> net/ipv4/tcp_ipv4.c:tcp_create_openreq_child() (for 2.2.16)
> and
> net/ipv4/tcp_minisocks.c:tcp_create_openreq_child() (for 2.4.x)
>
> immediately after the sk_alloc() call (if it successful) it calls
> memcpy(newsk, sk, sizeof(*newsk))
> i suggest setting your NULL initial values immediately after this line.
>
> sorry for the premature email

Didn't help.
The problem persists.

2001-02-24 01:50:45

by Sourav Ghosh

[permalink] [raw]
Subject: Re: creation of sock

I found this condition only happens when the sock state is TCP_TIME_WAIT.
I don't know if this helps.


Sourav Ghosh wrote:

> Hello,
>
> I'm using linux 2.2.15 kernel on redhat.
> I have added some variables (pointers) on "sock" data structure.
> I was initializing them to NULL in sk_alloc() function.
>
> But it seems some sock structures are allocated for TCP bypassing this
> sk_alloc() and due to this my added pointers are not initialized to NULL
> all the time.
>
> Can anyone tell me which function is being called for generating sock
> for TCP connections ( I guess for a aprticular TCP packet type, not for
> all, as I'm getting into this problem intermittently, esp., when I try
> access some specified website from my PC) ?
>
> Thanks
> --
> Sourav

2001-02-24 16:31:34

by Sourav Ghosh

[permalink] [raw]
Subject: Re: creation of sock

Hello,

It seems like linux replaces sock with tcp_tw_bucket structure in the
sock list in order to "work around the memory consumption problems for
the heavilly loaded server".

The header file tcp.h has some comments before declaring
"tcp_tw_bucket" structure. It is done in tcp_input.c.

But anyway, tcp_tw_bucket is never identical to sock structure. This
is a serious hack and I'm suprised no linux kernel documentation talks
about it.

I just wanted to let others know so that no one else faces this
problem.

--
Sourav






















>
> im a kernel newbie here so pardon "the blind leading the blind" ...
>
> doing a quick search for all calls to sk_alloc in the entire kernel
> sources
> yields only one call that sets the "zero out the allocated struct"
> boolean
> to false and that is:
> net/ipv4/tcp_minisocks.c:tcp_create_openreq_child().
> this funtion in turn is only ever called from:
> net/ipv[46]/tcp_ipv[46].c:tcp_v[46]_syn_recv_sock()
>
> the comment above the ipv4 version is (verbatim):
>
> /*
> * The three way handshake has completed - we got a valid synack -
> * now create the new socket.
> */
>
> so if you need those experimental values of yours zeroed out on socket
> creation i suggest replacing this snippet from
> net/core/sock.c:sk_alloc()
>
> if(sk && zero_it) {
> memset(sk, 0, sizeof(struct sock));
> sk->family = family;
> sock_lock_init(sk);
> }
>
> with
>
> if( sk ) {
> /* set your NULL init values here */
> if( zero_it ) {
> memset(sk, 0, sizeof(struct sock));
> sk->family = family;
> sock_lock_init(sk);
> }
> }
>
> doh! i just re-read your mail and realized youre using the 2.2.15
> kernel.
> my examples are from the 2.4.2 sources...
>
> looking at the 2.2.16 source (i have only 2.2.1[46] and not 2.2.15 for
> the
> 2.2 series) the (roughly) congruent if block of code is:
>
> if(sk) {
> if (zero_it)
> memset(sk, 0, sizeof(struct sock));
> sk->family = family;
> }
>
> and so if you're setting your init values to NULL under the "zero_it"
> condition you would get the behavior that you reported.
>
> hope that helps.