> > 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? > The problem with efi_reset_system() being buggy is, If user calls "reboot", kernel would call efi_reset_system() and if unhandled, kernel hangs and never reboots. But, if handled and returning error (either using long jump or some other technique), kernel could continue rebooting through other fall backs. I think, this is true only for x86 though. Please note that native_machine_emergency_restart() would call "BOOT_BIOS", if efi_reboot() returns in arch/x86/kernel/reboot > > 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? Hmm.. I think so.. I referred to the below articles while working on "efi_rts_wq" They say 1. Each workqueue has one or more dedicated worker threads (one per CPU, by default) associated with it. 2. Tasks running out of a special-purpose workqueue can sleep indefinitely, since they will not interfere with tasks in any other queue. [1] https://lwn.net/Articles/23634/ [2] https://lwn.net/Articles/11360/ Regards, Sai ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
