Linux HAM/Amateur Radio development
 help / color / mirror / Atom feed
From: 9a4gl@9a0tcp.ampr.org (Tihomir Heidelberg)
To: thomas@osterried.de
Cc: linux-hams@vger.kernel.org
Subject: Re: AX.25 unaccepted socket makes problems
Date: Wed, 28 May 03 14:29:08 CEST	[thread overview]
Message-ID: <2313@9A0TCP> (raw)

Hi,

>> also I think that skb->sk->pair should be set to NULL, because from this
>> point the pair (listening socket) does not exist any more and reference
>> to this can cause problem, right ?
>
>hmm. the listening socket exists as long the userspace application does
>listen().
>but i do not really understand the sk->pair concept.

yap, but I am talking about when listening socket is going to be
destroyed and there are some unaccepted connections made by listening
socket (lets call them CHILDs)... those CHILDs keeps living in kernel after
listening socket is destroyed... CHILDs have sk->pair pointing
to its listening socket (I really do not know who use/need that sk->pair)
but after listening socket is destroyed I think that CHILDs must not have
a reference to it anymore...

> also i have problems in understanding the concept in ax25_destroy_socket():
> skb->sk->dead is set to 1, then ax25_start_heartbeat() is called, which
> is a timer (which expires in +5s).

yap, CHILDs are destroyed after +5s (heardbeat expirity), I really do not
know why they are destroyed this way with a delay ?! Why dont we call
ax25_destroy_socket recursivly to destroy all CHILDs ? Anyone know the
reason ? They are anyway destroyed the same way on heardbeat exipirity.

> if we set it to skb->sk->state = TCP_LISTEN and our state is
> AX25_STATE_0, then this timer will call ax25_destroy_socket() again.

again, but first time it destroyed listening socket, and from timer it
destroy unaccepted socket...

> potentially running ax25_std_heartbeat_expiry(), which will use
> ax25->sk->... we have just free'd.

no, timer is handling nondestroyed socket (the CHILD)

> i have done this (interested in?). after the observation that when
> ax25rtd is running, the oops problem on ax25 cb's (which are independend
> of the ax25 route list) occorued.

yup, but when ax25_route_list is unprotected, it get broken, it is very
probably that new element in ax25_list is at memory which was used a bit
ago in ax25_route_list, anyone know if ax25_route_list also get broken
when ax25_list is broken ?

73 de Tihomir, 9a4gl@9a0tcp.ampr.org


             reply	other threads:[~2003-05-28 12:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-28 12:29 Tihomir Heidelberg [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-27 16:17 AX.25 unaccepted socket makes problems Tihomir Heidelberg
2003-05-28  0:04 ` Thomas Osterried
2003-05-28  6:46   ` Tihomir Heidelberg
2003-05-28 10:20     ` Steven Whitehouse
2003-05-28 10:25     ` Thomas Osterried

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2313@9A0TCP \
    --to=9a4gl@9a0tcp.ampr.org \
    --cc=linux-hams@vger.kernel.org \
    --cc=thomas@osterried.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox