On Thu, Jan 27, 2005 at 02:29:43PM -0800, Andrew Morton wrote: > I've already queued a patch for this: > > --- 25/mm/oom_kill.c~mm-fix-several-oom-killer-bugs-fix Thu Jan 27 > 13:56:58 2005 > +++ 25-akpm/mm/oom_kill.c Thu Jan 27 13:57:19 2005 > @@ -198,12 +198,7 @@ static void __oom_kill_task(task_t *p) > p->time_slice = HZ; > p->memdie = 1; > > - /* This process has hardware access, be more careful. */ > - if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) { > - force_sig(SIGTERM, p); > - } else { > - force_sig(SIGKILL, p); > - } > + force_sig(SIGKILL, p); > } > > static struct mm_struct *oom_kill_task(task_t *p)
Thanks. > However. This means that we'll now kill off tasks which had hardware > access. What are the implications of this? The implication of the above is basically that the X server won't be able to restore the text mode, but that avoids the deadlock ;). And they had not necessairly hardware access. They "might" have hardware access. Note that an app may have hardware access even if it has no rawio capabilities. One can run iopl and then change uid just fine. So the above check is quite weak since it leaves the kernel susceptible to bugs and memleaks in any app started by root. Kernel shouldn't trust root apps, all apps are buggy, root apps too (I even once fixed a signal race in /sbin/init that showed up with the schedule child first sched optimization ;). iopl and ioperm are the only two things we care about. We can a synchronous reliable eflags/ioperm value only from the "regs" in the task context. Problem is that since we can pick a task to kill that isn't necessairly the current task, we should start to approximate, and assume the process is sleeping. The regs must be saved during reschedule, so it should cache the old contents. So perhaps we can get a pratically reliable eflags dump from the tss_struct. But this will not be common code and it'll require a specialized arch API. Like has_hw_access(). Only then we can make a stronger assumption and be truly careful about sending SIGKILL. The right way to do this is probably to wait a few seconds before sending the sigkill. I'm not currently sure if it worth adding the has_hw_access(). But certainly I would prefer to do nothing special with only the sys_rawio capability. I thought I could wait the other patches to be merged to avoid confusion before making more changes (since it'd be a pretty self contained feature), but I can do that now if you prefer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/