All of lore.kernel.org
 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 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.