Date: Thu, 10 Aug 2006 11:33:37 -0500 From: Brooks Davis <brooks@one-eyed-alien.net> To: Divacky Roman <xdivac02@stud.fit.vutbr.cz> Cc: hackers@freebsd.org Subject: Re: SoC: help with LISTs and killing procs Message-ID: <20060810163337.GA22097@lor.one-eyed-alien.net> In-Reply-To: <20060810161705.GB19047@stud.fit.vutbr.cz> References: <20060810151616.GA17109@stud.fit.vutbr.cz> <20060810152359.GA21318@lor.one-eyed-alien.net> <20060810153543.GA19047@stud.fit.vutbr.cz> <20060810154305.GA21483@lor.one-eyed-alien.net> <20060810161705.GB19047@stud.fit.vutbr.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Aug 10, 2006 at 06:17:05PM +0200, Divacky Roman wrote:
> On Thu, Aug 10, 2006 at 10:43:05AM -0500, Brooks Davis wrote:
> > On Thu, Aug 10, 2006 at 05:35:43PM +0200, Divacky Roman wrote:
> > > On Thu, Aug 10, 2006 at 10:23:59AM -0500, Brooks Davis wrote:
> > > > On Thu, Aug 10, 2006 at 05:16:17PM +0200, Divacky Roman wrote:
> > > > > hi
> > > > >=20
> > > > > I am doing this:
> > > > >=20
> > > > > (pseudocode)
> > > > > LIST_FOREACH_SAFE(em, &td_em->shared->threads, threads, tmp_em) {
> > > > >=20
> > > > > kill(em, SIGKILL);
> > > > > }
> > > > >=20
> > > > > kill(SIGKILL) calls exit() which calls my exit_hook()
> > > > >=20
> > > > > my exit_hook() does LIST_REMOVE(em, threads).
> > > > >=20
> > > > > the problem is that this is not synchronous so I am getting a pan=
ic by INVARIANTS
> > > > > that "Bad link elm prev->next !=3D elm". This is because I list 1=
st item in the list
> > > > > I call kill on it, then process 2nd list, then scheduler preempts=
my code and calls
> > > > > exit() on the first proc which removes the first entry and bad th=
ings happen.=20
> > > > >=20
> > > > > I see this possible solutions:
> > > > >=20
> > > > > make this synchronous, it can be done by something like:
> > > > >=20
> > > > > ....
> > > > > kill(em, SIGKILL);
> > > > > wait_for_proc_to_vanish();
> > > > >=20
> > > > > pls. tell me what do you think about this solution and if its cor=
rect what is the wait_for_proc_to_vanish()
> > > > >=20
> > > > > maybe there's some better solution, pls tell me.
> > > >=20
> > > > It sounds like you need a lock protecting the list. If you held it=
over
> > > > the whole loop you could signal all processes before the exit_hook =
could
> > > > remove any.
> > >=20
> > > I dont understand. I am protecting the lock by a rw_rlock();
> > >=20
> > > the exit_hook() then acquires rw_wlock(); when removing the entry.
> > > what exactly do you suggest me to do? I dont get it.
> >=20
> > This can't be the case. If you're holding a read lock around the
> > loop (it must cover the entire loop), it should not be possible for the
> > exit_hook() to obtain a write lock while you are in the loop. Just to
> > verify, is the lock for the list and not per element?
>=20
> oh.. I see whats going on.. in the exit_hook I am doing this:
>=20
>=20
> em =3D em_find(p->p_pid, EMUL_UNLOCKED); // this performs EMUL_RLOC=
K(&emul_lock);
> ...
> EMUL_RUNLOCK(&emul_lock);
> =09
> EMUL_WLOCK(&emul_lock);
> LIST_REMOVE(em, threads);
> SLIST_REMOVE(&emuldata_head, em, linux_emuldata, emuldatas);
> EMUL_WUNLOCK(&emul_lock);
> =20
> the EMUL_RUNLOCK() unlocks it so it doesnt wait. This should be turned in=
to rw_try_upgrade()
> but I dont understand how ;(
>=20
> anyway, I still dont understand how should I use the lock to achieve the =
synchronization.
>=20
> my code looks like:
>=20
> EMUL_RLOCK(&emul_lock);
> LIST_FOREACH_SAFE(em, &td_em->shared->threads, threads, tmp_em) {
> }
> EMUL_RUNLOCK(&emul_lock);
>=20
> what do you suggest? I need to process the list first and then let the
> exit_hook in the various processes run.
I'll admit to not being super familiar with the rwlock code, but unless
exit_hook is being run in the same context as loop (i.e. the signal
handling isn't asynchronous) the unlock shouldn't result in the release
of the loops' reader lock and thus the write lock request should fail.
-- Brooks
--liOOAslEiF7prFVr
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFE21/hXY6L6fI4GtQRAirjAKCxdwcw78bOADcRGwRcfazKUnD0JQCfZGhP
llKfXRb6rd2I9HYpT96oocI=
=HdX9
-----END PGP SIGNATURE-----
--liOOAslEiF7prFVr--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060810163337.GA22097>