[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion "!cpu_softintr_p()" ... subr_kmem.c
The following reply was made to PR kern/41918; it has been noted by GNATS.
From: Frank Kardel <kardel%netbsd.org@localhost>
Subject: Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion
Date: Sun, 23 Aug 2009 08:43:16 +0200
Besides that there is always room for improvement, the problem occurred
just recently - a feeled 1-2weeks ago (I noticed it with my -current
update of last week).
So it is likely the deferral of the setting of link-local and loopback
addresses to a thread. The workqueue setup code uses kmem_zalloc that
imports the non softintr
requirement into in6_ifattach() (in6_ifattach.c:1.83 2009-08-13). Using
malloc() instead might be an option (in6_createmkludge()) does that.
Martin Husemann wrote:
> The following reply was made to PR kern/41918; it has been noted by GNATS.
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Subject: Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion
> "!cpu_softintr_p()" ... subr_kmem.c
> Date: Sun, 23 Aug 2009 00:32:58 +0200
> On Sat, Aug 22, 2009 at 11:40:00AM +0000, kardel%pip.acrys.com@localhost
> > The violation of calling kmem_zalloc() (likely in
> > in6_ifaddrs_schedule()) from a softint seems clear.
> > Possibly pppoe shouldn't call in6_ifattach from softint.
> Pppoe does not call in6_ifattach, but if_up().
> I don't see why this should not be allowed from a softint (so IMHO the upper
> layers should be fixed instead), but if we decide it isn't allowed to do so,
> we could move it to a full thread context, though I don't like that either.
> The way IFF_UP is used in this code certainly is ... uhm ... "creative",
> so completely reworking it is worth considering, but not as simple
> a task at it looks at first glance.
Main Index |
Thread Index |