RE: [PATCH RFC 0/8] Add efi page fault handler to fix/recover from

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi All,

> > >> The main problem is that we have just merged Sai's code to use a
> > >> work queue for invoking EFI services, and killing kworker threads
> > >> is obviously not going to make EFI any new friends.
> > >>
> > >> So I guess we should probably rework that code to use a dedicated
> > >> kthread, and just freeze it when it performs an illegal memory
> > >> access, and signal the completion in a way that makes the calling
> > >> thread understand that a) the call failed and b) runtime services
> > >> are no longer
> > available.
> > >
> > > Yes, this makes sense to me.
> > > Initially I did use a dedicated kthread for efi but moved to work
> > > queues later so
> > that the synchronization is well handled. I am ok to rework on the
> > patches, could we ask Ingo to hold onto efi_workqueue patches?
> > >
> >
> > I am fine with keeping them. We will have a different approach in
> > v4.19 than in subsequent kernels, but the workqueue approach is still
> > better than nothing at all.

As discussed in previous mails, I have implemented the below:

If kernel detects an illegal access by firmware to any efi region other than 
efi boot time code/data,
a. It freezes "efi_rts_wq" (efi runtime services work queue).
b. Signals the requested process that an error occurred.
c. Disables EFI Runtime Services forever.
d. Explicitly calls the scheduler to schedule another process.

But, I have couple of questions:

1. Since we don't use "efi_rts_wq" for efi_reset_system(), the above solution 
doesn't work if efi_reset_system() is buggy. We cannot neglect it either because 
that's the issue faced by Al Stone and hence I started the patch set. So, I am thinking 
to use long jump technique *only* for efi_reset_system(). Would you be OK with that?
Or please propose a new solution.

2. Also, as suggested, I haven’t used a dedicated "efi_kthread", I got this working with 
the existing "efi_rts_wq" setup. Please note that, the existing "efi_rts_wq", has only one 
worker thread. Could you please brief me on why we should have a dedicated kthread 
and not leverage "efi_rts_wq" (I am unclear on this).

Regards,
Sai
��.n��������+%������w��{.n�����{����*jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux