From owner-svn-src-all@FreeBSD.ORG Mon Nov 22 11:11:18 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5788A1065710; Mon, 22 Nov 2010 11:11:18 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 875AA8FC14; Mon, 22 Nov 2010 11:11:16 +0000 (UTC) Received: by ewy3 with SMTP id 3so3670287ewy.13 for ; Mon, 22 Nov 2010 03:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Hgd+GzJf0uyruABHGlz5rrNrDJDWgJp08XIZQUlqz7k=; b=VymKE0dE7h/pqIfBD8VIhnLndRZzalmMFVa8PwjezTmawOLtaYFpdhZjfxMChnA8io xDFLIUACaWuh8BPNftq9zREP7MV4GsF55rgE/zlOqq2QN/JH1hBLOri+BjgxWGN06JXU iF+/xQkDJOS57Fv4ykGH+v5m/E6VVJB4CORWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=PxTtzoFli0yv8Z5dNGiHPgiZjKXz2AOhdkjyTXU7H3SBBkAtKiiTdaOoIru0Xdiwt2 x/PmWi14UpB1C3AZxTfip4HT+tKt86bU93AAWSGHB7rrHVKZHS9P6ZczWUN0A15U/Ntd ByLGKgHE9pn5EYYWvitZMbV0ZJ6qQnQuQYS+g= Received: by 10.213.9.140 with SMTP id l12mr7549412ebl.13.1290424276006; Mon, 22 Nov 2010 03:11:16 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id v51sm4598495eeh.16.2010.11.22.03.11.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 03:11:15 -0800 (PST) Date: Mon, 22 Nov 2010 13:11:06 +0200 From: Gleb Kurtsou To: Kostik Belousov Message-ID: <20101122111105.GA2561@tops> References: <201011220907.oAM970To084256@svn.freebsd.org> <20101122093134.GU2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20101122093134.GU2392@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Alexander Leidinger Subject: Re: svn commit: r215664 - in head/sys: compat/linux kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 11:11:19 -0000 On (22/11/2010 11:31), Kostik Belousov wrote: > On Mon, Nov 22, 2010 at 09:07:00AM +0000, Alexander Leidinger wrote: > > Author: netchild > > Date: Mon Nov 22 09:06:59 2010 > > New Revision: 215664 > > URL: http://svn.freebsd.org/changeset/base/215664 > > > > Log: > > By using the 32-bit Linux version of Sun's Java Development Kit 1.6 > > on FreeBSD (amd64), invocations of "javac" (or "java") eventually > > end with the output of "Killed" and exit code 137. > > > > This is caused by: > > 1. After calling exec() in multithreaded linux program threads are not > > destroyed and continue running. They get killed after program being > > executed finishes. > > > > 2. linux_exit_group doesn't return correct exit code when called not > > from group leader. Which happens regularly using sun jvm. > > > > The submitters fix this in a similar way to how NetBSD handles this. > > > > I took the PRs away from dchagin, who seems to be out of touch of > > this since a while (no response from him). > > > > The patches committed here are from [2], with some little modifications > > from me to the style. > > > > PR: 141439 [1], 144194 [2] > > Submitted by: Stefan Schmidt , gk > > Reviewed by: rdivacky (in april 2010) > > MFC after: 5 days > > > > Modified: > > head/sys/compat/linux/linux_emul.c > > head/sys/compat/linux/linux_emul.h > > head/sys/compat/linux/linux_misc.c > > head/sys/kern/kern_exit.c > > > > Modified: head/sys/compat/linux/linux_emul.c > > ============================================================================== > > --- head/sys/compat/linux/linux_emul.c Mon Nov 22 09:04:29 2010 (r215663) > > +++ head/sys/compat/linux/linux_emul.c Mon Nov 22 09:06:59 2010 (r215664) > > @@ -155,7 +155,7 @@ void > > linux_proc_exit(void *arg __unused, struct proc *p) > > { > > struct linux_emuldata *em; > > - int error; > > + int error, shared_flags, shared_xstat; > > struct thread *td = FIRST_THREAD_IN_PROC(p); > > int *child_clear_tid; > > struct proc *q, *nq; > > @@ -187,6 +187,8 @@ linux_proc_exit(void *arg __unused, stru > > } > > > > EMUL_SHARED_WLOCK(&emul_shared_lock); > > + shared_flags = em->shared->flags; > > + shared_xstat = em->shared->xstat; > > LIST_REMOVE(em, threads); > > > > em->shared->refs--; > > @@ -196,6 +198,12 @@ linux_proc_exit(void *arg __unused, stru > > } else > > EMUL_SHARED_WUNLOCK(&emul_shared_lock); > > > > + if ((shared_flags & EMUL_SHARED_HASXSTAT) != 0) { > > + PROC_LOCK(p); > > + p->p_xstat = shared_xstat; > > + PROC_UNLOCK(p); > > + } > Why is process lock taken there ? The assignment to u_short inside the > properly aligned structure is atomic on all supported architectures, and > the thread that should see side-effect of assignment is the same thread > that does assignment. > > > + > > if (child_clear_tid != NULL) { > > struct linux_sys_futex_args cup; > > int null = 0; > > @@ -257,6 +265,9 @@ linux_proc_exec(void *arg __unused, stru > > if (__predict_false(imgp->sysent == &elf_linux_sysvec > > && p->p_sysent != &elf_linux_sysvec)) > > linux_proc_init(FIRST_THREAD_IN_PROC(p), p->p_pid, 0); > > + if (__predict_false(p->p_sysent == &elf_linux_sysvec)) > > + /* Kill threads regardless of imgp->sysent value */ > > + linux_kill_threads(FIRST_THREAD_IN_PROC(p), SIGKILL); > This is better expressed by > if ((p->p_sysent->sv_flags & SV_ABI_MASK) == SV_ABI_LINUX) > > Regardless of this mostly cosmetic issue, this is racy. Other > linux thread in the same process might do an execve(3). > More, if execve(3) call fails, then you return into the process > that lacks all threads except the one that called execve(3). execve(3) races in linuxulator are known, and that's not the only case: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/142082 But fixing it is not easy, as you've noted in other email current hook mechanism is not good enough for it.