lkml.org 
[lkml]   [2018]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH V2 3/3] efi: Use efi_rts_workqueue to invoke EFI Runtime Services
    Date
    05, 2018 at 03:23:10PM -0800, Sai Praneeth Prakhya wrote:
    > > From: Sai Praneeth <sai.praneeth.prakhya@intel.com>
    > >
    > > Presently, efi_runtime_services() are executed by firmware in process
    > > context. To execute efi_runtime_service(), kernel switches the page
    > > directory from swapper_pgd to efi_pgd. However, efi_pgd doesn't have
    > > any user space mappings. A potential issue could be, for instance, an
    > > NMI interrupt (like perf) trying to profile some user data while in efi_pgd.
    >
    > It might be worth pointing out that this could result in disaster (e.g.
    > if the frame pointer happens to point at MMIO in the EFI runtime services
    > mappings).
    >

    Sorry! I didn't get it. I would like to add this point, so could you please
    explain it more?

    > [...]
    >
    > > pstore writes could potentially be invoked in interrupt context and it
    > > uses set_variable<>() and query_variable_info<>() to store logs. If we
    > > invoke efi_runtime_services() through efi_rts_wq while in atomic()
    > > kernel issues a warning ("scheduling wile in atomic") and prints stack
    > > trace. One way to overcome this is to not make the caller process wait
    > > for the worker thread to finish. This approach breaks pstore i.e. the
    > > log messages aren't written to efi variables. Hence, pstore calls
    > > efi_runtime_services() without using efi_rts_wq or in other words
    > > efi_rts_wq will be used unconditionally for all the
    > > efi_runtime_services() except set_variable<>() and
    > > query_variable_info<>()
    >
    > Can't NMIs still come in during this?
    >
    > ... or do we assume that since something has already gone wrong, this doesn't
    > matter?
    >

    I think they can come. AFAIK, pstore (if enabled) runs only when we crashed.
    Since, we are still executing stuff to log messages and NMI's can't be masked,
    there is still a possibility for NMI's to occur (please correct me if I am wrong).
    But, as you said earlier, I guess it doesn't matter because anyways we are going down.

    > Otherwise, this doesn't seem to break basic stuff on arm64 platforms. I can boot
    > up, read the EFI RTC, and reboot. I ahd lockdep and KASAN enabled, I received
    > no splats from either.
    >
    > FWIW:
    >
    > Tested-by: Mark Rutland <mark.rutland@arm.com [arm64]
    >
    > Thanks,
    > Mark.

    \
     
     \ /
      Last update: 2018-03-08 05:12    [W:3.931 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site