* Chris Wright <[EMAIL PROTECTED]> wrote: > > did that thread go into technical details? There are some rlimit users > > that might not be prepared to see the rlimit change under them. The > > RT_CPU_RATIO one ought to be safe, but generally i'm not so sure. > > Not really. I mentioned the above, as well as the security concern. > Right now, at least the task_setrlimit hook would have to change to > take into account the task. And I never convinced myself that async > changes would be safe for each rlimit.
e.g. the stack rlimit looks dangerous, if any VM codepath ever looks twice on it (and relies on it being the same, somehow). But if someone reviewed all of the rlimit use in the kernel, we could make it a policy that rlimits might change. Any unsafe use could be made safe pretty easily. Since they are ulongs they are updated atomically even without any locking - but e.g. the default and the hard limit might change separately. (from the viewpoint of rlimit-using kernel code.) obviously a remote rlimit must listen to same kind of security permissions as e.g. ptrace or signal sending. Ingo - 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/