On 2018-07-24 18:19:15 [+0200], Ard Biesheuvel wrote:
> > Regarding the workqueue in commit 3eb420e70d87 ("efi: Use a work queue
> > to invoke EFI Runtime Services"). The efi_call_virt_pointer() function
> > uses local_save_flags() while invoking the EFI function. Why does commit
> > message say "Since UEFI runtime services are typically invoked with
> > interrupts enabled,"?
> >
>
> Because local_save_flags() does not disable interrupts??
now that you say so, it does make sense…
> > Anyway, I would still like to get rid of task_lock() in efi_switch_mm().
> > Any objections to that?
>
> No, not at all.
okay.
> > If efi_switch_mm() is only invoked from kernel-thread (the mixed-mode
> > caller does not) the then you could use use_mm() / unuse_mm() instead.
> > Then I would be fine with task_lock() (but it would have to be moved to
> > the preemptible section (after efi_sync_low_kernel_mappings()).
>
> There are some exceptions, unfortunately, although I don't think they
> matter to -rt: at early boot time and panic() time, alternative
> wrappers are used that bypass the work queue. The reset_system()
> service also bypasses the work queue but that does not really matter
> given the purpose of the call.
If you lose the task's real mm in panic() then it probably does not
matter since you are never going back to userland.
But the others might be invoked from user context as there are two
non-blocking calls. So no use_mm() then.
reset_system() service should not return but it may if a signal is
pending (still there is a fallback but wouldn't it make sense to drop
that interruptible part)? Also this might be called from
emergency_restart() / panic() right? So down() will open interrupts and
schedule() if the lock is contended.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
