linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Luck <tony.luck@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>,
	linux-nvdimm <linux-nvdimm@ml01.01.org>, X86 ML <x86@kernel.org>,
	"elliott@hpe.com" <elliott@hpe.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks
Date: Sat, 26 Dec 2015 18:08:24 -0800	[thread overview]
Message-ID: <CA+8MBbL9M9GD6NEPChO7_g_HrKZcdrne0LYXdQu18t3RqNGMfQ@mail.gmail.com> (raw)
In-Reply-To: <CALCETrUWmT7jwMvcS+NgaRKc7wpoZ5f_dGT8no7dOWFAGvKtmQ@mail.gmail.com>

On Sat, Dec 26, 2015 at 6:54 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Dec 26, 2015 6:33 PM, "Borislav Petkov" <bp@alien8.de> 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 adding nasty special cases like
> this.
>
> But what if we generalized it?  An extable entry gives a fault IP and
> a landing pad IP.  Surely we can squeeze a flag bit in there.

The clever squeezers have already been here. Instead of a pair
of 64-bit values for fault_ip and fixup_ip they managed with a pair
of 32-bit values that are each the relative offset of the desired address
from the table location itself.

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 fixed too.

Or we could direct the new fixups into a .fixup2 ELF section and put
begin/end labels around that ... so we could check the address of the
fixup to see whether it is a legacy or new format entry.

> set the bit, you get an extended extable entry.  Instead of storing a
> landing pad, it stores a pointer to a handler descriptor:
>
> struct extable_handler {
>   bool (*handler)(struct pt_regs *, struct extable_handler *, ...):
> };
>
> handler returns true if it handled the error and false if it didn't.

It may be had to call that from the machine check handler ... the
beauty of just patching the IP and returning from the handler was
that it got us out of machine check context.

> The "..." encodes the fault number, error code, cr2, etc.  Maybe it
> would be "unsigned long exception, const struct extable_info *info"
> where extable_info contains a union?  I really wish C would grow up
> and learn about union types.

All this is made more difficult because the h/w doesn't give us
all the things we might want to know (e.g. the virtual address).
We just have a physical address (which may be missing some
low order bits).

-Tony

  reply	other threads:[~2015-12-27  2:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-24 20:54 [PATCHV4 0/3] Machine check recovery when kernel accesses poison Tony Luck
2015-12-16  1:29 ` [PATCHV4 1/3] x86, ras: Add new infrastructure for machine check fixup tables Tony Luck
2015-12-16  1:29 ` [PATCHV4 2/3] x86, ras: Extend machine check recovery code to annotated ring0 areas Tony Luck
2015-12-16  1:30 ` [PATCHV4 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks Tony Luck
2015-12-24 21:46   ` Borislav Petkov
2015-12-16  1:30     ` [PATCHV5 " Tony Luck
2015-12-25 11:49       ` Borislav Petkov
2015-12-25 20:05         ` Luck, Tony
2015-12-26 10:32           ` Borislav Petkov
2015-12-26 14:54             ` Andy Lutomirski
2015-12-27  2:08               ` Tony Luck [this message]
2015-12-27  2:15                 ` Andy Lutomirski
2015-12-27  2:16                   ` Andy Lutomirski
2015-12-27  6:57                     ` Tony Luck
2015-12-27 10:09                       ` Borislav Petkov
2015-12-27 12:19                         ` Andy Lutomirski
2015-12-27 13:17                           ` Boris Petkov
2015-12-27 13:25                             ` Andy Lutomirski
2015-12-27 13:33                               ` Borislav Petkov
2015-12-27 13:40                                 ` Andy Lutomirski
2015-12-27 19:04                                 ` Dan Williams
2015-12-27 12:18                       ` Andy Lutomirski
2015-12-30 23:32                         ` Tony Luck
2015-12-31 20:30                           ` Tony Luck
2015-12-31 21:22                             ` Andy Lutomirski
2016-01-01 22:19                             ` Tony Luck
2016-01-03  3:40                               ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+8MBbL9M9GD6NEPChO7_g_HrKZcdrne0LYXdQu18t3RqNGMfQ@mail.gmail.com \
    --to=tony.luck@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=elliott@hpe.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).