From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IVexX-00044G-HY
	for qemu-devel@nongnu.org; Wed, 12 Sep 2007 23:01:39 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1IVexW-000444-Uc
	for qemu-devel@nongnu.org; Wed, 12 Sep 2007 23:01:39 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IVexW-000441-Pk
	for qemu-devel@nongnu.org; Wed, 12 Sep 2007 23:01:38 -0400
Received: from phoenix.bawue.net ([193.7.176.60] helo=mail.bawue.net)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <ths@networkno.de>) id 1IVexV-0005gY-W1
	for qemu-devel@nongnu.org; Wed, 12 Sep 2007 23:01:38 -0400
Date: Thu, 13 Sep 2007 04:00:23 +0100
From: Thiemo Seufer <ths@networkno.de>
Subject: Re: [Qemu-devel] [PATCH] fix SMB-related lockup on some systems
Message-ID: <20070913030023.GD15247@networkno.de>
References: <200708271040.47752.jwalt@garni.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <200708271040.47752.jwalt@garni.ch>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?iso-8859-1?Q?J=F6rg?= Walter <jwalt@garni.ch>
Cc: qemu-devel@nongnu.org

J=F6rg Walter wrote:
> Hi!
>=20
> I have found a bug where qemu would sit in an endless loop whenever "-smb=
" was=20
> enabled and accessed. It is probably the same problem some people in the =
user=20
> forums talk about, and here's my analysis and fix:
>=20
> On glibc systems with NPTL, fork() is not atomic with regard to signals, =
while=20
> on non-NPTL-systems, it is. This behaviour is considered to be correct by=
 the=20
> libc developers, as no relevant spec forbids this behaviour.
>=20
> See this thread for details:
> http://sourceware.org/ml/libc-hacker/2007-02/msg00009.html
>=20
> In qemu, accessing the SMB ip-address causes the slirp code to issue a fo=
rk in=20
> slirp/misc.c, which hangs, as we are in mid-emulation and SIGALARM signal=
s=20
> come in at a high rate, probably triggering the above mentioned behaviour.
>=20
> This patch solves the problem by temporarily blocking all signals until t=
he=20
> fork is over. It doesn't unblock signals in the child, as I assume that=
=20
> executing the server program will care for that anyways. It works for me,=
=20
> finally I can access "-smb"-folders again.
>=20
> --=20
> CU
>   J=F6rg

> --- slirp/misc.c	2007-08-27 10:30:20.000000000 +0200
> +++ slirp/misc.c.new	2007-08-27 10:29:50.000000000 +0200
> @@ -313,6 +313,7 @@
>  	int opt;
>          int master;
>  	char *argv[256];
> +	int mask;
>  #if 0
>  	char buff[256];
>  #endif
> @@ -346,8 +347,10 @@
>  		}
>  	}
>  =09
> +	mask =3D sigsetmask(~0);
>  	switch(fork()) {
>  	 case -1:
> +	 	sigsetmask(mask);
>  		lprint("Error: fork failed: %s\n", strerror(errno));
>  		close(s);
>  		if (do_pty =3D=3D 2)
> @@ -426,6 +429,7 @@
>  		exit(1);
>  	=09
>  	 default:
> +	 	sigsetmask(mask);
>  		if (do_pty =3D=3D 2) {
>  			close(s);
>  			so->s =3D master;

Could you rewrite this using pthread_sigmask, to make it thread safe?


Thiemo