On 04/07/2013 09:34 AM, H. Peter Anvin wrote:
> On 04/07/2013 06:33 AM, Borislav Petkov wrote:
>> looks like we haven't whacked all the moles - I keep seeing this when
>> testing 32-bit builds in qemu on latest Linus + tip. I'd guess this is
>> still that /dev/mem accessing thing called wdm.
>>
>>
On 04/07/2013 09:34 AM, H. Peter Anvin wrote:
On 04/07/2013 06:33 AM, Borislav Petkov wrote:
looks like we haven't whacked all the moles - I keep seeing this when
testing 32-bit builds in qemu on latest Linus + tip. I'd guess this is
still that /dev/mem accessing thing called wdm.
I'm still
On Sun, Apr 07, 2013 at 09:34:07AM -0700, H. Peter Anvin wrote:
> We shouldn't, no. /dev/mem really needs to be fixed along a bunch of
> axes. Yes, it is privileged and extra creepy, but it should either
> work or it should fail cleanly.
Can't we filter out accesses through /dev/mem and not
On 04/07/2013 06:33 AM, Borislav Petkov wrote:
>
> looks like we haven't whacked all the moles - I keep seeing this when
> testing 32-bit builds in qemu on latest Linus + tip. I'd guess this is
> still that /dev/mem accessing thing called wdm.
>
> I'm still wondering though whether we should
Hey Dave,
On Thu, Mar 07, 2013 at 08:31:51AM -0800, Dave Hansen wrote:
>
> The original bug reporter says this fixes it for him, so I'm
> broadening the cc list a bit. I assume this should just get
> sucked in to the x86 tree.
looks like we haven't whacked all the moles - I keep seeing this
Hey Dave,
On Thu, Mar 07, 2013 at 08:31:51AM -0800, Dave Hansen wrote:
The original bug reporter says this fixes it for him, so I'm
broadening the cc list a bit. I assume this should just get
sucked in to the x86 tree.
looks like we haven't whacked all the moles - I keep seeing this when
On 04/07/2013 06:33 AM, Borislav Petkov wrote:
looks like we haven't whacked all the moles - I keep seeing this when
testing 32-bit builds in qemu on latest Linus + tip. I'd guess this is
still that /dev/mem accessing thing called wdm.
I'm still wondering though whether we should BUG_ON on
On Sun, Apr 07, 2013 at 09:34:07AM -0700, H. Peter Anvin wrote:
We shouldn't, no. /dev/mem really needs to be fixed along a bunch of
axes. Yes, it is privileged and extra creepy, but it should either
work or it should fail cleanly.
Can't we filter out accesses through /dev/mem and not BUG_ON
On 03/07/2013 02:05 PM, Tetsuo Handa wrote:
>
> Excuse me, but I didn't realize that the link is wrong.
>
> https://lkml.org/lkml/2013/2/5/396 is a bug in CONFIG_MICROCODE_INTEL_EARLY=y
> && CONFIG_64BIT=n && CONFIG_DEBUG_VIRTUAL=y where patches are not available.
>
>
Dave Hansen wrote:
>
> The original bug reporter says this fixes it for him, so I'm
> broadening the cc list a bit. I assume this should just get
> sucked in to the x86 tree.
>
> The double-signed-off-by from my is because my IBM email is
> going away very shortly.
>
> --
>
>
The original bug reporter says this fixes it for him, so I'm
broadening the cc list a bit. I assume this should just get
sucked in to the x86 tree.
The double-signed-off-by from my is because my IBM email is
going away very shortly.
--
kernel_map_sync_memtype() is called from a variety of
Dave Hansen wrote:
> I have reproduced this bug and this patch fixes it for me
>
> https://lkml.org/lkml/2013/2/5/396
>
> Signed-off-by: Dave Hansen
This patch fixes it for me too.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Dave Hansen wrote:
I have reproduced this bug and this patch fixes it for me
https://lkml.org/lkml/2013/2/5/396
Signed-off-by: Dave Hansen d...@linux.vnet.ibm.com
This patch fixes it for me too.
Thank you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
The original bug reporter says this fixes it for him, so I'm
broadening the cc list a bit. I assume this should just get
sucked in to the x86 tree.
The double-signed-off-by from my is because my IBM email is
going away very shortly.
--
kernel_map_sync_memtype() is called from a variety of
Dave Hansen wrote:
The original bug reporter says this fixes it for him, so I'm
broadening the cc list a bit. I assume this should just get
sucked in to the x86 tree.
The double-signed-off-by from my is because my IBM email is
going away very shortly.
--
kernel_map_sync_memtype()
On 03/07/2013 02:05 PM, Tetsuo Handa wrote:
Excuse me, but I didn't realize that the link is wrong.
https://lkml.org/lkml/2013/2/5/396 is a bug in CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_64BIT=n CONFIG_DEBUG_VIRTUAL=y where patches are not available.
https://lkml.org/lkml/2013/3/5/314 is
kernel_map_sync_memtype() is called from a variety of contexts. The
pat.c code that calls it seems to ensure that it is not called for
non-ram areas by checking via pat_pagerange_is_ram(). It is important
that it only be called on the actual identity map because there *IS*
no map to sync for
kernel_map_sync_memtype() is called from a variety of contexts. The
pat.c code that calls it seems to ensure that it is not called for
non-ram areas by checking via pat_pagerange_is_ram(). It is important
that it only be called on the actual identity map because there *IS*
no map to sync for
18 matches
Mail list logo
