On Mon, Apr 08, 2013 at 03:53:31PM +0100, Andy Whitcroft wrote:
> On Sat, Apr 06, 2013 at 04:58:04PM +0200, Andrea Arcangeli wrote:
>
> > You're right, so this location clearly didn't trigger the problem so I
> > didn't notice the noop here. I only exercised the fix in the other
> > locations of
On Sat, Apr 06, 2013 at 04:58:04PM +0200, Andrea Arcangeli wrote:
> You're right, so this location clearly didn't trigger the problem so I
> didn't notice the noop here. I only exercised the fix in the other
> locations of the file that had the same problem.
>
> It was a noop, so it really
On 08.04.2013 16:15, Borislav Petkov wrote:
> On Mon, Apr 08, 2013 at 03:10:00PM +0200, Stefan Bader wrote:
>> * that we limited the number of possible pages already to
>> * the number of pages in the large page.
>> */
>> if (address == (address & pmask) &&
On Mon, Apr 08, 2013 at 03:10:00PM +0200, Stefan Bader wrote:
> * that we limited the number of possible pages already to
> * the number of pages in the large page.
> */
> if (address == (address & pmask) && cpa->numpages == (psize >>
> PAGE_SHIFT)) {
>
On 08.04.2013 14:51, Borislav Petkov wrote:
> On Mon, Apr 08, 2013 at 02:28:47PM +0200, Stefan Bader wrote:
>> To enforce the PSE bit here sounds reasonably right. And also apply
>> canon_pgprot, too. GLOBAL I don't know for sure.
>
> Well sure, you don't want to flush those from the TLB if it is
On Mon, Apr 08, 2013 at 02:28:47PM +0200, Stefan Bader wrote:
> To enforce the PSE bit here sounds reasonably right. And also apply
> canon_pgprot, too. GLOBAL I don't know for sure.
Well sure, you don't want to flush those from the TLB if it is kernel
memory since it is mapped in every process
On 08.04.2013 13:59, Borislav Petkov wrote:
> On Mon, Apr 08, 2013 at 01:53:44PM +0200, Ingo Molnar wrote:
>>
>> * Borislav Petkov wrote:
>>
have been the source of the confusion. Remove the noop initialization
accordingly.
Signed-off-by: Andrea Arcangeli
>>>
>>> Yeah, looks
On Mon, Apr 08, 2013 at 01:53:44PM +0200, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > > have been the source of the confusion. Remove the noop initialization
> > > accordingly.
> > >
> > > Signed-off-by: Andrea Arcangeli
> >
> > Yeah, looks good to me. I've folded it into my pile
* Borislav Petkov wrote:
> > have been the source of the confusion. Remove the noop initialization
> > accordingly.
> >
> > Signed-off-by: Andrea Arcangeli
>
> Yeah, looks good to me. I've folded it into my pile of changes touching this
> and
> there are no visible issues. [...]
Logistics
* Borislav Petkov b...@alien8.de wrote:
have been the source of the confusion. Remove the noop initialization
accordingly.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
Yeah, looks good to me. I've folded it into my pile of changes touching this
and
there are no visible
On Mon, Apr 08, 2013 at 01:53:44PM +0200, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de wrote:
have been the source of the confusion. Remove the noop initialization
accordingly.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
Yeah, looks good to me. I've folded it
On 08.04.2013 13:59, Borislav Petkov wrote:
On Mon, Apr 08, 2013 at 01:53:44PM +0200, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de wrote:
have been the source of the confusion. Remove the noop initialization
accordingly.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
Yeah,
On Mon, Apr 08, 2013 at 02:28:47PM +0200, Stefan Bader wrote:
To enforce the PSE bit here sounds reasonably right. And also apply
canon_pgprot, too. GLOBAL I don't know for sure.
Well sure, you don't want to flush those from the TLB if it is kernel
memory since it is mapped in every process
On 08.04.2013 14:51, Borislav Petkov wrote:
On Mon, Apr 08, 2013 at 02:28:47PM +0200, Stefan Bader wrote:
To enforce the PSE bit here sounds reasonably right. And also apply
canon_pgprot, too. GLOBAL I don't know for sure.
Well sure, you don't want to flush those from the TLB if it is kernel
On Mon, Apr 08, 2013 at 03:10:00PM +0200, Stefan Bader wrote:
* that we limited the number of possible pages already to
* the number of pages in the large page.
*/
if (address == (address pmask) cpa-numpages == (psize
PAGE_SHIFT)) {
/*
On 08.04.2013 16:15, Borislav Petkov wrote:
On Mon, Apr 08, 2013 at 03:10:00PM +0200, Stefan Bader wrote:
* that we limited the number of possible pages already to
* the number of pages in the large page.
*/
if (address == (address pmask) cpa-numpages ==
On Sat, Apr 06, 2013 at 04:58:04PM +0200, Andrea Arcangeli wrote:
You're right, so this location clearly didn't trigger the problem so I
didn't notice the noop here. I only exercised the fix in the other
locations of the file that had the same problem.
It was a noop, so it really couldn't
On Mon, Apr 08, 2013 at 03:53:31PM +0100, Andy Whitcroft wrote:
On Sat, Apr 06, 2013 at 04:58:04PM +0200, Andrea Arcangeli wrote:
You're right, so this location clearly didn't trigger the problem so I
didn't notice the noop here. I only exercised the fix in the other
locations of the file
On Sat, Apr 06, 2013 at 04:58:04PM +0200, Andrea Arcangeli wrote:
> You're right, so this location clearly didn't trigger the problem so I
> didn't notice the noop here. I only exercised the fix in the other
> locations of the file that had the same problem.
>
> It was a noop, so it really
Hi everyone,
On Fri, Apr 05, 2013 at 04:21:04PM +0200, Borislav Petkov wrote:
> On Fri, Apr 05, 2013 at 11:01:02AM +0200, Stefan Bader wrote:
> > When looking through some mm code I stumbled over one part in
> > arch/x86/mm/pageattr.c that looks somewhat bogus to me. Cannot
> > say what exactly
Hi everyone,
On Fri, Apr 05, 2013 at 04:21:04PM +0200, Borislav Petkov wrote:
On Fri, Apr 05, 2013 at 11:01:02AM +0200, Stefan Bader wrote:
When looking through some mm code I stumbled over one part in
arch/x86/mm/pageattr.c that looks somewhat bogus to me. Cannot
say what exactly the
On Sat, Apr 06, 2013 at 04:58:04PM +0200, Andrea Arcangeli wrote:
You're right, so this location clearly didn't trigger the problem so I
didn't notice the noop here. I only exercised the fix in the other
locations of the file that had the same problem.
It was a noop, so it really couldn't
On Fri, Apr 05, 2013 at 11:01:02AM +0200, Stefan Bader wrote:
> When looking through some mm code I stumbled over one part in
> arch/x86/mm/pageattr.c that looks somewhat bogus to me. Cannot
> say what exactly the effects are, but maybe you do (or you could
> explain to me why I am wrong :)).
>
>
When looking through some mm code I stumbled over one part in
arch/x86/mm/pageattr.c that looks somewhat bogus to me. Cannot
say what exactly the effects are, but maybe you do (or you could
explain to me why I am wrong :)).
commit a8aed3e0752b4beb2e37cbed6df69faae88268da
Author: Andrea Arcangeli
When looking through some mm code I stumbled over one part in
arch/x86/mm/pageattr.c that looks somewhat bogus to me. Cannot
say what exactly the effects are, but maybe you do (or you could
explain to me why I am wrong :)).
commit a8aed3e0752b4beb2e37cbed6df69faae88268da
Author: Andrea Arcangeli
On Fri, Apr 05, 2013 at 11:01:02AM +0200, Stefan Bader wrote:
When looking through some mm code I stumbled over one part in
arch/x86/mm/pageattr.c that looks somewhat bogus to me. Cannot
say what exactly the effects are, but maybe you do (or you could
explain to me why I am wrong :)).
26 matches
Mail list logo
