Messages in this thread | | | Date | Fri, 2 Apr 2004 05:07:25 +0200 | From | Andrea Arcangeli <> | Subject | Re: disable-cap-mlock |
| |
On Thu, Apr 01, 2004 at 06:49:07PM -0800, Andrew Morton wrote: > Andrea Arcangeli <andrea@suse.de> wrote: > > > > > One thing I was wondering was whether /proc/sys/vm/disable_cap_mlock should > > > hold a GID rather than a boolean. So you do > > > > > > echo groupof oracle > /proc/sys/vm/disable_cap_mlock > > > > that's probably optimal OTOH that would complicate the code, I prefer an > > obviously safe !disable_cap_mlock, if we want to go complicated we can > > probably wait the userspace solution ;) > > That depends on how you structure the code. If you do it the below way, > it's a one-liner.
after you did this cleanup effort I'll have to merge your version ;)
> > (Will the compiler propagate `unlikeliness' out of an inline function?)
it should, both need_resched and signal_pending depends on it, but I don't think unlikely is correct, it's likely infact, optimizing for an application returning -EPERM doesn't sound worthwhile, so I'll change it to "likely".
thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |