On 7 August 2018 at 20:01, Prakhya, Sai Praneeth <sai.praneeth.prakhya@xxxxxxxxx> wrote: > 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. > What would be the point of that? Can you reasonably expect the kernel to still run reliably after it has taken itself down, called efi_reset_system() and failed? > 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). > Does every work queue have its own dedicated kernel thread? -- 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
