This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
because it doesn't copy anything from/to userspace to access the
argument.
Acked-by: Aleksa Sarai
Oops, I misunderstood what _IOR means semantically. TIL -- thanks!
--
Aleksa Sarai
Software Engineer (Containers)
SUSE
this problem to be manifested on boot for some machines).
Cc: # v3.11+
Cc: Jeff Mahoney
Fixes: b382a324b60f ("Btrfs: fix qgroup rescan resume on mount")
Signed-off-by: Aleksa Sarai
---
fs/btrfs/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/super.c b/fs/btrf
add TIOCGPTPEER ioctl")
Signed-off-by: Arnd Bergmann
Oops, I missed that.
Acked-by: Aleksa Sarai
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
namespaces to safely create {master,slave} pseudoterminal pairs
without needing to open potentially unsafe /dev/pts/... filenames that
may be malicious mountpoints or similar in an untrusted namespace
(avoiding the endless issues with ptsname(3) and similar approaches).
Cc:
Signed-off-by: Aleksa
rauner
Cc: Valentin Rothberg
Signed-off-by: Aleksa Sarai
Is this going to be documented anywhere? Is there a man page update
that also goes along with this?
I will add one, I didn't know where the man-pages project is hosted / where
patches get pushed? What is the ML?
From the M
rauner
Cc: Valentin Rothberg
Signed-off-by: Aleksa Sarai
Is this going to be documented anywhere? Is there a man page update
that also goes along with this?
I will add one, I didn't know where the man-pages project is hosted /
where patches get pushed? What is the ML?
What userspac
mental level than nptl.
Which I think makes this surprising even if you know that setuid is
implemented in userspace.
Quite surprising, thanks for the explanation.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
given that, I wouldn't be surprised (as a user) that zombie threads will
have stale credentials (glibc isn't running in those threads anymore).
Am I mistaken in that belief?
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
*tty,
unsigned int cmd, unsigned long arg);
If you like, I can change (*ioctl) to return longs as well, and then
change all of the call-sites (since unlocked_ioctl also returns long).
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
.
Signed-off-by: Aleksa Sarai
---
drivers/tty/pty.c | 22 ++
fs/compat_ioctl.c | 6 --
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 65799575c666..2a6bd9ae3f8b 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
Changes in v4:
* Dropped an accidental change to Makefile.
Aleksa Sarai (2):
tty: add compat_ioctl callbacks
tty: add TIOCGPTPEER ioctl
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/powerpc
rauner
Cc: Valentin Rothberg
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/powerpc/include/uapi/asm/ioctls.h | 1 +
arch/sh/include/uapi/asm/ioctls.h | 1 +
-declaration \
-Wno-format-security \
+ -Wno-error=int-in-bool-context \
-std=gnu89 $(call cc-option,-fno-PIE)
Ah sorry, I committed that by accident. I'll send a fixed version.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
rauner
Cc: Valentin Rothberg
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/powerpc/include/uapi/asm/ioctls.h | 1 +
arch/sh/include/uapi/asm/ioctls.h | 1 +
.
Signed-off-by: Aleksa Sarai
---
Makefile | 1 +
drivers/tty/pty.c | 22 ++
fs/compat_ioctl.c | 6 --
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 470bd4d9513a..fb689286d83a 100644
--- a/Makefile
+++ b/Makefile
@@ -401,6
Changes in v3:
* Defined a compat_ioctl callback for all pty ioctls, since they are
all 32-bit and 64-bit compatible.
* Made TIOCGPTPEER support 32-bit userspace.
Aleksa Sarai (2):
tty: add compat_ioctl callbacks
tty: add TIOCGPTPEER ioctl
Makefile | 1
Changes in v2:
* Reordered addition to ioctls.h to follow correct hex ordering.
Aleksa Sarai (1):
tty: add TIOCGPTPEER ioctl
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/powerpc/include
rauner
Cc: Valentin Rothberg
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/powerpc/include/uapi/asm/ioctls.h | 1 +
arch/sh/include/uapi/asm/ioctls.h | 1 +
ery
similar to TIOCGPTN and TIOSPTLCK, but I can move it if the hex order is
more important for maintainence.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
rauner
Cc: Valentin Rothberg
Signed-off-by: Aleksa Sarai
---
arch/alpha/include/uapi/asm/ioctls.h | 1 +
arch/mips/include/uapi/asm/ioctls.h| 1 +
arch/parisc/include/uapi/asm/ioctls.h | 1 +
arch/powerpc/include/uapi/asm/ioctls.h | 1 +
arch/sh/include/uapi/asm/ioctls.h | 1 +
, I didn't see that patch. Yeah, you're right.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
cro
‘MIPI_INIT_COUNT’
I915_WRITE(MIPI_INIT_COUNT(port ==
^~~
Signed-off-by: Aleksa Sarai
---
drivers/gpu/drm/i915/intel_dsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
in
I had some ideas about how you could implement bridging in userspace (as
an unprivileged user, for rootless containers) but if you can't join
namespaces individually then such a setup is not practically possible.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
s the container init process -- so it shouldn't break
anything for runC). I was just pointing out that systemd isn't the only
major userspace user of the prctl (for future reference).
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
exit code from PID 1 in the container).
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
ase, this makes
the fact that getgroups(2) returns 65534 even _more_ concerning -- how
on earth is a userspace process meant to know what secret privileges it
has? How can it make sane decisions about security with this setup?
% touch somefile
% chmod 660 somefile
% sudo chown root:wheel somefile
% unshar
es
one applicaiton work for me.
I need to get better at writing commit messages, sorry about that. As I
mentioned above, the biggest issue is the ambiguity of 65534. The fact
that apt doesn't react in a sane way is a symptom of that issue, and
there are almost certainly more cases of programs t
e to filter out these "fake" group IDs anyway.
This just makes it so that less applications will have to handle this
broken API.
Fixes: 9cc46516ddf4 ("userns: Add a knob to disable setgroups on a per user
namespace basis")
Cc: "Eric W. Biederman"
Cc:
Signed-of
ing that we should consider?
RE: llist_head, the problem with that is that appending to the end is an
O(n) operation. Though, as I said, n is not going to be very large in
most cases.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
Rather than implementing an open addressing linked list structure
ourselves, use the standard list_head structure to improve consistency
with the rest of the kernel and reduce confusion.
Cc: Michal Hocko
Cc: Oleg Nesterov
Signed-off-by: Aleksa Sarai
---
include/linux/sched.h | 6
Rather than implementing an open addressing linked list structure
ourselves, use the standard list_head structure to improve consistency
with the rest of the kernel and reduce confusion.
Cc: Michal Hocko
Cc: Oleg Nesterov
Signed-off-by: Aleksa Sarai
---
include/linux/sched.h | 6
a
directory that the whole world can access matters.
Okay, but why is it being applied to _all_ subdirectories of /proc/pid?
Why not make it *only* set the owner of /proc/pid and nothing else?
Looks like that was not intended given the reasons you just provided.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
he original reasoning behind it? Does it make
sense for a non-dumpable process to allow someone to change the mode of
some random /proc/[pid]/ directories?
I get the feeling that some of this logic is a bit iffy.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
sing something
but I can't think of the security issue that this code currently fixes
(since all of the important permission checks are *in addition* to the
generic_permission used for /proc/self/..., which use ptrace_may_access).
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
s, so is_group_p() will succeed. Also hide_pid_min is set such
that it will work in either case.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
dation.org
Signed-off-by: Aleksa Sarai
---
fs/proc/base.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ca651ac00660..ebabb12f4536 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1729,6 +1729,7 @@ int pid_getattr(struct vfsmoun
inst access of CLOEXEC file descriptors -- file descriptors which may
reference filesystem objects the container shouldn't have access to).
Cc: d...@opencontainers.org
Cc: # v3.2+
Reported-by: Michael Crosby
Signed-off-by: Aleksa Sarai
---
fs/exec.c | 10 --
1 file changed, 8 insertion
, I'll cc stable (v3.2+) to the
patch.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
inst access of CLOEXEC file descriptors -- file descriptors which may
reference filesystem objects the container shouldn't have access to).
Cc: d...@opencontainers.org
Reported-by: Michael Crosby
Signed-off-by: Aleksa Sarai
---
fs/exec.c | 10 --
1 file changed, 8 insertions(+), 2 dele
;ll apply it to my
local kernel. :D
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
issue still persists, but I didn't apply your other proposed
change to this conditional.
Or am I misunderstanding what tsk->ptrace refers to?
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
to move the
actual processes within the cgroup namespace around? The administrator
could also join the cgroupns (without needing to join the userns) and
then just move things around that way?
Do any of those suggestions seem reasonable?
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
ss anything (and if there's
enough processes then cgroup.procs reads aren't atomic either).
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
oesn't
inspire confidence :/ (from the runC side, we've had nothing but
issues). Also, how do you even boot into a cgroupv2 system with systemd
(I started backporting patches to openSUSE, but it's still not booting)?
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
administrator to
*install* and support LXC (as well as the shadow-utils setuid binaries
too). There are cases where you don't have the freedom to do that, and
also "just get someone to give you privileges temporarily" is again
punting on the problem.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
folks would find it useful to be able to
limit browser processes in a similar way.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
e container crowd, but people also
planning on using cgroups as advanced forms of rlimits).
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
eference doesn't do anything. Getting it here would only make
sense if the pointer is passed to an asynchronous context.
I'll send out a fixed patchset once we figure out the
cgroups_proc_write_permission() stuff.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
e, etc).
The current setup would obviously still work, but you'd add a permission
for users that just want to be able to limit their own processes. IIRC
we need to update cgroup_procs_write_permission() anyway. By having the
cgroup namespace requirement, you'd definitely have to &qu
rocs write access to their current cgroup.
This is important for unprivileged subtree management, as it allows
unprivileged processes to move to their newly create subtrees.
Cc: d...@opencontainers.org
Signed-off-by: Aleksa Sarai
---
kernel/cgroup.c | 24
1 file c
s a design constraint
this is possible.
It should be noted that cgroupv2 also has attaching restrictions that
make this process safe against two complicit processes from migrating
a process to the less restrictive cgroup of the two.
Cc: d...@opencontainers.org
Signed-off-by: Aleksa Sarai
---
ker
you're in (because that restriction
doesn't make much sense).
[1]: http://marc.info/?l=linux-kernel&m=146319604331859
Cc: d...@opencontainers.org
Aleksa Sarai (3):
kernfs: add support for custom per-sb permission hooks
cgroup: allow for unprivileged subtree management
cgrou
This allows for users of kernfs to create custom (and possibly less
restrictive) permission checks for kernfs_nodes. The default is
unchanged. This patch is part of the cgroupns unprivileged subtree
management patchset.
Cc: d...@opencontainers.org
Signed-off-by: Aleksa Sarai
---
fs/kernfs
On Sun, Jun 26, 2016 at 09:34:41PM +1000, Aleksa Sarai wrote:
If a user has a setup where they wait for notifications on changes to
pids.event, and then auto-adjust the cgroup limits based on the number of
failures you have a race condition between reading the pids.event file and
then setting
On Fri, Jun 24, 2016 at 01:00:48PM +1000, Aleksa Sarai wrote:
This allows users to dynamically adjust their limits based on how many
failed forks happened since they last reset their limits, otherwise they
would have to track (in a racy way) how many limit failures there were
since the last
set-we-log-failures-again semantics that Tejun said he liked.
Aleksa Sarai (2):
cgroup: pids: show number of failed forks since limit reset
docs: cgroup/pids: update documentation to include pids.events
Documentation/cgroup-v1/pids.txt | 18 ++
kernel/cgroup_pids.c
the limit was reset (which was the original semantics of
the patchset).
In addition, I clarified the licensing for this file.
Signed-off-by: Aleksa Sarai
---
kernel/cgroup_pids.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/kernel
So that users know what the interface and meaning of the keyed values
are. In addition, mention that the only time that since=0 is when the
limit was changed.
Signed-off-by: Aleksa Sarai
---
Documentation/cgroup-v1/pids.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a
}
> + }
> + return err;
> }
Why are we logging this? Isn't the pids.events file enough
information? I feel like you could remove a lot of logic if you don't
log this.
And even if we do end up logging it, why have the boolean flag (the
counter always increases, just log if the counter is currently 0 and
you're incrementing it).
--
Aleksa Sarai (cyphar)
www.cyphar.com
ues James is referring to
is that the cgroup manager could have a bug in it (and because the
cgroup interface is the filesystem, it would probably be some kind of
write-to-any-path bug). This is an intrinsic part of the model of "you
need to have cooperation with an admin process in order to use
resource limiting for your own processes".
--
Aleksa Sarai (cyphar)
www.cyphar.com
tion I'd have is how would we deal with visibility (and
should a "parent" cgroup namespace be able to modify things inside the
cgroup?). And of course, how would that interact with VFS?
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
ysctl?).
PTAL.
[1]: https://lkml.org/lkml/2016/5/2/280
Aleksa Sarai (2):
cgroup: make cgroup.procs permissions userns-aware
cgroup: implement subtree creation on copy_cgroup_ns()
kernel/cgroup.c | 149 +++-
1 file changed, 126 insertion
namespace.
Signed-off-by: Aleksa Sarai
---
kernel/cgroup.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 86cb5c6e8932..f1c798b69561 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2841,6 +2841,8 @@ static int cgroup_procs_write_permiss
ctl?).
PTAL.
[1]: https://lkml.org/lkml/2016/5/2/280
Aleksa Sarai (2):
cgroup: make cgroup.procs permissions userns-aware
cgroup: implement subtree creation on copy_cgroup_ns()
kernel/cgroup.c | 149 +++-
1 file changed, 126 insertions(+), 23 deletions(-)
--
2.8.2
Signed-off-by: Aleksa Sarai
---
kernel/cgroup.c | 143 +++-
1 file changed, 120 insertions(+), 23 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index f1c798b69561..f455488dc899 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -
use problems for someone.
Does anyone have any opinions on this idea?
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
to the problem.
3. We'd be creating cgroups and attaching processes to the cgroups
without explicitly going through the VFS layer. This presumably means
that other parts of userspace might not get alerted properly to the
changes. I'm not really sure how we should deal with that, but
p and the
target cgroup.
Currently the decision is made in cgroup_procs_write_permission() and
actually is blind to the user namespace, so this needs updating anyway.
Yeah, but we can't apply it (the common ancestor restriction) to
cgroupv1 (back-compat). Maybe we could combine both up
#x27;t support all of the controllers needed for many container
runtimes to work, I don't think we should not implement this for
cgroupv1. But that's just my opinion.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
use the
cgroup_ns->pid_ns), I'm just wondering if it's necessary.
We could do this in the same way that proc gets virtualized after
remounting (in a new mount namespace) on fork into a pid namespace.
I actually really like this idea. I'll get to work on it.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
ce to modify
subtrees (but without allowing for cgroup escape) -- by pinning what pid
namespace the cgroup was created under. We can use the same type of
virtualization that /proc does (except instead of selectively showing
the dentries, we selectively show different owners of the dentries).
Would t
So, you can't apply a new restriction like this retro-actively to
cgroup v1 hierarchies.
Okay, understood. I'll see if it's possible to make this change safe
without adding restrictions to cgroupv1 hierarchies.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE L
ode of the cgroup didn't have a+rx, so
administrators can opt-out of this feature on a cgroup-by-cgroup basis.
Cc: d...@opencontainers.org
Signed-off-by: Aleksa Sarai
---
kernel/cgroup.c | 82 +++--
1 file changed, 80 insertions(+), 2 del
cs
tee: /sys/fs/cgroup/pids/parent/b/cgroup.procs: Permission denied
---
Fixes: 187fe84067bd ("cgroup: require write perm on common ancestor when
moving processes on the default hierarchy")
Cc: d...@opencontainers.org
Signed-off-by: Aleksa Sarai
Signed-off-by: Aleksa Sarai
cgroups to have the permissions
a-rx. This update also includes an updated version of the comment
describing the guarantees given by Unix directory permissions and cgroup
core.
[1]: https://lkml.org/lkml/2016/5/1/87
Aleksa Sarai (2):
cgroup: apply common ancestor cgroup.procs restriction in cgroupv
group to overcome your own
+*cgroup restriction.
It appears this restriction isn't actually being applied on cgroupv1.
I'll send an updated patch which makes sure the cgroup.proc common
ancestor restriction is enforced for all hierarchies.
--
Aleksa Sarai
Software Engin
namespace with a subtree it owns as the
root of that namespace (then changing the file mode such that only
sufficiently capable processes in the associated user namespace can
modify the subtree setup).
Signed-off-by: Aleksa Sarai
Cc: d...@opencontainers.org
---
kernel/cgr
This is an updated version of v1 of this patchset[1], which properly
unlocks all of the relevant locks in the error path of copy_cgroup_ns().
[1]: https://lkml.org/lkml/2016/5/1/77
Aleksa Sarai (1):
cgroup: allow management of subtrees by new cgroup namespaces
kernel/cgroup.c | 74
cgroup_kn_set_mode(kn, mode[ssid]);
> + kernfs_unbreak_active_protection(kn);
> + } while_each_subsys_mask();
Sorry, I just realised this doesn't unlock all of the relevant locks
in the error path. I'll send an updated patch.
--
Aleksa Sarai (cyphar)
www.cyphar.com
/pull/774
Aleksa Sarai (1):
cgroup: allow management of subtrees by new cgroup namespaces
kernel/cgroup.c | 71 +++--
1 file changed, 69 insertions(+), 2 deletions(-)
--
2.8.1
namespace with a subtree it owns as the
root of that namespace (then changing the file mode such that only
sufficiently capable processes in the associated user namespace can
modify the subtree setup).
Signed-off-by: Aleksa Sarai
Cc: d...@opencontainers.org
---
kernel/cgr
ther or not
> CLONE_NEWCGROUP only works for cgroupv2 or does it also work on
> cgroupv1 (we haven't yet transitioned to cgroupv2 in runC).
>
> Thanks.
>
> [1]: https://github.com/opencontainers/runc/pull/774
Does anyone have an opinion on this proposal?
--
Aleksa Sarai (cyphar)
www.cyphar.com
k? Are there any recommendations on whether
we can make this work better? Also, can you clarify whether or not
CLONE_NEWCGROUP only works for cgroupv2 or does it also work on
cgroupv1 (we haven't yet transitioned to cgroupv2 in runC).
Thanks.
[1]: https://github.com/opencontainers/runc/pull/774
--
Aleksa Sarai (cyphar)
www.cyphar.com
> Again, if we do this, we can make other cleanups/simplifications. For example,
> we can kill cgrp_ss_priv[CGROUP_CANFORK_COUNT] in copy_process().
Thank god, I never liked that code. ;)
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubs
, and the cpu cgroup is by no means a magic
> bullet to handle this.
I feel like these are backed by different resources, and we should
work on limiting those *at the source* in the context of a controller
rather than just patching up the symptoms (too many forks causing
issues), becau
fork()s, they're bad
because the *create a bunch of processes that use up memory*, which
happens because they call fork() a bunch of times and **don't
exit()**.
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
t; exit.
Looks good to me. Out of interest, is there any reason why we still
have ->exit(), given the zombie process edge case? Surely the zombie
process edge case would cause issues with kmemcg and similar
controllers, if they use ->exit() and not ->free()?
--
Aleksa Sarai (cyph
oller? But I'm not sure if that's safe (can we
even call task_get_css() on a task that's being waited on?).
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
> On Thu, Sep 24, 2015 at 09:42:38AM +1000, Aleksa Sarai wrote:
>> Does it make sense for the PIDs controller to allow a user to set a
>> limit of 0? Since we don't cancel attaches, a limit of 0 doesn't
>> affect anything (nothing stops attaches, and you need t
think that attempting to set pid.limit to 0 should return
an -EINVAL.
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majord
.
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
syscall in the first place?
I completely understand if you can't remember all of the technical
decisions you made in 1991, but this one really bugged me when I
landed upon the man page for this (now defunct) syscall. If you could
shed some light on this, I'd really appreciate it.
--
Al
are in
drivers/hid/ isn't going to be much use if one were to try to
implement a driver for this hardware?
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
, so what gives? Is there some peculiarity with this hardware?
Am I not reading the above patches correctly? I'd be happy to test any
patches you'd like to throw at me.
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe lin
optimisation
that it would be pointless to use a better structure? Also, is there a
good reason why we have UID_GID_MAP_MAX_EXTENTS = 5 (other than the
one cache line thing)? Surely it's not more efficient to have to
create a bunch of nested namespaces in order to have more than 5
extents?
se, why do you get EBUSY when trying to
remove the module (surely you should get an ENOENT)? Is it even safe
to attempt to remove a module from within itself?
Thanks in advance.
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-k
Fix incorrect usage of css_get and css_put to put a different css in
pids_{cancel_,}attach() than the one grabbed in pids_can_attach(). This
could lead to quite serious memory leakage (and unsafe operations on the
putted css).
Signed-off-by: Aleksa Sarai
---
kernel/cgroup_pids.c | 19
protect the contained csses is "sort of implementation detail. It can
be implemented in different ways." Which made me think that depending
on that is not a good idea.
But if it's safe to depend on the cgroup_migrate_add_src() pinning the
ref on the css_set, I'll drop this patch
Thanks to Nikolay Borisov who discovered this.
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
P
g
cgroup_migrate() to grab a reference before ->can_attach() and once the
attach has failed or succeded.
Aleksa Sarai (2):
cgroup: get a ref to source csses when migrating
cgroup: pids: fix invalid get/put usage
kernel/cgroup.c | 21 +++--
kernel/cgroup_pids.c | 13 +--
301 - 400 of 513 matches
Mail list logo
