Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Feb 2009 08:19:22 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-hackers@freebsd.org
Cc:        Nikola =?utf-8?q?Kne=C5=BEevi=C4=87?= <laladelausanne@gmail.com>
Subject:   Re: blockable sleep lock (sleep mutex) 16
Message-ID:  <200902050819.22726.jhb@freebsd.org>
In-Reply-To: <FD9EC34D-DEA4-401E-A62C-B16FDAF6657C@gmail.com>
References:  <02026848-7F83-405C-B4F3-EDD8B47DA294@gmail.com> <498736C2.3040207@elischer.org> <FD9EC34D-DEA4-401E-A62C-B16FDAF6657C@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 04 February 2009 11:05:02 am Nikola Kne=C5=BEevi=C4=87 wrote:
> On 2 Feb 2009, at 19:09 , Julian Elischer wrote:
>=20
> >>> It says "non-sleepable locks", yet it classifies click_instance =20
> >>> as  sleep mutex. I think witness code should emit messages which =20
> >>> are more  clear.
> >> It is confusing, but you can't do an M_WAITOK malloc while holding =20
> >> a mutex.  Basically, sleeping actually means calling "*sleep() =20
> >> (such as mtx_sleep()) or cv_*wait*()".  Blocking on a mutex is not =20
> >> sleeping, it's "blocking".  Some locks (such as sx(9)) do "sleep" =20
> >> when you contest them.  In the scheduler, sleeping and blocking are =20
> >> actually quite different (blocking uses turnstiles that handle =20
> >> priority inversions via priority propagation, sleeping uses sleep =20
> >> queues which do not do any of that).  The underyling idea is that =20
> >> mutexes should be held for "short" periods of time, and that any =20
> >> sleeps are potentially unbounded.  Holding a mutex while sleeping =20
> >> could result in a mutex being held for a long time.
> >
> >
> > the locking overview page
> > man 9 locking
> > tries to explain this..
> > I've been pestering John to proofread it and make suggestiosn for a =20
> > while now.
>=20
>=20
> Thanks John and Julian. I agree, man pages should be more clear :)
>=20
> I've switched from using mtx to sx locks, since they offer sleeping =20
> while hold.
>=20
> Unfortunately, I've ran into something really weird now, when I unload =20
> the module:
> ---8<---
> #0  doadump () at pcpu.h:195
> #1  0xffffffff8049ef98 in boot (howto=3D260) at /usr/src/sys/kern/=20
> kern_shutdown.c:418
> #2  0xffffffff8049f429 in panic (fmt=3DVariable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xffffffff8075cd26 in trap_fatal (frame=3D0xc, eva=3DVariable "eva" i=
s =20
> not available.
> ) at /usr/src/sys/amd64/amd64/trap.c:764
> #4  0xffffffff8075da62 in trap (frame=3D0xffffffff87699940) at /usr/src/=
=20
> sys/amd64/amd64/trap.c:290
> #5  0xffffffff80743bfe in calltrap () at /usr/src/sys/amd64/amd64/=20
> exception.S:209
> #6  0xffffffff8052a411 in strcmp (s1=3D0xffffffff80824a0c "sigacts",
>      s2=3D0xffffffff877cd3a9 <Address 0xffffffff877cd3a9 out of bounds>) =
=20
> at /usr/src/sys/libkern/strcmp.c:45
> #7  0xffffffff804d7c61 in enroll (description=3D0xffffffff80824a0c =20
> "sigacts", lock_class=3D0xffffffff80a19fe0)
>      at /usr/src/sys/kern/subr_witness.c:1439
> #8  0xffffffff804d7fb1 in witness_init (lock=3D0xffffff00016f4ca8) at /=20
> usr/src/sys/kern/subr_witness.c:618
> #9  0xffffffff8049fd31 in sigacts_alloc () at /usr/src/sys/kern/=20
> kern_sig.c:3280
> #10 0xffffffff80481121 in fork1 (td=3D0xffffff0001384a50, flags=3D20, =20
> pages=3DVariable "pages" is not available.
> ) at /usr/src/sys/kern/kern_fork.c:453
> #11 0xffffffff80481450 in fork (td=3D0xffffff0001384a50, uap=3DVariable =
=20
> "uap" is not available.
> ) at /usr/src/sys/kern/kern_fork.c:106
> #12 0xffffffff8075d260 in syscall (frame=3D0xffffffff87699c80) at /usr/=20
> src/sys/amd64/amd64/trap.c:907
> #13 0xffffffff80743e0b in Xfast_syscall () at /usr/src/sys/amd64/amd64/=20
> exception.S:330
> #14 0x0000000800ca0a6c in ?? ()
> --->8---
>=20
> and in fra 7:
> (kgdb) p *w
> $5 =3D {w_name =3D 0xffffffff877cd3a9 <Address 0xffffffff877cd3a9 out of =
=20
> bounds>, w_class =3D 0xffffffff80a19fe0, w_list =3D {
>      stqe_next =3D 0xffffffff80accce0}, w_typelist =3D {stqe_next =3D =20
> 0xffffffff80accce0}, w_children =3D 0x0,
>    w_file =3D 0xffffffff877d1fa0 <Address 0xffffffff877d1fa0 out of =20
> bounds>, w_line =3D 307, w_level =3D 0, w_refcount =3D 2,
>    w_Giant_squawked =3D 0 '\0', w_other_squawked =3D 0 '\0', =20
> w_same_squawked =3D 0 '\0', w_displayed =3D 0 '\0'}
> (kgdb) p *w->w_class
> $6 =3D {lc_name =3D 0xffffffff808564e0 "sleep mutex", lc_flags =3D 9, =20
> lc_ddb_show =3D 0xffffffff80492e6b <db_show_mtx>,
>    lc_lock =3D 0xffffffff804938be <lock_mtx>, lc_unlock =3D =20
> 0xffffffff804933fc <unlock_mtx>}
>=20
> This happens after modevent exists.
>=20
> What puzzles me here is w_refcount of 2, while w_name is out of =20
> bounds. Locks I've created I properly destroyed (at least I think I =20
> did :)).

You are probably missing some sx_destroy()'s.  You need to destroy each loc=
k=20
you create with sx_init().

=2D-=20
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200902050819.22726.jhb>