Date: Sun, 8 Oct 2017 11:33:07 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Don Lewis <truckman@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r324313 - head/sys/amd64/amd64 Message-ID: <20171008083307.GG95911@kib.kiev.ua> In-Reply-To: <201710072054.v97Ks5nX062548@gw.catspoiler.org> References: <20171007201142.GE95911@kib.kiev.ua> <201710072054.v97Ks5nX062548@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 07, 2017 at 01:54:05PM -0700, Don Lewis wrote: > On 7 Oct, Konstantin Belousov wrote: > > On Sat, Oct 07, 2017 at 01:04:09PM -0700, Don Lewis wrote: > >> On 5 Oct, Konstantin Belousov wrote: > >> > Author: kib > >> > Date: Thu Oct 5 12:50:03 2017 > >> > New Revision: 324313 > >> > URL: https://svnweb.freebsd.org/changeset/base/324313 > >> > > >> > Log: > >> > Avoid a race betweem freeing LDT and context switches. > >> > > >> > cpu_switch.S uses curproc->p_md.md_ldt value as the flag indicating > >> > presence of the process LDT. The flag is checked and then ldt segment > >> > descriptor is copied into the CPU' GDT slot. > >> > > >> > Disallow context switches around clearing of the curproc LDT state by > >> > performing the cleanup in critical section. Ensure that the md_ldt > >> > flag is cleared before md_ldt_sd descriptor content is destroyed by > >> > inserting fence between the operations. > >> > > >> > We depend on the x86 memory model strong ordering guarantees, in > >> > particular, that cpu_switch.S observes the writes to md_ldt and > >> > md_ldt_sd in the expected order. > >> > >> I don't know which of this series of commits is responsible, but I think > >> that it fixed the build of lang/ghc on Ryzen. > >> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029#c102 > > > > Does ghc use LDT on amd64 ? This sounds unbelievable. > > I have no idea, but ghc would reliably fail to build on my Ryzen machine > up through r323398, and at r324367 it seems to reliably build. Could you try to bisect ? I reviewed all kernel changes and do not see anything which could be marked as possible fix for whatever kernel issue causing usermode fault.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171008083307.GG95911>