Date: Fri, 15 Feb 2013 20:31:11 -0800 From: Marc Fournier <scrappy@hub.org> To: John Baldwin <jhb@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Rick Macklem <rmacklem@uoguelph.ca>, freebsd-stable@freebsd.org Subject: Re: 9-STABLE -> NFS -> NetAPP: Message-ID: <F3CC5573-8805-446E-A7CD-DD67A4B8ABD6@hub.org> In-Reply-To: <201302150844.43188.jhb@freebsd.org> References: <1964289267.3041689.1360897556427.JavaMail.root@erie.cs.uoguelph.ca> <201302150844.43188.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Trying the patch now =85 but what do you mean by using 'SIGSTOP'? I =
generally do a 'kill -HUP' then when that doesn't work 'kill -9' =85 =
should Iuse -STOP instead of 9?
On 2013-02-15, at 5:44 AM, John Baldwin <jhb@freebsd.org> wrote:
>=20
> I think this is the right idea, but in HEAD with the sigdeferstop() =
changes it=20
> should just check for TDF_SBDRY instead of adding a new parameter. I =
think
> checking for TDF_SBDRY will work even in 9 (and will make the patch =
smaller). =20
> Also, I think this is only needed for stop signals. Other suspend =
requests=20
> will eventually resume the thread, it is only stop signals that can =
cause the=20
> thread to get stuck indefinitely (since it depends on the user sending=20=
> SIGCONT).
>=20
> Marc, are you using SIGSTOP?
>=20
> Index: kern_thread.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- kern_thread.c (revision 246122)
> +++ kern_thread.c (working copy)
> @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead)
> return (ERESTART);
>=20
> /*
> + * Ignore suspend requests for stop signals if they
> + * are deferred.
> + */
> + if (P_SHOULDSTOP(p) =3D=3D P_STOPPED_SIG &&
> + td->td_flags & TDF_SBDRY) {
> + KASSERT(return_instead,
> + ("TDF_SBDRY set for unsafe =
thread_suspend_check"));
> + return (0);
> + }
> +
> + /*
> * If the process is waiting for us to exit,
> * this thread should just suicide.
> * Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE.
>=20
> --=20
> John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F3CC5573-8805-446E-A7CD-DD67A4B8ABD6>