Hi Konstantin, On Thu, May 29, 2014 at 2:27 PM, Konstantin Belousov <[email protected]> wrote: > On Thu, May 29, 2014 at 02:19:06PM -0700, Neel Natu wrote: >> Hi, >> >> On Thu, May 29, 2014 at 3:44 AM, Peter Jeremy <[email protected]> wrote: >> > On 2014-May-29 04:38:18 +0300, Konstantin Belousov <[email protected]> >> > wrote: >> >>Hm, I think I know what is going on. Try this, please. >> >>At least, your test binary worked for me. >> > >> > Thank you. That seems to fix the problem even on non-trivial code. >> > >> >> Occasionally, I run into a problem where sys arch(I386_SET_LDT) fails >> with a ENOSPC. The golang runtime isn't checking the error return >> correctly and proceeds to load the bogus selector value into %gs. >> >> ./write >> pid 2571 comm write: signal 10 err e4 code 3 type 9 addr 0x8062446 rsp >> 0xffffdae8 rip 0x8062446 <8e e8 83 c4 20 c3 00 00> >> Bus error (core dumped) >> >> Here is the output of kdump: >> $ kdump >> capability mode sandbox enabled >> 1934 ktrace RET ktrace 0 >> 1934 ktrace CALL execve(0x7fffffffed2f,0x7fffffffeae0,0x7fffffffeaf0) >> 1934 ktrace NAMI "./write" >> 1934 write RET execve 0 >> 1934 write CALL sysarch(0x1,0xffffdb38) >> 1934 write RET sysarch -1 errno 28 No space left on device >> 1934 write PSIG SIGBUS SIG_DFL code=BUS_OBJERR >> 1934 write NAMI "write.core" >> >> In any case this is a problem because we aren't zeroing the LDT after >> allocation. Here is a patch that fixes it: >> >> Index: sys/amd64/amd64/sys_machdep.c >> =================================================================== >> --- sys/amd64/amd64/sys_machdep.c (revision 266856) >> +++ sys/amd64/amd64/sys_machdep.c (working copy) >> @@ -462,7 +462,7 @@ >> new_ldt = malloc(sizeof(struct proc_ldt), M_SUBPROC, M_WAITOK); >> new_ldt->ldt_base = (caddr_t)kmem_malloc(kernel_arena, >> max_ldt_segment * sizeof(struct user_segment_descriptor), >> - M_WAITOK); >> + M_WAITOK | M_ZERO); >> if (new_ldt->ldt_base == NULL) { >> FREE(new_ldt, M_SUBPROC); >> mtx_lock(&dt_lock); >> >> Ok to commit? > Sure, > this also should be merged back to at least stable/8.
Thanks, will do. best Neel _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "[email protected]"
