On 24 July 2018 at 18:02, Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> wrote:
> On 2018-07-24 17:32:14 [+0200], Ard Biesheuvel wrote:
>> Please refer to what has been queued up in tip:efi/core. Sai has
>> implemented a work queue for EFI calls so they occur from a kernel
>> thread, and the mixed mode locking has been fixed as well.
>
> I see commit 83a0a2ea0b99 ("efi/x86: Prevent reentrant firmware calls in
> mixed mode") which fixes the locking issue I mentioned. Will this make
> its way to the current kernel?
>
The next one, yes. If you mean 'backported to -stable', I haven't
really though about that yet, although it probable makes sense to do
so.
> 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??
> Anyway, I would still like to get rid of task_lock() in efi_switch_mm().
> Any objections to that?
No, not at all.
> 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.
--
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
