linux-um archives
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] problems with ifup-a on etch compiled kernels
Date: Mon, 06 Nov 2006 13:44:56 -0800	[thread overview]
Message-ID: <eioacp$m4r$1@sea.gmane.org> (raw)
In-Reply-To: <eilvlj$b5r$1@sea.gmane.org>

Michael Richardson wrote:
> I don't know whether to blame a recent update to debian testing from stable --- likely it would be a glibc issue, but...
> I did run into the _syscall0() problem after that, and I found that I could get around it by appropriately #define 
> _KERNEL prior to #include <linux/unistd.h>. What I don't get about the remark of Paolo is that _syscall0() is a userland 
> thing, not a kernel thing.
> 
> I.e. any user program should be able to use _syscall() to get an open coded call to the kernel.
> 
> Anyway, my problem: 2.6.15, 2.6.17.13 (both patched as above), and 2.6.19-rc3 all fail during ifup -a:
> 
> + echo -n 'Configuring network interfaces: '
> Configuring network interfaces: + ifup -a
> BUG: soft lockup detected on CPU#0!
> 083bf9f0:  [<080632a2>] dump_stack+0x22/0x30
> 083bfa08:  [<080a25c4>] softlockup_tick+0x84/0xa0
> 083bfa20:  [<0808ca32>] run_local_timers+0x12/0x20
> 083bfa28:  [<0808c796>] update_process_times+0x36/0x90
> 083bfa48:  [<080636fc>] timer_handler+0x3c/0x70
> 083bfa64:  [<080798f9>] sig_handler_common_skas+0xa9/0x100
> 083bfa88:  [<08075413>] real_alarm_handler+0x23/0x60
> 083bfaa0:  [<080754a2>] alarm_handler+0x52/0x70
> 083bfabc:  [<08077eda>] hard_handler+0x1a/0x20
> 083bfacc:  [<ffffe420>] _etext+0xf7df5404/0x0
> 083bfe14:  [<081a3431>] inet_ioctl+0x61/0xa0
> 083bfe2c:  [<081525a4>] sock_ioctl+0x144/0x2b0

I've tracked this down to a number of places. It looks like the ifa->ifa_dev is not
valid when the notification chain is called:

08707a08:  [<08074329>] sig_handler_common_skas+0xa9/0x120
08707a30:  [<0806ff25>] sig_handler+0x35/0x70
08707a4c:  [<080728ea>] hard_handler+0x1a/0x20
08707a5c:  [<ffffe420>] _etext+0xf7defac0/0x0
08707d64:  [<0808bcdc>] notifier_call_chain+0x6c/0x90
08707d94:  [<0808beb0>] blocking_notifier_call_chain+0x30/0x50
08707db0:  [<081a2d14>] __inet_insert_ifa+0xd4/0x160
08707dd4:  [<081a2dbd>] inet_insert_ifa+0x1d/0x20

The stack item <ffffe420>] _etext+0xf7defac0/0x0, seems to be bogus. I instrumented
kernel/sys.c, to print the functions which notifier_call_chain was calling,
and learnt that it was crashing in arch/um/drivers/net_kern.c because of:
	struct net_device *dev = ifa->ifa_dev->dev;

in uml_inetaddr_event.

sure enough, ifa->ifa_dev was NULL. Naturally, if I run things manually, or under GDB, it fails.
Furthermore, this happens with 2.6.15 and 2.6.17.13 (patched to compile on etch), and
with 2.6.19-rc3 (which I'm using as my debug base).  I tried with gcc-3.3 and with gcc-4.1.2.

So, whatever is going on is related somehow to the glibc, (my guess), but represents some
real bug that has been hidden for awhile.

I patched around the problem in uml_inetaddr_event (return immediately if ifa_dev==NULL), and found
the next instance of it net/ipv4/fib_frontend.c, in fib_netdev_event.
Clearly, either we aren't initializing something right, or it's getting blown away at some point.
Perhaps a different malloc policy in this glibc?

I will spend the rest of today on this (I'm at IETF in San Diego), but afterwards,
I'll begin to start reverting to sarge (if I can), so that I can continue working on my real problem.
I should be on IRC and in jabber. (mrcharlesr@gmail.com, mrichardson@ecotroph.net).

(Hmm. I'm trying Mozilla news for gmane.org reading. I don't like the composer much, I have no
idea what column I'm on...)


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2006-11-06 21:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-06  0:29 [uml-devel] problems with ifup-a on etch compiled kernels Michael Richardson
2006-11-06 21:44 ` Michael Richardson [this message]
2006-11-06 22:01   ` Michael Richardson
2006-11-07 19:32     ` Michael Richardson
2006-11-08 18:10   ` Jeff Dike
2006-11-08 23:04     ` Michael Richardson
2006-11-13 21:21     ` Michael Richardson

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='eioacp$m4r$1@sea.gmane.org' \
    --to=mcr@sandelman.ca \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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