Date: Sun, 22 Apr 2018 21:06:56 +0200 From: Tijl Coosemans <tijl@FreeBSD.org> To: Konstantin Belousov <kib@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r332489 - in head: gnu/usr.bin/gdb/kgdb sys/conf sys/dev/dcons sys/dev/hyperv/vmbus/i386 sys/dev/ppc sys/dev/syscons sys/i386/conf sys/i386/i386 sys/i386/include sys/i386/include/pc sys... Message-ID: <20180422210656.29cb7d0a@kalimero.tijl.coosemans.org> In-Reply-To: <201804132030.w3DKUnFn050153@repo.freebsd.org> References: <201804132030.w3DKUnFn050153@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Apr 2018 20:30:49 +0000 (UTC) Konstantin Belousov <kib@FreeBSD.org> wrote: > Author: kib > Date: Fri Apr 13 20:30:49 2018 > New Revision: 332489 > URL: https://svnweb.freebsd.org/changeset/base/332489 > > Log: > i386 4/4G split. > > The change makes the user and kernel address spaces on i386 > independent, giving each almost the full 4G of usable virtual addresses > except for one PDE at top used for trampoline and per-CPU trampoline > stacks, and system structures that must be always mapped, namely IDT, > GDT, common TSS and LDT, and process-private TSS and LDT if allocated. Could this have broken the linux futex syscall? I have a linux program that gets stuck in linux_sys_futex and becomes unkillable. Note that the routines in sys/i386/linux/linux_support.s try to do atomic operations on user space addresses.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180422210656.29cb7d0a>