search for: lockdep_assert_irqs_disabled

On Tue, Jul 14, 2020 at 02:09:05PM +0200, Joerg Roedel wrote: > @@ -1028,6 +1036,16 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication) > struct ghcb *ghcb; > > lockdep_assert_irqs_disabled(); > + > + /* > + * #DB is special and needs to be handled outside of the intrumentation_begin()/end(). > + * Otherwise the #VC handler could be raised recursivly. > + */ > + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { > + vc_handle_trap_db(regs); > + return;...

On Tue, Jul 14, 2020 at 02:09:05PM +0200, Joerg Roedel wrote: > @@ -1028,6 +1036,16 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication) > struct ghcb *ghcb; > > lockdep_assert_irqs_disabled(); > + > + /* > + * #DB is special and needs to be handled outside of the intrumentation_begin()/end(). > + * Otherwise the #VC handler could be raised recursivly. > + */ > + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { > + vc_handle_trap_db(regs); > + return;...

...ser_mode(regs)) + noist_exc_debug(regs); + else + exc_debug(regs); +} + static enum es_result vc_handle_exitcode(struct es_em_ctxt *ctxt, struct ghcb *ghcb, unsigned long exit_code) @@ -1028,6 +1036,16 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication) struct ghcb *ghcb; lockdep_assert_irqs_disabled(); + + /* + * #DB is special and needs to be handled outside of the intrumentation_begin()/end(). + * Otherwise the #VC handler could be raised recursivly. + */ + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { + vc_handle_trap_db(regs); + return; + } + instrumentation_begin(); /*...

On Wed, Jul 15, 2020 at 10:47:52AM +0200, Peter Zijlstra wrote: > On Tue, Jul 14, 2020 at 02:09:05PM +0200, Joerg Roedel wrote: > > > @@ -1028,6 +1036,16 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication) > > struct ghcb *ghcb; > > > > lockdep_assert_irqs_disabled(); > > + > > + /* > > + * #DB is special and needs to be handled outside of the intrumentation_begin()/end(). > > + * Otherwise the #VC handler could be raised recursivly. > > + */ > > + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { > > + vc_han...

...ser_mode(regs)) + noist_exc_debug(regs); + else + exc_debug(regs); +} + static enum es_result vc_handle_exitcode(struct es_em_ctxt *ctxt, struct ghcb *ghcb, unsigned long exit_code) @@ -1033,6 +1041,15 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication) struct ghcb *ghcb; lockdep_assert_irqs_disabled(); + + /* + * Handle #DB before calling into !noinstr code to avoid recursive #DB. + */ + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { + vc_handle_trap_db(regs); + return; + } + instrumentation_begin(); /* -- 2.28.0

...Jul 15, 2020 at 10:47:52AM +0200, Peter Zijlstra wrote: > > On Tue, Jul 14, 2020 at 02:09:05PM +0200, Joerg Roedel wrote: > > > > > @@ -1028,6 +1036,16 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication) > > > struct ghcb *ghcb; > > > > > > lockdep_assert_irqs_disabled(); > > > + > > > + /* > > > + * #DB is special and needs to be handled outside of the intrumentation_begin()/end(). > > > + * Otherwise the #VC handler could be raised recursivly. > > > + */ > > > + if (error_code == SVM_EXIT_EXCP_BASE + X86_...

...Jul 15, 2020 at 10:47:52AM +0200, Peter Zijlstra wrote: > > On Tue, Jul 14, 2020 at 02:09:05PM +0200, Joerg Roedel wrote: > > > > > @@ -1028,6 +1036,16 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication) > > > struct ghcb *ghcb; > > > > > > lockdep_assert_irqs_disabled(); > > > + > > > + /* > > > + * #DB is special and needs to be handled outside of the intrumentation_begin()/end(). > > > + * Otherwise the #VC handler could be raised recursivly. > > > + */ > > > + if (error_code == SVM_EXIT_EXCP_BASE + X86_...

...signed long flags2; > + lockdep_assert_irqs_enabled(); /* Pass - expectedly blind. */ Indeed, we didn't trace the above disable, so software state is still on. > + local_irq_save(flags2); So here we save IRQ state, and unconditionally disable IRQs and trace them disabled. > + lockdep_assert_irqs_disabled(); /* Pass. */ > + local_irq_restore(flags2); But here, we restore IRQ state to 'disabled' and explicitly trace it disabled *again* (which is a bit daft, but whatever). > + } > + raw_local_irq_restore(flags1); This then restores the IRQ state to enable, but no tracing. >...

...mmon.h> +#include <linux/highmem.h> #include <linux/livepatch.h> #include <linux/audit.h> @@ -194,6 +195,7 @@ static void exit_to_user_mode_prepare(st /* Ensure that the address limit is intact and no locks are held */ addr_limit_user_check(); + kmap_assert_nomap(); lockdep_assert_irqs_disabled(); lockdep_sys_exit(); } --- a/kernel/fork.c +++ b/kernel/fork.c @@ -930,6 +930,7 @@ static struct task_struct *dup_task_stru account_kernel_stack(tsk, 1); kcov_task_init(tsk); + kmap_local_fork(tsk); #ifdef CONFIG_FAULT_INJECTION tsk->fail_nth = 0; --- a/kernel/sched/core.c +++ b/...

...inue\n"); + BUG(); + } +} + +dotraplinkage void do_vmm_communication(struct pt_regs *regs, + unsigned long exit_code) +{ + struct sev_es_runtime_data *data = this_cpu_read(runtime_data); + struct ghcb_state state; + struct es_em_ctxt ctxt; + enum es_result result; + struct ghcb *ghcb; + + lockdep_assert_irqs_disabled(); + + /* + * This is invoked through an interrupt gate, so IRQs are disabled. The + * code below might walk page-tables for user or kernel addresses, so + * keep the IRQs disabled to protect us against concurrent TLB flushes. + */ + + ghcb = sev_es_get_ghcb(&state); + if (!ghcb) { + /* +...

On Tue, Aug 11, 2020 at 11:20:54AM +0200, peterz at infradead.org wrote: > On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > > In case you don't want to do it I can send the patch for the Xen > > variants. > > I might've opened a whole new can of worms here. I'm not sure we > can/want to fix the entire fallout this release :/ > > Let me

On Tue, Aug 11, 2020 at 11:20:54AM +0200, peterz at infradead.org wrote: > On Tue, Aug 11, 2020 at 10:38:50AM +0200, J?rgen Gro? wrote: > > In case you don't want to do it I can send the patch for the Xen > > variants. > > I might've opened a whole new can of worms here. I'm not sure we > can/want to fix the entire fallout this release :/ > > Let me

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

From: Joerg Roedel <jroedel at suse.de> Hi, here is the fourth version of the SEV-ES Guest Support patches. I addressed the review comments sent to me for the previous version and rebased the code v5.8-rc5. The biggest change in this version is the IST handling code for the #VC handler. I adapted the entry code for the #VC handler to the big pile of entry code changes merged into

From: Joerg Roedel <jroedel at suse.de> Hi, here is the fourth version of the SEV-ES Guest Support patches. I addressed the review comments sent to me for the previous version and rebased the code v5.8-rc5. The biggest change in this version is the IST handling code for the #VC handler. I adapted the entry code for the #VC handler to the big pile of entry code changes merged into

From: Joerg Roedel <jroedel at suse.de> Hi, here is a rebased version of the latest SEV-ES patches. They are now based on latest tip/master instead of upstream Linux and include the necessary changes. Changes to v4 are in particular: - Moved early IDT setup code to idt.c, because the idt_descr and the idt_table are now static - This required to make stack protector work early (or