Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1268237

Re: [PATCH 2/3] x86, ras: Extend machine check recovery code to annotated ring0 areas

Show all headers | View raw

On Wed, Nov 11, 2015 at 08:19:35PM -0800, Andy Lutomirski wrote:
> >@@ -1132,9 +1133,15 @@ void do_machine_check(struct pt_regs *regs, long error_code)
> >  		if (no_way_out)
> >  			mce_panic("Fatal machine check on current CPU", &m, msg);
> >  		if (worst == MCE_AR_SEVERITY) {
> >-			recover_paddr = m.addr;
> >-			if (!(m.mcgstatus & MCG_STATUS_RIPV))
> >-				flags |= MF_MUST_KILL;
> >+			if ((m.cs & 3) == 3) {
> >+				recover_paddr = m.addr;
> >+				if (!(m.mcgstatus & MCG_STATUS_RIPV))
> >+					flags |= MF_MUST_KILL;
> >+			} else if (fixup_mcexception(regs)) {
> >+				regs->ax = BIT(63) | m.addr;
> >+			} else
> >+				mce_panic("Failed kernel mode recovery",
> >+					  &m, NULL);
> 
> Maybe I'm misunderstanding this, but presumably you shouldn't call
> fixup_mcexception unless you've first verified RIPV (i.e. that the ip you're
> looking up in the table is valid).

Good point. We can only arrive here with a AR_SEVERITY from some
kernel code if the code in mce_severity.c assigned that severity.
But it doesn't currently look at RIPV ... I should make it do that.
Actually I'll check for both RIPV and EIPV: we don't need to look for
a fixup entry for all the innocent bystander cpus that got dragged
into the exception handler because the exception was broadcast to
everyone.

> Also... I find the general flow of this code very hard to follow.  It's
> critical that an MCE hitting kernel mode not get as far as
> ist_begin_non_atomic.  It was already hard enough to tell that the code
> follows that rule, and now it's even harder.  Would it make sense to add
> clear assertions that m.cs == regs->cs and that user_mode(regs) when you get
> to the end?  Simplifying the control flow might also be nice.

Yes. This is a mess now. It works (because we only set recover_paddr
in the user mode case ... so we'll take the "goto done" for the kernel
case). But I agree that this is far from obvious.

> >  		} else if (kill_it) {
> >  			force_sig(SIGBUS, current);
> >  		}
> >
> 
> I would argue that this should happen in the non-atomic section.  It's
> probably okay as long as we came from user mode, but it's more obviously
> safe in the non-atomic section.

Will look at relocating this too when I restructure the tail of the
function.

Thanks for the review.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH 0/3] Machine check recovery when kernel accesses poison Tony Luck <tony.luck@intel.com> - 2015-11-09 19:50 +0100
  [PATCH 2/3] x86, ras: Extend machine check recovery code to annotated  ring0 areas Tony Luck <tony.luck@intel.com> - 2015-11-09 19:50 +0100
    Re: [PATCH 2/3] x86, ras: Extend machine check recovery code to  annotated ring0 areas Borislav Petkov <bp@alien8.de> - 2015-11-10 12:30 +0100
      Re: [PATCH 2/3] x86, ras: Extend machine check recovery code to  annotated ring0 areas "Luck, Tony" <tony.luck@intel.com> - 2015-11-10 23:20 +0100
        Re: [PATCH 2/3] x86, ras: Extend machine check recovery code to  annotated ring0 areas Borislav Petkov <bp@alien8.de> - 2015-11-11 12:10 +0100
    Re: [PATCH 2/3] x86, ras: Extend machine check recovery code to  annotated ring0 areas Andy Lutomirski <luto@kernel.org> - 2015-11-12 05:30 +0100
      Re: [PATCH 2/3] x86, ras: Extend machine check recovery code to  annotated ring0 areas "Luck, Tony" <tony.luck@intel.com> - 2015-11-12 21:00 +0100
  [PATCH 3/3] x86, ras: Add mcsafe_memcpy() function to recover from  machine checks Tony Luck <tony.luck@intel.com> - 2015-11-09 19:50 +0100
    Re: [PATCH 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks Ingo Molnar <mingo@kernel.org> - 2015-11-12 09:00 +0100
      Re: [PATCH 3/3] x86, ras: Add mcsafe_memcpy() function to recover  from machine checks "Luck, Tony" <tony.luck@intel.com> - 2015-11-12 21:10 +0100
  Re: [RFC PATCH 0/3] Machine check recovery when kernel accesses  poison Borislav Petkov <bp@alien8.de> - 2015-11-10 12:30 +0100
    Re: [RFC PATCH 0/3] Machine check recovery when kernel accesses  poison "Luck, Tony" <tony.luck@intel.com> - 2015-11-10 23:00 +0100
      Re: [RFC PATCH 0/3] Machine check recovery when kernel accesses  poison Borislav Petkov <bp@alien8.de> - 2015-11-11 21:50 +0100
        Re: [RFC PATCH 0/3] Machine check recovery when kernel accesses  poison "Luck, Tony" <tony.luck@intel.com> - 2015-11-11 22:50 +0100
          Re: [RFC PATCH 0/3] Machine check recovery when kernel accesses  poison Borislav Petkov <bp@alien8.de> - 2015-11-11 23:30 +0100
            RE: [RFC PATCH 0/3] Machine check recovery when kernel accesses  poison "Luck, Tony" <tony.luck@intel.com> - 2015-11-11 23:40 +0100

csiph-web