Date: Tue, 20 May 2014 18:44:12 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r266464 - in head/sys: kern sys vm Message-ID: <20140520154412.GM74331@kib.kiev.ua> In-Reply-To: <537B7625.4080908@freebsd.org> References: <201405200919.s4K9JZvg087765@svn.freebsd.org> <537B7625.4080908@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140520154412.GM74331>