Date: Sun, 2 Mar 2008 22:06:47 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: current@freebsd.org Subject: Re: knlist_cleardel() panic Message-ID: <20080302200647.GQ57756@deviant.kiev.zoral.com.ua> In-Reply-To: <20080302195334.GI96595@funkthat.com> References: <20080302152523.GO57756@deviant.kiev.zoral.com.ua> <20080302195334.GI96595@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--hMG3mwLWsaCgkvvK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Mar 02, 2008 at 11:53:34AM -0800, John-Mark Gurney wrote:
> Kostik Belousov wrote this message on Sun, Mar 02, 2008 at 17:25 +0200:
> > The panic below was already reported, but now I got it on my desktop
> > and was able to investigate further.
> >=20
> > #5 0xc06daf36 in trap (frame=3D0xe8093b1c)
> > at /usr/bsd/src/sys/i386/i386/trap.c:490
> > #6 0xc06c0b4b in calltrap () at /usr/bsd/src/sys/i386/i386/exception.s=
:139
> > #7 0xc0493968 in knlist_cleardel (knl=3D0xcabec128, td=3D0x0, islocked=
=3D1,=20
> > killkn=3D0) at atomic.h:149
> > #8 0xc04f520c in pipeclose (cpipe=3D0xcabec0b8)
> > at /usr/bsd/src/sys/kern/sys_pipe.c:1508
> > #9 0xc04f5320 in pipe_close (fp=3D0xc5ce8630, td=3D0xcac01aa0)
> > at /usr/bsd/src/sys/kern/sys_pipe.c:1425
> > #10 0xc0489442 in fdrop (fp=3D0xc5ce8630, td=3D0xcac01aa0) at file.h:297
> > #11 0xc048accf in closef (fp=3D0xc5ce8630, td=3D0xcac01aa0)
> > at /usr/bsd/src/sys/kern/kern_descrip.c:1958
> > #12 0xc048b1ff in kern_close (td=3D0xcac01aa0, fd=3D10)
> > at /usr/bsd/src/sys/kern/kern_descrip.c:1054
> > #13 0xc048b2da in close (td=3D0xcac01aa0, uap=3D0xe8093cfc)
> > at /usr/bsd/src/sys/kern/kern_descrip.c:1006
> > ---Type <return> to continue, or q <return> to quit---
> > #14 0xc06da865 in syscall (frame=3D0xe8093d38)
> > at /usr/bsd/src/sys/i386/i386/trap.c:1035
> > #15 0xc06c0bb0 in Xint0x80_syscall ()
> > at /usr/bsd/src/sys/i386/i386/exception.s:196
> >=20
> > At the frame 8, we have
> > (kgdb) p/x *(knl->kl_list->slh_first)
> > $9 =3D {kn_link =3D {sle_next =3D 0x0}, kn_selnext =3D {sle_next =3D 0x=
0},
> > kn_knlist =3D 0x0, kn_tqe =3D {tqe_next =3D 0xc58de484, tqe_prev =3D =
0xc5e9ab20},
> > kn_kq =3D 0x0, kn_kevent =3D {ident =3D 0x0, filter =3D 0x0, flags =
=3D 0x0,
> > fflags =3D 0x0, data =3D 0x0, udata =3D 0x0}, kn_status =3D 0x20,
> > kn_sfflags =3D 0x0, kn_sdata =3D 0x0, kn_ptr =3D {p_fp =3D 0x0, p_pro=
c =3D 0x0,
> > p_aio =3D 0x0, p_lio =3D 0x0}, kn_fop =3D 0x0, kn_hook =3D 0x0}
> >=20
> > The knote is KN_MARKER, and the kn_kq is NULL. The result is that KQ_LO=
CK
> > in the knlist_cleardel()::SLIST_FOREACH_SAFE() loop dereferences NULL a=
nd
> > panics.
> >=20
> > Does the following change makes any sense?
>=20
> I thought this was a bug, but upon further examination, there is
> something wrong... a KN_MARKER knote should never be on the knlist..
> It is only ever added to kq's even list, never to an object's list...
>=20
> If you could walk the knl->kl_list through kn_selnext, and ensure
> that the kn w/ kN_MARKER exists would be good... It should be
> last one as kn_selnext is NULL...
As I shown above, the KN_MARKER was found on the cpipe->pipe_sel.si_note,
(kgdb) p cpipe->pipe_sel.si_note
$1 =3D {kl_list =3D {slh_first =3D 0xc58df330},=20
kl_lock =3D 0xc0493a20 <knlist_mtx_lock>,=20
kl_unlock =3D 0xc0493370 <knlist_mtx_unlock>,=20
kl_locked =3D 0xc0493350 <knlist_mtx_locked>, kl_lockarg =3D 0xcabec170
}
(kgdb) p/x (knl->kl_list->slh_first)
$2 =3D 0xc58df330
(kgdb) p/x *(knl->kl_list->slh_first)
$3 =3D {kn_link =3D {sle_next =3D 0x0}, kn_selnext =3D {sle_next =3D 0x0},=
=20
kn_knlist =3D 0x0, kn_tqe =3D {tqe_next =3D 0xc58de484, tqe_prev =3D 0xc5=
e9ab20},=20
kn_kq =3D 0x0, kn_kevent =3D {ident =3D 0x0, filter =3D 0x0, flags =3D 0x=
0,=20
fflags =3D 0x0, data =3D 0x0, udata =3D 0x0}, kn_status =3D 0x20,=20
kn_sfflags =3D 0x0, kn_sdata =3D 0x0, kn_ptr =3D {p_fp =3D 0x0, p_proc =
=3D 0x0,=20
p_aio =3D 0x0, p_lio =3D 0x0}, kn_fop =3D 0x0, kn_hook =3D 0x0}
>=20
> I can't think of a way that this can happen, as the only way to get
> on the knlist is by calling knlist_add, and it should only ever be
> called from f_attach, which is called in one place, and has to have
> kn_kq set properly... Are there any custom patches on the system?
This is the stock RELENG_7 as of today.
--hMG3mwLWsaCgkvvK
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (FreeBSD)
iEYEARECAAYFAkfLCNcACgkQC3+MBN1Mb4g2FwCgikWbgwT1LvgAGt3kEiZxtgqq
2TgAoPXUgoqBtJJUeEU3MJy2+Yw83Wdh
=+G2X
-----END PGP SIGNATURE-----
--hMG3mwLWsaCgkvvK--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080302200647.GQ57756>