| Age | Commit message (Collapse) | Author |
|---|
|
This follows the sparc changes a439fe51a1f8eb087c22dd24d69cebae4a3addac.
Most of the moving about was done with Sam's directions at:
http://marc.info/?l=linux-sh&m=121724823706062&w=2
with subsequent hacking and fixups entirely my fault.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
Most of the include/asm-*/resource.h headers are the same as one another.
This patch makes one generic version, include/asm-generic/resource.h, and
uses that when appropriate. The only vaguely interesting things here are
that the generic version introduces a new _STK_LIM_MAX macro, which can be
populated by an arch (ia64 and parisc needed that). Also, some arches hid
RLIM_INFINITY under __KERNEL__, while others did not. The generic version
does not, so the following arches will see that change:
arm, arm26, mips, ppc, ppc64, sh (and hence sh64)
And, finally, some arches maintain their own order for the resource
numbers. This is now marked by __ARCH_RLIMIT_ORDER, and is used by the
following arches:
alpha, mips, sparc, and sparc64.
This actually uncovered a mips bug (fix already sent, this patch is
relative to that fix), where the default RLIMIT_MEMLOCK was set to
RLIM_INFINITY and RLIMIT_NPROC set to MLOCK_LIMIT (the latter is no big
deal because RLIMIT_NPROC default is overwritten dynamically during bootup
in fork_init()). Also, this change makes alpha's default for RLIMIT_NPROC
change from RLIM_INFINITY to 0, but again...no problem as it's dynamically
overwritten during bootup.
The following arches are left untouched:
m68knommu: untouched (uses m68k/resource.h)
sh64: untouched (uses asm-sh/resource.h)
um: untouched (uses arch code already)
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Since various gnupg users have indicated that gpg wants to mlock 32kB of
memory, I created the patch below that increases the default mlock ulimit
to 32kB.
This is no security problem because it's trivial for processes to lock way
more memory than this in page tables, network buffers, etc. In fact, since
this patch allows gnupg to mlock to prevent passphrase data from being
swapped out, the security people will probably like it ;)
This gets the new per-user mlock limit a bit more testing, too.
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Here is the last agreed-on patch that lets normal users mlock pages up to
their rlimit. This patch addresses all the issues brought up by Chris and
Andrea.
From: Chris Wright <chrisw@osdl.org>
Couple more nits.
The default lockable amount is one page now (first patch is was 0). Why
don't we keep it as 0, with the CAP_IPC_LOCK overrides in place? That way
nothing is changed from user perspective, and the rest of the policy can be
done by userspace as it should.
This patch breaks in one scenario. When ulimit == 0, process has
CAP_IPC_LOCK, and does SHM_LOCK. The subsequent unlock or destroy will
corrupt the locked_shm count.
It's also inconsistent in handling user_can_mlock/CAP_IPC_LOCK interaction
betwen shm_lock and shm_hugetlb.
SHM_HUGETLB can now only be done by the shm_group or CAP_IPC_LOCK.
Not any can_do_mlock() user.
Double check of can_do_mlock isn't needed in SHM_LOCK path.
Interface names user_can_mlock and user_substract_mlock could be better.
Incremental update below. Ran some simple sanity tests on this plus my
patch below and didn't find any problems.
* Make default RLIM_MEMLOCK limit 0.
* Move CAP_IPC_LOCK check into user_can_mlock to be consistent
and fix but with ulimit == 0 && CAP_IPC_LOCK with SHM_LOCK.
* Allow can_do_mlock() user to try SHM_HUGETLB setup.
* Remove unecessary extra can_do_mlock() test in shmem_lock().
* Rename user_can_mlock to user_shm_lock and user_subtract_mlock
to user_shm_unlock.
* Use user instead of current->user to fit in 80 cols on SHM_LOCK.
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Add an rlimit entry to control the maximum number of bytes a user can allocate
to a POSIX mqueue.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The following patches introduce per user rlimits for both queued signals and
POSIX message queues. The changes touch all the arches resource.h files as
well as init_task.c to get the rlimit defaults setup.
Both require caching the user_struct to avoid problems with setuid().
The signal changes makes some small changes to send_signal() to pass along the
task being signalled to get proper accounting for signals initiated in
interrupt. Thanks to Marcelo for getting this one going.
This patch:
Add an rlimit entry to control the maximum number of pending signals a user
may have. This is essentially just the resource.h changes.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
|
