All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fenghua Yu <fenghua.yu@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	Ravi V Shankar <ravi.v.shankar@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	Rafael Wysocki <rafael.j.wysocki@intel.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Alan Cox <alan@linux.intel.com>, x86 <x86@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 03/15] x86/split_lock: Handle #AC exception for split lock in kernel mode
Date: Wed, 16 May 2018 14:35:31 -0700	[thread overview]
Message-ID: <20180516213529.GA46255@romley-ivt3.sc.intel.com> (raw)
In-Reply-To: <9a64587d-7b04-7445-9434-4e39ff66ceb9@intel.com>

On Wed, May 16, 2018 at 09:44:59AM -0700, Dave Hansen wrote:
> On 05/15/2018 10:21 AM, Fenghua Yu wrote:
> > On Tue, May 15, 2018 at 08:51:24AM -0700, Dave Hansen wrote:
> >> On 05/14/2018 11:52 AM, Fenghua Yu wrote:
> >>> +#define	delay_ms	1
> >>
> >> That seems like a dangerously-generic name that should not be a #define
> >> anyway.
> > 
> > Sure. I will change it to
> > #define split_lock_delay_ms	1
> 
> Why not:
> 
> static unsigned int reenable_split_lock_delay_ms = 1;
> 
> ?
Sure.

> 
> >>> +/* Will the faulting instruction be re-executed? */
> >>> +static bool re_execute(struct pt_regs *regs)
> >>> +{
> >>> +	/*
> >>> +	 * The only reason for generating #AC from kernel is because of
> >>> +	 * split lock. The kernel faulting instruction will be re-executed.
> >>> +	 */
> >>> +	if (!user_mode(regs))
> >>> +		return true;
> >>> +
> >>> +	return false;
> >>> +}
> >>
> >> This helper with a single user is a bit unnecessary.  Just open-code
> >> this and move the comments into the caller.
> > 
> > In this patch, this helper is only used for checking kernel mode.
> > Then in patch #11, this helper will add checking user mode code.
> > It would be better to have a helper defined and called.
> 
> Then introduce the helper later, or call this out in a comment or the
> patch description, please.

Ok. I will call this out in the patch description.

