On 26 July 2018 at 20:51, Prakhya, Sai Praneeth <sai.praneeth.prakhya@xxxxxxxxx> wrote: >> > The basic idea is that, when you get an exception from a context that >> > is busted (i.e. it wasn't user code with a signal handler or kernel >> > code with a fixup), you can't return from the exception handler. That >> > leaves two choices: >> > >> > 1. Kill the task without returning. You could call do_exit(), or, >> > roughly equivalently, let yourself OOPS (fall through to die(), etc). >> > Then you have to make sure that the code that called into the thread >> > can handle it by signaling some completion first or whatever you need >> > to do. >> > >> > 2. Sleep forever. For example, set the task state to >> > TASK_UNINTERRUPTIBLE and reschedule. >> > >> > If the thread is a real kthread, (1) may be a bad idea. I’m not sure a >> > kthread can tolerate do_exit(), since the kthread core plays awful >> > games involving storing important data structures on the stack. Also, >> > with (2), it might be possible to enable some after-the-fact >> > debugging, since the full crashing state is still there. >> > >> >> 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. -- 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
