This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for Intel X1000
- From: "Kinsella, Ray" <ray dot kinsella at intel dot com>
- To: "dalias at libc dot org" <dalias at libc dot org>
- Cc: "carlos at redhat dot com" <carlos at redhat dot com>, "fweimer at redhat dot com" <fweimer at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 20 May 2015 13:54:13 +0000
- Subject: Re: Support for Intel X1000
- Authentication-results: sourceware.org; auth=none
- References: <1431426490 dot 3246 dot 29 dot camel at intel dot com> <5552104C dot 1020806 at redhat dot com> <20150512152207 dot GW17573 at brightrain dot aerifal dot cx> <1431513937 dot 2622 dot 24 dot camel at intel dot com> <20150513170809 dot GY17573 at brightrain dot aerifal dot cx> <555397D0 dot 70808 at redhat dot com> <20150515012433 dot GC17573 at brightrain dot aerifal dot cx>
> I did a little bit of research and it appears that only lock-prefixed
> instructions which can page fault are affected by this bug. So why not
> just make the kernel enforce mlockall for all processes on affected
> cpus?
mlockall doesn't help in situations where a page is marked as CoW, you
still get the page fault on write (i.e. lock cmpxchg -
read/modify/write).
I am seeing this in two places :-
1. when the data section of an elf binary is loaded.
2. memory shared between a child and a parent process after a fork.
1. seems to be causing the issue, can't see a away to work around this.
> I'm not clear on whether the bug crashes the whole system or
> just clobbers the user process state in an unrecoverable way, but if
> it's the latter, only writable pages would need to be locked;
> read-only pages could still be paged normally.
It clobbers the process the process state in an unrecoverable way. The
problem doesn't affect the Kernel, as the Kernel doesn't page fault.