> 
> >>> +/*
> >>> + * #AC handler for kernel split lock is called by generic #AC handler.
> >>> + *
> >>> + * Disable #AC for split lock on this CPU so that the faulting instruction
> >>> + * gets executed. The #AC for split lock is re-enabled later.
> >>> + */
> >>> +bool do_split_lock_exception(struct pt_regs *regs, unsigned long error_code)
> >>> +{
> >>> +	unsigned long delay = msecs_to_jiffies(delay_ms);
> >>> +	unsigned long address = read_cr2(); /* Get the faulting address */
> >>> +	int this_cpu = smp_processor_id();
> >>
> >> How does this end up working?  This seems to depend on this handler not
> >> getting preempted.
> > 
> > Maybe change the handler to:
> > 
> > this_cpu = task_cpu(current);
> > Then disable split lock on this_cpu.
> > Re-enable split lock on this_cpu (already in this way).
> > 
> > Does this sound better?
> 
> Actually, as I look at it, interrupts *are* still disabled here, so you
> are OK.  But, you can do a local_irq_enable() once you get all of the
> per-cpu state settled and go to start handling the fault if you are
> going to do anything that takes an appreciable amount of time.

Ok.

> 
> >>> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> >>> index 03f3d7695dac..c07b817bbbe9 100644
> >>> --- a/arch/x86/kernel/traps.c
> >>> +++ b/arch/x86/kernel/traps.c
> >>> @@ -61,6 +61,7 @@
> >>>  #include <asm/mpx.h>
> >>>  #include <asm/vm86.h>
> >>>  #include <asm/umip.h>
> >>> +#include <asm/cpu.h>
> >>>  
> >>>  #ifdef CONFIG_X86_64
> >>>  #include <asm/x86_init.h>
> >>> @@ -286,10 +287,21 @@ static void do_error_trap(struct pt_regs *regs, long error_code, char *str,
> >>>  			  unsigned long trapnr, int signr)
> >>>  {
> >>>  	siginfo_t info;
> >>> +	int ret;
> >>>  
> >>>  	RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> >>>  
> >>>  	/*
> >>> +	 * #AC exception could be handled by split lock handler.
> >>> +	 * If the handler can't handle the exception, go to generic #AC handler.
> >>> +	 */
> >>> +	if (trapnr == X86_TRAP_AC) {
> >>> +		ret = do_split_lock_exception(regs, error_code);
> >>> +		if (ret)
> >>> +			return;
> >>> +	}
> >>
> >> Why are you hooking into do_error_trap()?  Shouldn't you just be
> >> installing do_split_lock_exception() as *the* #AC handler and put it in
> >> the IDT?
> > 
> > Split lock is not the only reason that causes #AC. #AC can be caused
> > by user turning on AC bit in EFLAGS, which is just cache line misalignment
> > and is different from split lock.
> > 
> > So split lock is sharing the handler with another #AC case and can't
> > be installed seperately from previous #AC handler, right?
> 
> There are lots of exceptions that use do_error_trap().  I'm suggesting
> that you make an IDT entry for X86_TRAP_AC that does not use
> do_error_trap() since you need something different in there now.
> 
> See:
> 
> > #define DO_ERROR(trapnr, signr, str, name)                              \
> > dotraplinkage void do_##name(struct pt_regs *regs, long error_code)     \
> > {                                                                       \
> >         do_error_trap(regs, error_code, str, trapnr, signr);            \
> > }
> > 
> > DO_ERROR(X86_TRAP_DE,     SIGFPE,  "divide error",              divide_error)
> > DO_ERROR(X86_TRAP_OF,     SIGSEGV, "overflow",                  overflow)
> > DO_ERROR(X86_TRAP_UD,     SIGILL,  "invalid opcode",            invalid_op)
> > DO_ERROR(X86_TRAP_OLD_MF, SIGFPE,  "coprocessor segment overrun",coprocessor_segment_overrun)
> > DO_ERROR(X86_TRAP_TS,     SIGSEGV, "invalid TSS",               invalid_TSS)
> > DO_ERROR(X86_TRAP_NP,     SIGBUS,  "segment not present",       segment_not_present)
> > DO_ERROR(X86_TRAP_SS,     SIGBUS,  "stack segment",             stack_segment)
> > DO_ERROR(X86_TRAP_AC,     SIGBUS,  "alignment check",           alignment_check)
> 
> Look at do_general_protection(), for instance.

Sure. I will define the #AC separately.

Thanks.

-Fenghua

  reply	other threads:[~2018-05-16 21:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14 18:52 [PATCH 0/15] x86/split_lock: Enable #AC exception for split locked accesses Fenghua Yu
2018-05-14 18:52 ` [PATCH 01/15] x86/split_lock: Add CONFIG and enumerate #AC exception for split locked access feature Fenghua Yu
2018-05-15 15:36   ` Dave Hansen
2018-05-15 15:41     ` Fenghua Yu
2018-05-15 15:54       ` Dave Hansen
2018-05-14 18:52 ` [PATCH 02/15] x86/split_lock: Set up #AC exception for split locked accesses Fenghua Yu
2018-05-14 18:52 ` [PATCH 03/15] x86/split_lock: Handle #AC exception for split lock in kernel mode Fenghua Yu
2018-05-15 15:51   ` Dave Hansen
2018-05-15 16:35     ` Luck, Tony
2018-05-15 17:21     ` Fenghua Yu
2018-05-16 16:44       ` Dave Hansen
2018-05-16 21:35         ` Fenghua Yu [this message]
2018-05-14 18:52 ` [PATCH 04/15] x86/split_lock: Use non locked bit set instruction in set_cpu_cap Fenghua Yu
2018-05-14 18:52 ` [PATCH 05/15] x86/split_lock: Use non atomic set and clear bit instructions to clear cpufeature Fenghua Yu
2018-05-14 18:52 ` [PATCH 06/15] x86/split_lock: Save #AC setting for split lock in BIOS in boot time and restore the setting in reboot Fenghua Yu
2018-05-14 18:52 ` [PATCH 07/15] x86/split_lock: Handle suspend/hibernate and resume Fenghua Yu
2018-05-14 21:42   ` Rafael J. Wysocki
2018-05-14 18:52 ` [PATCH 08/15] x86/split_lock: Set split lock during EFI runtime service Fenghua Yu
2018-05-14 18:52 ` [PATCH 09/15] x86/split_lock: Explicitly enable or disable #AC for split locked accesses Fenghua Yu
2018-05-15 16:15   ` Dave Hansen
2018-05-15 17:29     ` Fenghua Yu
2018-05-16 16:37       ` Dave Hansen
2018-05-14 18:52 ` [PATCH 10/15] x86/split_lock: Add a sysfs interface to allow user to enable or disable split lock during run time Fenghua Yu
2018-05-14 18:52 ` [PATCH 11/15] x86/split_lock: Add sysfs interface to control user mode behavior Fenghua Yu
2018-05-14 18:52 ` [PATCH 12/15] x86/split_lock: Add sysfs interface to show and control BIOS split lock setting Fenghua Yu
2018-05-14 18:52 ` [PATCH 13/15] x86/split_lock: Trace #AC exception for split lock Fenghua Yu
2018-05-14 18:52 ` [PATCH 14/15] x86/split_lock: Add CONFIG and testing sysfs interface Fenghua Yu
2018-05-14 18:52 ` [PATCH 15/15] x86/split_lock: Add split lock user space test in selftest Fenghua Yu
2018-05-15 15:10 ` [PATCH 0/15] x86/split_lock: Enable #AC exception for split locked accesses Dave Hansen
2018-05-15 16:26   ` Alan Cox
2018-05-15 16:30     ` Dave Hansen

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=20180516213529.GA46255@romley-ivt3.sc.intel.com \
    --to=fenghua.yu@intel.com \
    --cc=alan@linux.intel.com \
    --cc=arjan@infradead.org \
    --cc=ashok.raj@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rafael.j.wysocki@intel.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.