From: "Michael Kerrisk" <mtk-manpages@gmx.net>
To: Christoph Lameter <clameter@sgi.com>
Cc: ak@suse.de, linux-mm@kvack.org, michael.kerrisk@gmx.net
Subject: Re: Inconsistent capabilites associated with MPOL_MOVE_ALL
Date: Wed, 15 Mar 2006 01:25:27 +0100 (MET) [thread overview]
Message-ID: <23583.1142382327@www015.gmx.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0603141608350.22835@schroedinger.engr.sgi.com>
Christoph,
> > err = do_migrate_pages(mm, &old, &new,
> > capable(CAP_SYS_ADMIN) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE);
> >
> > while in the implemantation of mbind() we have:
> >
> > if ((flags & MPOL_MF_MOVE_ALL( && !capable(CAP_SYS_RESOURCE))
> > return -EPERM;
> >
> > Is it really intended to associate two *different* capabilities
> > with the operation of MPOL_MF_MOVE_ALL in this fashion? At
> > first glance, it seems rather inconsistent to do so.
>
> You are likely right. Which one is the more correct capability to use?
Umm -- maybe CAP_SYS_NICE!
Whichever it is, I think it should be consistent. See below
for why I mention CAP_SYS_NICE.
In case it helps you decide which to use, here's a list of
what I know each of these capabilities already allows:
CAP_SYS_NICE
Raise process nice value (nice(), setpriority());
change nice value for arbitrary processes (setpriority());
set SCHED_RR and SCHED_FIFO real-time scheduling policies for
calling process, set scheduling policies and priorities
for arbitrary processes (sched_setscheduler(), sched_setparam());
set CPU affinity for arbitrary processes (sched_setaffinity())
It seems to me that setting scheduling policy and
priorities is also the kind of thing that might be performed
in apps that also use the NUMA API, so it would seem consistent
to use CAP_SYS_NICE for NUMA also.
CAP_SYS_RESOURCE
Use reserved space on file systems;
make ioctl() calls controlling ext3 journaling;
override disk quota limits;
increase hard resource limits (setrlimit());
override RLIMIT_NPROC resource limit (fork());
raise msg_qbytes limit for a message queue above limit in
/proc/sys/kernel/msgmnb;
bypass various POSIX message queue limits defined by files under
/proc/sys/fs/mqueue
CAP_SYS_ADMIN
Allow system calls that open files to exceed /proc/sys/fs/file-max
limit;
perform various system administration operations including:
quotactl() (control disk quotas), mount() and umount(),
swapon() and swapoff(), pivot_root(), sethostname() and setdomainname();
override RLIMIT_NPROC resource limit;
set trusted and security extended attributes;
perform IPC_SET and IPC_RMID operations on
arbitrary System V IPC objects;
forge PID when passing credentials via Unix domain socket;
employ TIOCCONS ioctl()
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-03-15 0:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-03 16:58 numa_maps update Christoph Lameter
2006-03-04 9:07 ` Andrew Morton
2006-03-04 4:59 ` Andi Kleen
2006-03-04 20:08 ` Christoph Lameter
2006-03-04 20:26 ` Andrew Morton
2006-03-06 16:19 ` Christoph Lameter
2006-03-06 17:37 ` Christoph Lameter
2006-03-15 0:01 ` Inconsistent capabilites associated with MPOL_MOVE_ALL Michael Kerrisk
2006-03-15 0:09 ` Christoph Lameter
2006-03-15 0:25 ` Michael Kerrisk [this message]
2006-03-15 0:33 ` Christoph Lameter
2006-03-15 0:40 ` Michael Kerrisk
2006-03-15 0:41 ` Andrew Morton
2006-03-15 0:53 ` Christoph Lameter
2006-03-15 1:01 ` Andrew Morton
2006-03-15 1:07 ` Michael Kerrisk
2006-03-15 1:12 ` Michael Kerrisk
2006-03-15 1:16 ` Christoph Lameter
2006-03-15 1:08 ` Christoph Lameter
2006-03-15 0:59 ` Michael Kerrisk
2006-03-15 1:16 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23583.1142382327@www015.gmx.net \
--to=mtk-manpages@gmx.net \
--cc=ak@suse.de \
--cc=clameter@sgi.com \
--cc=linux-mm@kvack.org \
--cc=michael.kerrisk@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox