Date: Mon, 22 Nov 2010 12:11:34 +0100 From: Alexander Leidinger <netchild@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com>, rdivacky@FreeBSD.org Cc: emulation@FreeBSD.org Subject: Re: svn commit: r215664 - in head/sys: compat/linux kern Message-ID: <20101122121134.1202791p75lfy1og@webmail.leidinger.net> In-Reply-To: <20101122104232.GY2392@deviant.kiev.zoral.com.ua> References: <201011220907.oAM970To084256@svn.freebsd.org> <20101122093134.GU2392@deviant.kiev.zoral.com.ua> <20101122111306.16504je0tt7xe5us@webmail.leidinger.net> <20101122104232.GY2392@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Moving the thread to emulation@, adding Roman (please see at the end). Quoting Kostik Belousov <kostikbel@gmail.com> (from Mon, 22 Nov 2010 12:42:32 +0200): > On Mon, Nov 22, 2010 at 11:13:06AM +0100, Alexander Leidinger wrote: >> Quoting Kostik Belousov <kostikbel@gmail.com> (from Mon, 22 Nov 2010 >> 11:31:34 +0200): >> >> >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. >> >>+ >> >> 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); >> >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). >> >> How critical is this in your opinion (relative to the issue this patch >> is fixing)? Do you prefer a backout or do you think the probability >> that the someone wins the race is low enough? >> >> Do you see a solution for the race? > I did not asked for backout, nor I am asking now. > > Most likely, the semantic of linux thread groups cannot be implemented > by only using event handlers that linux.ko hooks now. How linux handles > single-threading when doing execve(2) from multithreaded process ? Roman, can your memory help out here? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 BOFH excuse #344: Network failure - call NBC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101122121134.1202791p75lfy1og>