On Fri, Jan 1, 2016 at 2:19 PM, Tony Luck wrote:
> Somehow this didn't get sent ... found it in the "Drafts" folder. But
> it's rubbish, skip to the
> bottom.
>
> On Thu, Dec 31, 2015 at 12:30 PM, Tony Luck wrote:
>> I switched to BIAS 0xC000 ... and now I should get class 1 entries
>> (bit3
Somehow this didn't get sent ... found it in the "Drafts" folder. But
it's rubbish, skip to the
bottom.
On Thu, Dec 31, 2015 at 12:30 PM, Tony Luck wrote:
> I switched to BIAS 0xC000 ... and now I should get class 1 entries
> (bit31=0, bit30=1).
>
> New patch series coming soon.
Or not :-(
On Jan 1, 2016 4:30 AM, "Tony Luck" wrote:
>
> On Wed, Dec 30, 2015 at 3:32 PM, Tony Luck wrote:
> > Fifth is just a hack because I clearly didn't understand what I was
> > doing in parts 2&3 because my new class shows up as '3' not '1'!
> >
> > Andy: Can you explain the assembler/linker arithmet
On Wed, Dec 30, 2015 at 3:32 PM, Tony Luck wrote:
> Fifth is just a hack because I clearly didn't understand what I was
> doing in parts 2&3 because my new class shows up as '3' not '1'!
>
> Andy: Can you explain the assembler/linker arithmetic for the class?
Never mind ... figured it out.
The f
On Sun, Dec 27, 2015 at 4:18 AM, Andy Lutomirski wrote:
> I think I can save you some pondering. This old patch gives two flag
> bits. Feel free to borrow the patch, but you'll probably want to
> change the _EXTABLE_CLASS_XYZ macros:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.gi
On Sun, Dec 27, 2015 at 5:33 AM, Borislav Petkov wrote:
> On Sun, Dec 27, 2015 at 05:25:45AM -0800, Andy Lutomirski wrote:
>> That could significantly bloat the kernel image.
>
> Yeah, we probably should build an allyesconfig and see how big
> __ex_table is and compute how much actually that bloat
On Sun, Dec 27, 2015 at 5:33 AM, Borislav Petkov wrote:
> On Sun, Dec 27, 2015 at 05:25:45AM -0800, Andy Lutomirski wrote:
>> That could significantly bloat the kernel image.
>
> Yeah, we probably should build an allyesconfig and see how big
> __ex_table is and compute how much actually that bloat
On Sun, Dec 27, 2015 at 05:25:45AM -0800, Andy Lutomirski wrote:
> That could significantly bloat the kernel image.
Yeah, we probably should build an allyesconfig and see how big
__ex_table is and compute how much actually that bloat would be,
because...
> Anyway, the bit 31 game isn't so bad IMO
On Sun, Dec 27, 2015 at 5:17 AM, Boris Petkov wrote:
> Andy Lutomirski wrote:
>>You certainly can, but it doesn't scale well to multiple users of
>>similar mechanisms. It also prevents you from using the same
>>mechanism in anything that could be inlined, which is IMO kind of
>>unfortunate.
>
>
Andy Lutomirski wrote:
>You certainly can, but it doesn't scale well to multiple users of
>similar mechanisms. It also prevents you from using the same
>mechanism in anything that could be inlined, which is IMO kind of
>unfortunate.
Well, but the bit 31 game doesn't make it any better than the b
On Sun, Dec 27, 2015 at 2:09 AM, Borislav Petkov wrote:
> On Sat, Dec 26, 2015 at 10:57:26PM -0800, Tony Luck wrote:
>> ... will get the right value. Maybe this would still work out
>> if the fixup is a 31-bit value plus a flag, but the external
>> tool thinks it is a 32-bit value? I'd have to p
On Sat, Dec 26, 2015 at 10:57 PM, Tony Luck wrote:
> On Sat, Dec 26, 2015 at 6:16 PM, Andy Lutomirski wrote:
We could make one of them 31-bits (since even an "allyesconfig" kernel
is still much smaller than a gigabyte) to free a bit for a flag. But there
are those external tools to
On Sat, Dec 26, 2015 at 10:57:26PM -0800, Tony Luck wrote:
> ... will get the right value. Maybe this would still work out
> if the fixup is a 31-bit value plus a flag, but the external
> tool thinks it is a 32-bit value? I'd have to ponder that.
I still fail to see why do we need to make it so
On Sat, Dec 26, 2015 at 6:16 PM, Andy Lutomirski wrote:
>>> We could make one of them 31-bits (since even an "allyesconfig" kernel
>>> is still much smaller than a gigabyte) to free a bit for a flag. But there
>>> are those external tools to pre-sort exception tables that would all
>>> need to be
On Sat, Dec 26, 2015 at 6:08 PM, Tony Luck wrote:
> On Sat, Dec 26, 2015 at 6:54 AM, Andy Lutomirski wrote:
>> On Dec 26, 2015 6:33 PM, "Borislav Petkov" wrote:
>>> Andy, why is that? It makes the exception handling much simpler this way...
>>>
>>
>> I like the idea of moving more logic into C,
On Sat, Dec 26, 2015 at 6:15 PM, Andy Lutomirski wrote:
> On Sat, Dec 26, 2015 at 6:08 PM, Tony Luck wrote:
>> On Sat, Dec 26, 2015 at 6:54 AM, Andy Lutomirski wrote:
>>> On Dec 26, 2015 6:33 PM, "Borislav Petkov" wrote:
Andy, why is that? It makes the exception handling much simpler this
On Sat, Dec 26, 2015 at 6:54 AM, Andy Lutomirski wrote:
> On Dec 26, 2015 6:33 PM, "Borislav Petkov" wrote:
>> Andy, why is that? It makes the exception handling much simpler this way...
>>
>
> I like the idea of moving more logic into C, but I don't like
> splitting the logic across files and ad
On Dec 26, 2015 6:33 PM, "Borislav Petkov" wrote:
>
> On Fri, Dec 25, 2015 at 08:05:39PM +, Luck, Tony wrote:
> > mce_in_kernel_recov() should check whether we have a fix up entry for
> > the specific IP that hit the machine check before rating the severity
> > as kernel recoverable.
>
> Yeah,
On Fri, Dec 25, 2015 at 08:05:39PM +, Luck, Tony wrote:
> mce_in_kernel_recov() should check whether we have a fix up entry for
> the specific IP that hit the machine check before rating the severity
> as kernel recoverable.
Yeah, it is not precise right now. But this is easy - I'll change it
mce_in_kernel_recov() should check whether we have a fix up entry for the
specific IP that hit the machine check before rating the severity as kernel
recoverable.
If we add more functions (for different cache behaviour, or to optimize for
specific processor model) we can make sure to put them a
On Tue, Dec 15, 2015 at 05:30:49PM -0800, Tony Luck wrote:
> Using __copy_user_nocache() as inspiration create a memory copy
> routine for use by kernel code with annotations to allow for
> recovery from machine checks.
>
> Notes:
> 1) We align the source address rather than the destination. This
Using __copy_user_nocache() as inspiration create a memory copy
routine for use by kernel code with annotations to allow for
recovery from machine checks.
Notes:
1) We align the source address rather than the destination. This
means we never have to deal with a memory read that spans two
cac
22 matches
Mail list logo
