From owner-svn-src-head@FreeBSD.ORG Tue May 20 15:44:18 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1D56657; Tue, 20 May 2014 15:44:18 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7445422BF; Tue, 20 May 2014 15:44:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s4KFiCDn068092; Tue, 20 May 2014 18:44:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s4KFiCDn068092 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s4KFiCTT068091; Tue, 20 May 2014 18:44:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 20 May 2014 18:44:12 +0300 From: Konstantin Belousov To: Julian Elischer Subject: Re: svn commit: r266464 - in head/sys: kern sys vm Message-ID: <20140520154412.GM74331@kib.kiev.ua> References: <201405200919.s4K9JZvg087765@svn.freebsd.org> <537B7625.4080908@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c0R9lMW4BuILQA0o" Content-Disposition: inline In-Reply-To: <537B7625.4080908@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 15:44:19 -0000 --c0R9lMW4BuILQA0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 20, 2014 at 11:35:01PM +0800, Julian Elischer wrote: > On 5/20/14, 5:19 PM, Konstantin Belousov wrote: > > Author: kib > > Date: Tue May 20 09:19:35 2014 > > New Revision: 266464 > > URL: http://svnweb.freebsd.org/changeset/base/266464 > > > > Log: > > When exec_new_vmspace() decides that current vmspace cannot be reused > > on execve(2), it calls vmspace_exec(), which frees the current > > vmspace. The thread executing an exec syscall gets new vmspace > > assigned, and old vmspace is freed if only referenced by the current > > process. The free operation includes pmap_release(), which > > de-constructs the paging structures used by hardware. > > =20 > > If the calling process is multithreaded, other threads are suspended > > in the thread_suspend_check(), and need to be unsuspended and run to > > be able to exit on successfull exec. Now, since the old vmspace is > > destroyed, paging structures are invalid, threads are resumed on the > > non-existent pmaps (page tables), which leads to triple fault on x86. > > =20 > > To fix, postpone the free of old vmspace until the threads are resum= ed > > and exited. To avoid modifications to all image activators all of > > which use exec_new_vmspace(), memoize the current (old) vmspace in > > kern_execve(), and notify it about the need to call vmspace_free() > > with a thread-private flag TDP_EXECVMSPC. > I was sure that we covered this case at some time in the past.. > I think all threads but the caller were killed at the kernel boundary=20 > and exec waited for that to happen. No, what you describe cannot be done. Threads cannot be killed until we are committed for exec to either success, or we do not have any other route except killing the process. If we return in the context of the image executing execve(2), then we must return an error, and other threads must survive. Threads are gracefully terminated after the kern_exec() committed to something. This is correctly handled in the code, except the glitch fixed in the commit. --c0R9lMW4BuILQA0o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTe3hMAAoJEJDCuSvBvK1B9HYQAKAroFKlgE3OPMMLyQHNWaiM V6q2swFPi4Uv9mM0PnD3t9kkuBMgeUGw5GAH41cimhOjJ7BRQW9ECP0Sp+78wWSx F7Fc+7WH7Zo6NfKy6irBvJbKmp79HGMkedIE2FcRu//P/BVZuzwohtkSS6gwr77m CCe+iCI5MrfaEixIxAXNIAmYuoryjn1bDnum5UrSHcnqmg5J7hM9ak7OoafYPgob rueb0vpVHXvdqjyVHHqZmQ6Wsn1OP97cPCKgPfi57YwjZ7Gdl3ft1FjzNodOyUHe v/0ROBudKQFLL0JbN7a/9/hDXbmqys+K8gyDfKm/KAWpC5O+yLkuaa5mtZPuVEvK HSWLr2uv8FyW+R5bw0FebpVYyqHTNxvLpkSDSG30GphmehQRDDJgC+xv1d5UN3SL J8JIcrwDltlefArnnHrJe5LIHsRqCba8X3MrRbLN5zE2Ci9r11FzQ/BPkVrd4gLP sD7zvCuh3uhv5LoIN4sLPMXv5mmtKj78zJpXrR9ZHtWO8ONBFq4+iTdGEMHOD18+ aU2VobSn5aQHohB51NmhGeD7TPvf+gi8EfFKVjbUEhjpr7bpFW9Tp7LpQww/w7Cl ScmygybfSOjCg4uy2sP4VDHU8QFLGutFsizMaw6UviZ5NMsRUR4QpLljG3bpqLdx 1SVpeqetTye/4ZmS2fJd =Vohx -----END PGP SIGNATURE----- --c0R9lMW4BuILQA0o--