Re: User space out of memory approach

[Andrea Arcangeli <andrea@suse.de>]

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.