lkml.org 
[lkml]   [2009]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Xen bugfixes

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Hi,
>
> Here's 3 patches which fix two Xen PV spinlock bugs, and makes
> CONFIG_CC_STACKPROTECTOR work on both 32- and 64-bit.
>
> The spinlock bugs are both rare races:
> - lock can briefly hold the lock while interrupts are enabled, allowing an ISR to deadlock
> - unlock doesn't enforce CPU memory ordering between the actual unlock write and the check
> to see if there are any pending waiters, so it can end up deciding there's nobody to
> kick on unlock, leaving another CPU hanging. It needs a full mb() to guarantee the correct
> ordering.
>
> The stack-protector fix bites the bullet and does a full GDT setup
> early so that we can load %gs for the stack-protector canary
> segment on i386. This also removes the assumption that the
> initial percpu %fs segment has a zero base.
>
> x86-64 still just needs the GS_BASE MSR written, but that now
> happens using the same code as i386 rather than being special
> cased.
>
> Thanks,
> J
>
> The following changes since commit e07cccf4046978df10f2e13fe2b99b2f9b3a65db:
> Linus Torvalds (1):
> Linux 2.6.31-rc9
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git bugfix
>
> Jeremy Fitzhardinge (2):
> xen: make -fstack-protector work under Xen
> xen: only enable interrupts while actually blocking for spinlock
>
> Yang Xiaowei (1):
> xen: use stronger barrier after unlocking lock
>
> arch/x86/mm/Makefile | 4 ++
> arch/x86/xen/Makefile | 2 +
> arch/x86/xen/enlighten.c | 131 +++++++++++++++++++++++++++++++++++++++-------
> arch/x86/xen/smp.c | 1 +
> arch/x86/xen/spinlock.c | 28 ++++++----
> drivers/xen/Makefile | 3 +
> 6 files changed, 140 insertions(+), 29 deletions(-)

Pulled, thanks a lot Jeremy!

A few comments:

> +# Make sure __phys_addr has no stackprotector
> +nostackp := $(call cc-option, -fno-stack-protector)
> +CFLAGS_ioremap.o := $(nostackp)
> +

Sure we could move __phys_addr into its own file and thus avoid
turning off stackprotector for the rest of ioremap.c?

> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -8,6 +8,7 @@ endif
> # Make sure early boot has no stackprotector
> nostackp := $(call cc-option, -fno-stack-protector)
> CFLAGS_enlighten.o := $(nostackp)
> +CFLAGS_mmu.o := $(nostackp)

A similar argument could be made here - what proportion of mmu.c is
affected?

Also, once the commits have hit upstream feel free bounce them to
stable@kernel.org - they dont have Cc: <stable@kernel.org> tags for
automatic back-merging requests. The fixes narrowly missed v2.6.31.

Ingo


\
 
 \ /
  Last update: 2009-09-10 07:19    [W:0.802 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site