Date: Thu, 5 Aug 2010 13:10:46 -0400 From: John Baldwin <jhb@freebsd.org> To: mdf@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: sched_pin() versus PCPU_GET Message-ID: <201008051310.46994.jhb@freebsd.org> In-Reply-To: <AANLkTimD6fMLazWwA1bMZZJCKSHdL5v-4kc1wCSVQoMZ@mail.gmail.com> References: <AANLkTikY20TxyeyqO5zP3zC-azb748kV-MdevPfm%2B8cq@mail.gmail.com> <AANLkTi=YjbBdZp9KuGUmMuYUmWyx_n%2BykikPSMMMo=j9@mail.gmail.com> <AANLkTimD6fMLazWwA1bMZZJCKSHdL5v-4kc1wCSVQoMZ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, August 05, 2010 12:01:22 pm mdf@freebsd.org wrote: > On Wed, Aug 4, 2010 at 9:20 AM, <mdf@freebsd.org> wrote: > > On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin <jhb@freebsd.org> wrote: > >> Actually, I would beg to differ in that case. If PCPU_GET(spinlocks) > >> returns non-NULL, then it means that you hold a spin lock, > > > > ll_count is 0 for the "correct" pc_spinlocks and non-zero for the > > "wrong" one, though. So I think it can be non-NULL but the current > > thread/CPU doesn't hold a spinlock. > > > > I don't believe we have any code in the NMI handler. I'm on vacation > > today so I'll check tomorrow. > > I checked and ipi_nmi_handler() doesn't appear to have any local > changes. I assume that's where I should look? The tricky bits are all in the assembly rather than in C, probably in exception.S. However, if %gs were corrupt I would not expect it to point to another CPU's data, but garbage from userland. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008051310.46994.jhb>