All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alain Fauconnet <alain@cscoms.net>
To: kuznet@ms2.inr.ac.ru
Cc: linux-kernel@vger.kernel.org, lve@ns.aanet.ru
Subject: Re: UPD: Frequent/consistent panics in 2.4.19 at ip_route_input_slow, in_dev_get(dev)
Date: Tue, 29 Oct 2002 11:13:30 +0700	[thread overview]
Message-ID: <20021029111330.C15782@cscoms.net> (raw)
In-Reply-To: <200210290130.EAA19804@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Oct 29, 2002 at 04:30:25AM +0300

On Tue, Oct 29, 2002 at 04:30:25AM +0300, kuznet@ms2.inr.ac.ru wrote:

> > I assume that the kernel is trying to use dynamic memory that has been
> > released already, right?
> 
> Right.
> 
> > What's next in tracing this one down?
> 
> To tell what exactly driver makes this. Apparently, it continues
> to inject packets to the stack even after it has been destroyed.
>

In  this  case,  would  they  be  packets  TO  or FROM the ppp device?
(reminder:  crash  happens  in ip_route_input_slow, called with struct
net_device *dev presumably pointing at what used to be the PPP device)

> If you did not see message "Freeing alive device", this means
> that driver unregistered it. Usual ppp seems to be sane...

No such message in logs, but  "PPPIOCDETACH  file->f_count=3"  appears
quite often. If I understand it right, it'd mean that the ppp interface
is destroyed while having channels open to  it...  Does  it  give  any
hint?

Let's try to summarize anything unusual this box has:

- pptp  (PoPToP). But pptp is only userland software, how could it cause
such a problem? It merely forks pppd as a child.

- NAT, both SNAT and DNAT (for transparent redirection to a Squid),  and
a lot of rules used to do traffic accounting so iptables configuration
is kind of hairy. Could it somehow cause packets to be  "delayed"  and
thus re-injected to the stack later than  usual?  (I'm  probably  just
talking nonsense here - sorry - trying to guess).

- assymetrical routing: packets come from clients over VPN, thus over the
PPP  interface.  They are routed back though a LAN interface that goes
to the satellite uplink. To do this, the route to the peer IP  through
the PPP interface is deleted in the ip-up script.

Ah..  something  else that could be relevant (??): I see that ifconfig
-a shows "duplicate" ppp devices e.g.:

ppp96     Link encap:Point-to-Point Protocol  
          inet addr:xxx.yyy.zzz.2  P-t-P:172.16.27.104  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:44238 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:2192741 (2.0 Mb)  TX bytes:153 (153.0 b)

ppp96     Link encap:Point-to-Point Protocol  
          inet addr:xxx.yyy.zzz.2  P-t-P:172.16.27.104  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

Is this "normal"?

Greets,
_Alain_


  reply	other threads:[~2002-10-29  4:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-21  3:02 UPD: Frequent/consistent panics in 2.4.19 at ip_route_input_slow, in_dev_get(dev) Alain Fauconnet
2002-10-21 16:40 ` kuznet
2002-10-22  3:24   ` Alain Fauconnet
2002-10-28 10:19   ` Alain Fauconnet
2002-10-29  1:30     ` kuznet
2002-10-29  4:13       ` Alain Fauconnet [this message]
2002-10-29  4:31         ` kuznet

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=20021029111330.C15782@cscoms.net \
    --to=alain@cscoms.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lve@ns.aanet.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.