* Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call
From: Eric W. Biederman @ 2014-10-19 0:20 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David Drysdale, Alexander Viro, Meredydd Luff,
linux-kernel@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Andrew Morton, Kees Cook, Arnd Bergmann, X86 ML,
linux-arch, Linux API
In-Reply-To: <CALCETrVraoD+r4zxBoGd+BV5P275AXcRV_R00SSr8fjQzRHnUg@mail.gmail.com>
Andy Lutomirski <luto@amacapital.net> writes:
> [Added Eric Biederman, since I think your tree might be a reasonable
> route forward for these patches.]
>
> On Thu, Jun 5, 2014 at 6:40 AM, David Drysdale <drysdale@google.com> wrote:
>> Resending, adding cc:linux-api.
>>
>> Also, it may help to add a little more background -- this patch is
>> needed as a (small) part of implementing Capsicum in the Linux kernel.
>>
>> Capsicum is a security framework that has been present in FreeBSD since
>> version 9.0 (Jan 2012), and is based on concepts from object-capability
>> security [1].
>>
>> One of the features of Capsicum is capability mode, which locks down
>> access to global namespaces such as the filesystem hierarchy. In
>> capability mode, /proc is thus inaccessible and so fexecve(3) doesn't
>> work -- hence the need for a kernel-space
>
> I just found myself wanting this syscall for another reason: injecting
> programs into sandboxes or otherwise heavily locked-down namespaces.
>
> For example, I want to be able to reliably do something like nsenter
> --namespace-flags-here toybox sh. Toybox's shell is unusual in that
> it is more or less fully functional, so this should Just Work (tm),
> except that the toybox binary might not exist in the namespace being
> entered. If execveat were available, I could rig nsenter or a similar
> tool to open it with O_CLOEXEC, enter the namespace, and then call
> execveat.
>
> Is there any reason that these patches can't be merged more or less as
> is for 3.19?
Yes. There is a silliness in how it implements fexecve. The fexecve
case should be use the empty string "" not a NULL pointer to indication
that. That change will then harmonize execveat with the other ...at
system calls and simplify the code and remove a special case. I believe
using the empty string "" requires implementing the AT_EMPTY_PATH flag.
For sandboxes execveat seems to make a great deal of sense. I can
get the same functionality by passing in a directory file descriptor
calling fchdir and execve so this should not introduce any new security
holes. And using the final file descriptor removes a race.
AT_SYMLINK_NOFOLLOW seems to have some limited utility as well, although
for exec I don't know what problems it can solve.
Until I am done moving I won't have time to pick this up, and the code
clearly needs another revision but I will be happy to work to see that
we get a sane execveat implemented.
Eric
p.s. I don't believe there are any namespaces issues where doing
something with execveat flags make sense.
^ permalink raw reply
* Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
From: One Thousand Gnomes @ 2014-10-18 21:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: John Stultz, lkml, devel, Linux API, Santosh Shilimkar,
Arve Hjønnevåg, Sumit Semwal, Rebecca Schultz Zavin,
Christoffer Dall, Anup Patel
In-Reply-To: <20141016231221.GA13592@kroah.com>
> Do we really need someone to do more work that has been done on it in
> the past as an official "maintainer"? I'll be glad to do it, as I doubt
> it will require any time at all.
Well every time in the past that Al Viro looked in its direction he broke
it so probably. Someone is going to have to clean up or fix the fact it
pokes around in the depths of the low level fd I/O code and calls stuff
like __fd_install and __alloc_fd directly, or mend it if it breaks.
I'm curious what Al Viro thinks of it
> > Currently in the android space no one but libbinder should use the
> > kernel interface.
>
> That is correct. If you do that, you deserve all of the pain and
> suffering and rooted machines you will get.
So what is the Android side model for its security. That probably also
should be described so nobody goes off and uses it for something like
systemd because "it looked neat".
> But all of the changes will be in new code. Be it kdbus, or something
> else if that doesn't work out. This existing binder.c file will not be
> changing at all. This existing ABI, and codebase, is something that we
> have to maintain forever for those millions of devices out there in the
> real world today.
95% of those devices are locked down, most of them have non replaceable
batteries that will dead and irreplacable (sanely anyway) in 3-5 years.
"Forever" in the phone world is mercifully rather short.
Alan
^ permalink raw reply
* Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call
From: Andy Lutomirski @ 2014-10-17 21:45 UTC (permalink / raw)
To: David Drysdale, Eric W. Biederman
Cc: Alexander Viro, Meredydd Luff,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Andrew Morton,
Kees Cook, Arnd Bergmann, X86 ML, linux-arch, Linux API
In-Reply-To: <1401975635-6162-1-git-send-email-drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
[Added Eric Biederman, since I think your tree might be a reasonable
route forward for these patches.]
On Thu, Jun 5, 2014 at 6:40 AM, David Drysdale <drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> Resending, adding cc:linux-api.
>
> Also, it may help to add a little more background -- this patch is
> needed as a (small) part of implementing Capsicum in the Linux kernel.
>
> Capsicum is a security framework that has been present in FreeBSD since
> version 9.0 (Jan 2012), and is based on concepts from object-capability
> security [1].
>
> One of the features of Capsicum is capability mode, which locks down
> access to global namespaces such as the filesystem hierarchy. In
> capability mode, /proc is thus inaccessible and so fexecve(3) doesn't
> work -- hence the need for a kernel-space
I just found myself wanting this syscall for another reason: injecting
programs into sandboxes or otherwise heavily locked-down namespaces.
For example, I want to be able to reliably do something like nsenter
--namespace-flags-here toybox sh. Toybox's shell is unusual in that
it is more or less fully functional, so this should Just Work (tm),
except that the toybox binary might not exist in the namespace being
entered. If execveat were available, I could rig nsenter or a similar
tool to open it with O_CLOEXEC, enter the namespace, and then call
execveat.
Is there any reason that these patches can't be merged more or less as
is for 3.19?
--Andy
>
> [1] http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf
>
> ------
>
> This patch set adds execveat(2) for x86, and is derived from Meredydd
> Luff's patch from Sept 2012 (https://lkml.org/lkml/2012/9/11/528).
>
> The primary aim of adding an execveat syscall is to allow an
> implementation of fexecve(3) that does not rely on the /proc
> filesystem. The current glibc version of fexecve(3) is implemented
> via /proc, which causes problems in sandboxed or otherwise restricted
> environments.
>
> Given the desire for a /proc-free fexecve() implementation, HPA
> suggested (https://lkml.org/lkml/2006/7/11/556) that an execveat(2)
> syscall would be an appropriate generalization.
>
> Also, having a new syscall means that it can take a flags argument
> without back-compatibility concerns. The current implementation just
> defines the AT_SYMLINK_NOFOLLOW flag, but other flags could be added
> in future -- for example, flags for new namespaces (as suggested at
> https://lkml.org/lkml/2006/7/11/474).
>
> Related history:
> - https://lkml.org/lkml/2006/12/27/123 is an example of someone
> realizing that fexecve() is likely to fail in a chroot environment.
> - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514043 covered
> documenting the /proc requirement of fexecve(3) in its manpage, to
> "prevent other people from wasting their time".
> - https://bugzilla.kernel.org/show_bug.cgi?id=74481 documented that
> it's not possible to fexecve() a file descriptor for a script with
> close-on-exec set (which is possible with the implementation here).
> - https://bugzilla.redhat.com/show_bug.cgi?id=241609 described a
> problem where a process that did setuid() could not fexecve()
> because it no longer had access to /proc/self/fd; this has since
> been fixed.
>
>
> Changes since Meredydd's v3 patch:
> - Added a selftest.
> - Added a man page.
> - Left open_exec() signature untouched to reduce patch impact
> elsewhere (as suggested by Al Viro).
> - Filled in bprm->filename with d_path() into a buffer, to avoid use
> of potentially-ephemeral dentry->d_name.
> - Patch against v3.14 (455c6fdbd21916).
>
>
> David Drysdale (2):
> syscalls,x86: implement execveat() system call
> syscalls,x86: add selftest for execveat(2)
>
> arch/x86/ia32/audit.c | 1 +
> arch/x86/ia32/ia32entry.S | 1 +
> arch/x86/kernel/audit_64.c | 1 +
> arch/x86/kernel/entry_64.S | 28 ++++
> arch/x86/syscalls/syscall_32.tbl | 1 +
> arch/x86/syscalls/syscall_64.tbl | 2 +
> arch/x86/um/sys_call_table_64.c | 1 +
> fs/exec.c | 153 ++++++++++++++++---
> include/linux/compat.h | 3 +
> include/linux/sched.h | 4 +
> include/linux/syscalls.h | 4 +
> include/uapi/asm-generic/unistd.h | 4 +-
> kernel/sys_ni.c | 3 +
> lib/audit.c | 3 +
> tools/testing/selftests/Makefile | 1 +
> tools/testing/selftests/exec/.gitignore | 6 +
> tools/testing/selftests/exec/Makefile | 32 ++++
> tools/testing/selftests/exec/execveat.c | 251 ++++++++++++++++++++++++++++++++
> 18 files changed, 476 insertions(+), 23 deletions(-)
> create mode 100644 tools/testing/selftests/exec/.gitignore
> create mode 100644 tools/testing/selftests/exec/Makefile
> create mode 100644 tools/testing/selftests/exec/execveat.c
>
> --
> 1.9.1.423.g4596e3a
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [PATCHv1 8/8] cgroup: mount cgroupns-root when inside non-init cgroupns
From: Serge E. Hallyn @ 2014-10-17 12:19 UTC (permalink / raw)
To: Aditya Kali
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, luto-kltTT9wpgjJwATOyAt5JVQ,
tj-DgEjT+Ai2ygdnm+yROfE0A, cgroups-u79uwXL29TY76Z2rM5mHXA,
mingo-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1413235430-22944-9-git-send-email-adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Quoting Aditya Kali (adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> This patch enables cgroup mounting inside userns when a process
> as appropriate privileges. The cgroup filesystem mounted is
> rooted at the cgroupns-root. Thus, in a container-setup, only
> the hierarchy under the cgroupns-root is exposed inside the container.
> This allows container management tools to run inside the containers
> without depending on any global state.
> In order to support this, a new kernfs api is added to lookup the
> dentry for the cgroupns-root.
>
> Signed-off-by: Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Acked-by: Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> ---
> fs/kernfs/mount.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/kernfs.h | 2 ++
> kernel/cgroup.c | 47 +++++++++++++++++++++++++++++++++++++++++++++--
> 3 files changed, 95 insertions(+), 2 deletions(-)
>
> diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c
> index f973ae9..e334f45 100644
> --- a/fs/kernfs/mount.c
> +++ b/fs/kernfs/mount.c
> @@ -62,6 +62,54 @@ struct kernfs_root *kernfs_root_from_sb(struct super_block *sb)
> return NULL;
> }
>
> +/**
> + * kernfs_make_root - create new root dentry for the given kernfs_node.
> + * @sb: the kernfs super_block
> + * @kn: kernfs_node for which a dentry is needed
> + *
> + * This can used used by callers which want to mount only a part of the kernfs
> + * as root of the filesystem.
> + */
> +struct dentry *kernfs_obtain_root(struct super_block *sb,
> + struct kernfs_node *kn)
> +{
> + struct dentry *dentry;
> + struct inode *inode;
> +
> + BUG_ON(sb->s_op != &kernfs_sops);
> +
> + /* inode for the given kernfs_node should already exist. */
> + inode = ilookup(sb, kn->ino);
> + if (!inode) {
> + pr_debug("kernfs: could not get inode for '");
> + pr_cont_kernfs_path(kn);
> + pr_cont("'.\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + /* instantiate and link root dentry */
> + dentry = d_obtain_root(inode);
> + if (!dentry) {
> + pr_debug("kernfs: could not get dentry for '");
> + pr_cont_kernfs_path(kn);
> + pr_cont("'.\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + /* If this is a new dentry, set it up. We need kernfs_mutex because this
> + * may be called by callers other than kernfs_fill_super. */
> + mutex_lock(&kernfs_mutex);
> + if (!dentry->d_fsdata) {
> + kernfs_get(kn);
> + dentry->d_fsdata = kn;
> + } else {
> + WARN_ON(dentry->d_fsdata != kn);
> + }
> + mutex_unlock(&kernfs_mutex);
> +
> + return dentry;
> +}
> +
> static int kernfs_fill_super(struct super_block *sb, unsigned long magic)
> {
> struct kernfs_super_info *info = kernfs_info(sb);
> diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
> index 3c2be75..b9538e0 100644
> --- a/include/linux/kernfs.h
> +++ b/include/linux/kernfs.h
> @@ -274,6 +274,8 @@ void kernfs_put(struct kernfs_node *kn);
> struct kernfs_node *kernfs_node_from_dentry(struct dentry *dentry);
> struct kernfs_root *kernfs_root_from_sb(struct super_block *sb);
>
> +struct dentry *kernfs_obtain_root(struct super_block *sb,
> + struct kernfs_node *kn);
> struct kernfs_root *kernfs_create_root(struct kernfs_syscall_ops *scops,
> unsigned int flags, void *priv);
> void kernfs_destroy_root(struct kernfs_root *root);
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 2fc0dfa..ef27dc4 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -1302,6 +1302,13 @@ static int parse_cgroupfs_options(char *data, struct cgroup_sb_opts *opts)
>
> memset(opts, 0, sizeof(*opts));
>
> + /* Implicitly add CGRP_ROOT_SANE_BEHAVIOR if inside a non-init cgroup
> + * namespace.
> + */
> + if (current->nsproxy->cgroup_ns != &init_cgroup_ns) {
> + opts->flags |= CGRP_ROOT_SANE_BEHAVIOR;
> + }
> +
> while ((token = strsep(&o, ",")) != NULL) {
> nr_opts++;
>
> @@ -1391,7 +1398,7 @@ static int parse_cgroupfs_options(char *data, struct cgroup_sb_opts *opts)
>
> if (opts->flags & CGRP_ROOT_SANE_BEHAVIOR) {
> pr_warn("sane_behavior: this is still under development and its behaviors will change, proceed at your own risk\n");
> - if (nr_opts != 1) {
> + if (nr_opts > 1) {
> pr_err("sane_behavior: no other mount options allowed\n");
> return -EINVAL;
> }
> @@ -1581,6 +1588,15 @@ static void init_cgroup_root(struct cgroup_root *root,
> set_bit(CGRP_CPUSET_CLONE_CHILDREN, &root->cgrp.flags);
> }
>
> +struct dentry *cgroupns_get_root(struct super_block *sb,
> + struct cgroup_namespace *ns)
> +{
> + struct dentry *nsdentry;
> +
> + nsdentry = kernfs_obtain_root(sb, ns->root_cgrp->kn);
> + return nsdentry;
> +}
> +
> static int cgroup_setup_root(struct cgroup_root *root, unsigned int ss_mask)
> {
> LIST_HEAD(tmp_links);
> @@ -1684,6 +1700,14 @@ static struct dentry *cgroup_mount(struct file_system_type *fs_type,
> int ret;
> int i;
> bool new_sb;
> + struct cgroup_namespace *ns =
> + get_cgroup_ns(current->nsproxy->cgroup_ns);
> +
> + /* Check if the caller has permission to mount. */
> + if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN)) {
> + put_cgroup_ns(ns);
> + return ERR_PTR(-EPERM);
> + }
>
> /*
> * The first time anyone tries to mount a cgroup, enable the list
> @@ -1816,11 +1840,28 @@ out_free:
> kfree(opts.release_agent);
> kfree(opts.name);
>
> - if (ret)
> + if (ret) {
> + put_cgroup_ns(ns);
> return ERR_PTR(ret);
> + }
>
> dentry = kernfs_mount(fs_type, flags, root->kf_root,
> CGROUP_SUPER_MAGIC, &new_sb);
> +
> + if (!IS_ERR(dentry)) {
> + /* If this mount is for a non-init cgroup namespace, then
> + * Instead of root's dentry, we return the dentry specific to
> + * the cgroupns->root_cgrp.
> + */
> + if (ns != &init_cgroup_ns) {
> + struct dentry *nsdentry;
> +
> + nsdentry = cgroupns_get_root(dentry->d_sb, ns);
> + dput(dentry);
> + dentry = nsdentry;
> + }
> + }
> +
> if (IS_ERR(dentry) || !new_sb)
> cgroup_put(&root->cgrp);
>
> @@ -1833,6 +1874,7 @@ out_free:
> deactivate_super(pinned_sb);
> }
>
> + put_cgroup_ns(ns);
> return dentry;
> }
>
> @@ -1861,6 +1903,7 @@ static struct file_system_type cgroup_fs_type = {
> .name = "cgroup",
> .mount = cgroup_mount,
> .kill_sb = cgroup_kill_sb,
> + .fs_flags = FS_USERNS_MOUNT,
> };
>
> static struct kobject *cgroup_kobj;
> --
> 2.1.0.rc2.206.gedb03e5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
From: Serge E. Hallyn @ 2014-10-17 9:52 UTC (permalink / raw)
To: Aditya Kali
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, luto-kltTT9wpgjJwATOyAt5JVQ,
tj-DgEjT+Ai2ygdnm+yROfE0A, cgroups-u79uwXL29TY76Z2rM5mHXA,
mingo-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1413235430-22944-8-git-send-email-adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Quoting Aditya Kali (adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> setns on a cgroup namespace is allowed only if
> * task has CAP_SYS_ADMIN in its current user-namespace and
> over the user-namespace associated with target cgroupns.
> * task's current cgroup is descendent of the target cgroupns-root
> cgroup.
> * target cgroupns-root is same as or deeper than task's current
> cgroupns-root. This is so that the task cannot escape out of its
> cgroupns-root. This also ensures that setns() only makes the task
> get restricted to a deeper cgroup hierarchy.
>
> Signed-off-by: Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Acked-by: Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Below you allow setns to your own cgroupns. I think that's fine,
but since you're not doing an explicit cgroup change anyway should
you just return 0 at top in that case to save some cpu time?
> ---
> kernel/cgroup_namespace.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cgroup_namespace.c b/kernel/cgroup_namespace.c
> index c16604f..c612946 100644
> --- a/kernel/cgroup_namespace.c
> +++ b/kernel/cgroup_namespace.c
> @@ -80,8 +80,48 @@ err_out:
>
> static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
> {
> - pr_info("setns not supported for cgroup namespace");
> - return -EINVAL;
> + struct cgroup_namespace *cgroup_ns = ns;
> + struct task_struct *task = current;
> + struct cgroup *cgrp = NULL;
> + int err = 0;
> +
> + if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN) ||
> + !ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + /* Prevent cgroup changes for this task. */
> + threadgroup_lock(task);
> +
> + cgrp = get_task_cgroup(task);
> +
> + err = -EINVAL;
> + if (!cgroup_on_dfl(cgrp))
> + goto out_unlock;
> +
> + /* Allow switch only if the task's current cgroup is descendant of the
> + * target cgroup_ns->root_cgrp.
> + */
> + if (!cgroup_is_descendant(cgrp, cgroup_ns->root_cgrp))
> + goto out_unlock;
> +
> + /* Only allow setns to a cgroupns root-ed deeper than task's current
> + * cgroupns-root. This will make sure that tasks cannot escape their
> + * cgroupns by attaching to parent cgroupns.
> + */
> + if (!cgroup_is_descendant(cgroup_ns->root_cgrp,
> + task_cgroupns_root(task)))
> + goto out_unlock;
> +
> + err = 0;
> + get_cgroup_ns(cgroup_ns);
> + put_cgroup_ns(nsproxy->cgroup_ns);
> + nsproxy->cgroup_ns = cgroup_ns;
> +
> +out_unlock:
> + threadgroup_unlock(current);
> + if (cgrp)
> + cgroup_put(cgrp);
> + return err;
> }
>
> static void *cgroupns_get(struct task_struct *task)
> --
> 2.1.0.rc2.206.gedb03e5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
From: Christoph Hellwig @ 2014-10-17 9:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Anup Patel, linux-api, linux-kernel, Arve Hj?nnev?g,
Santosh Shilimkar, Rebecca Schultz Zavin, John Stultz,
Sumit Semwal, Christoffer Dall
In-Reply-To: <20141016124741.GA3832@kroah.com>
On Thu, Oct 16, 2014 at 02:47:41PM +0200, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> The Android binder code has been "stable" for many years now. No matter
> what comes in the future, we are going to have to support this API, so
> might as well move it to the "real" part of the kernel as there's no
> real work that needs to be done to the existing code.
NAK. It's complete rubbish and does things to the FD code that it
really shouldn't. Android needs to completely redo the interface, and
there's been absolutely no work towards that.
This is exactly the sort of attitude I feared about when you started the
whole staging concepts, and it sounds like a good reason to disband
staging entirely, given that it's been mostly useless except for
boasting peoples commit statistics.
^ permalink raw reply
* Re: [PATCHv1 6/8] cgroup: restrict cgroup operations within task's cgroupns
From: Serge E. Hallyn @ 2014-10-17 9:28 UTC (permalink / raw)
To: Aditya Kali
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, luto-kltTT9wpgjJwATOyAt5JVQ,
tj-DgEjT+Ai2ygdnm+yROfE0A, cgroups-u79uwXL29TY76Z2rM5mHXA,
mingo-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1413235430-22944-7-git-send-email-adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Quoting Aditya Kali (adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> Restrict following operations within the calling tasks:
> * cgroup_mkdir & cgroup_rmdir
> * cgroup_attach_task
> * writes to cgroup files outside of task's cgroupns-root
>
> Also, read of /proc/<pid>/cgroup file is now restricted only
> to tasks under same cgroupns-root. If a task tries to look
> at cgroup of another task outside of its cgroupns-root, then
> it won't be able to see anything for the default hierarchy.
> This is same as if the cgroups are not mounted.
>
> Signed-off-by: Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
So this is a bit different from some other namespaces - if I
have an open fd to a file, then setns into a mntns where that
file is not addressable, I can still use the file.
I guess not allowing attach to a cgroup outside our ns is a
good failsafe as we'll otherwise risk falling off a cliff in
some code, but I'm not sure the cgroup_file_write/mkdir/rmdir
restrictions are needed. (And really I can fchdir to a
directory not in my ns, so the cgroup-attach restriction is
any more justified).
Still I'm not strictly opposed ot this, so
Acked-by: Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
just wanted to point this out.
> ---
> kernel/cgroup.c | 34 +++++++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index f8099b4..2fc0dfa 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2318,6 +2318,12 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
> struct task_struct *task;
> int ret;
>
> + /* Only allow changing cgroups accessible within task's cgroup
> + * namespace. i.e. 'dst_cgrp' should be a descendant of task's
> + * cgroupns->root_cgrp. */
> + if (!cgroup_is_descendant(dst_cgrp, task_cgroupns_root(leader)))
> + return -EPERM;
> +
> /* look up all src csets */
> down_read(&css_set_rwsem);
> rcu_read_lock();
> @@ -2882,6 +2888,10 @@ static ssize_t cgroup_file_write(struct kernfs_open_file *of, char *buf,
> struct cgroup_subsys_state *css;
> int ret;
>
> + /* Reject writes to cgroup files outside of task's cgroupns-root. */
> + if (!cgroup_is_descendant(cgrp, task_cgroupns_root(current)))
> + return -EINVAL;
> +
> if (cft->write)
> return cft->write(of, buf, nbytes, off);
>
> @@ -4560,6 +4570,13 @@ static int cgroup_mkdir(struct kernfs_node *parent_kn, const char *name,
> parent = cgroup_kn_lock_live(parent_kn);
> if (!parent)
> return -ENODEV;
> +
> + /* Allow mkdir only within process's cgroup namespace root. */
> + if (!cgroup_is_descendant(parent, task_cgroupns_root(current))) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> +
> root = parent->root;
>
> /* allocate the cgroup and its ID, 0 is reserved for the root */
> @@ -4822,6 +4839,13 @@ static int cgroup_rmdir(struct kernfs_node *kn)
> if (!cgrp)
> return 0;
>
> + /* Allow rmdir only within process's cgroup namespace root.
> + * The process can't delete its own root anyways. */
> + if (!cgroup_is_descendant(cgrp, task_cgroupns_root(current))) {
> + cgroup_kn_unlock(kn);
> + return -EPERM;
> + }
> +
> ret = cgroup_destroy_locked(cgrp);
>
> cgroup_kn_unlock(kn);
> @@ -5051,6 +5075,15 @@ int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns,
> if (root == &cgrp_dfl_root && !cgrp_dfl_root_visible)
> continue;
>
> + cgrp = task_cgroup_from_root(tsk, root);
> +
> + /* The cgroup path on default hierarchy is shown only if it
> + * falls under current task's cgroupns-root.
> + */
> + if (root == &cgrp_dfl_root &&
> + !cgroup_is_descendant(cgrp, task_cgroupns_root(current)))
> + continue;
> +
> seq_printf(m, "%d:", root->hierarchy_id);
> for_each_subsys(ss, ssid)
> if (root->subsys_mask & (1 << ssid))
> @@ -5059,7 +5092,6 @@ int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns,
> seq_printf(m, "%sname=%s", count ? "," : "",
> root->name);
> seq_putc(m, ':');
> - cgrp = task_cgroup_from_root(tsk, root);
> path = cgroup_path(cgrp, buf, PATH_MAX);
> if (!path) {
> retval = -ENAMETOOLONG;
> --
> 2.1.0.rc2.206.gedb03e5
>
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
From: Dan Carpenter @ 2014-10-17 9:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, Anup Patel, linux-api, linux-kernel,
Arve Hjønnevåg, John Stultz, Rebecca Schultz Zavin,
Santosh Shilimkar, Sumit Semwal, Christoffer Dall
In-Reply-To: <20141016124741.GA3832@kroah.com>
The code isn't very beautiful and there are lots of details wrong like
the error codes.
Al had some critical things to say about it but it looks like most of
those issues have been fixed.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] Documentation/ABI/testing/sysfs-ibft: fix a typo
From: WANG Chao @ 2014-10-17 8:47 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA; +Cc: open list:ABI/API
Correct a sentence in Documentation/ABI/testing/sysfs-ibft.
Signed-off-by: WANG Chao <chaowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Documentation/ABI/testing/sysfs-ibft | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-ibft b/Documentation/ABI/testing/sysfs-ibft
index c2b7d11..cac3930 100644
--- a/Documentation/ABI/testing/sysfs-ibft
+++ b/Documentation/ABI/testing/sysfs-ibft
@@ -20,4 +20,4 @@ Date: November 2007
Contact: Konrad Rzeszutek <ketuzsezr-Gq0aWv8utHQdnm+yROfE0A@public.gmane.org>
Description: The /sys/firmware/ibft/ethernetX directory will contain
files that expose the iSCSI Boot Firmware Table NIC data.
- This can this can the IP address, MAC, and gateway of the NIC.
+ Usually this contains the IP address, MAC, and gateway of the NIC.
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v11 0/3] Add drm driver for Rockchip Socs
From: Mark yao @ 2014-10-17 8:42 UTC (permalink / raw)
To: Heiko Stübner
Cc: Dave Airlie, Boris BREZILLON, Rob Clark, Daniel Vetter,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Randy Dunlap, Grant Likely, Greg Kroah-Hartman, John Stultz,
Rom Lemarchand, devicetree@vger.kernel.org, linux-doc, LKML,
dri-devel, linux-api, linux-rockchip, dianders,
Stéphane Marchesin, dbehr
In-Reply-To: <4044646.m0RgIJvLdJ@phil>
On 2014年10月17日 16:25, Heiko Stübner wrote:
> Am Freitag, 17. Oktober 2014, 16:16:01 schrieb Mark yao:
>> On 2014年10月17日 14:24, Heiko Stübner wrote:
>>> Hi Mark,
>>>
>>> Am Freitag, 17. Oktober 2014, 12:22:53 schrieb Mark yao:
>>>> On 2014年10月17日 08:46, Dave Airlie wrote:
>>>>> On 17 October 2014 10:40, Mark yao <mark.yao@rock-chips.com> wrote:
>>>>>> Hi
>>>>>> I think Rockchip drm driver is ready now, can it land?
>>>>> I probably want to wait until -rc1 though I suppose since its a new
>>>>> driver and self contained we might be able to see if Linus is
>>>>> interested in squeezing it in.
>>>>>
>>>>> Can you send me a git pull request for it against drm-next or even 3.17.
>>>>>
>>>>> Dave.
>>>> Hi, Dave
>>>>
>>>> the git pull request:
>>>> The following changes since commit
> 4db36870b92cdf5a79615aeabc68efc97df13918:
>>> I think this needs a fix. Your commit 4db36870b is the pending iommu
>>> driver. Which isn't part of neither the mainline kernel nor the drm tree
>>> Dave meant.
>>>
>>> What Dave meant was to base your patches on top of his "drm-next" branch
>>> or
>>> the raw 3.17 release.
>>>
>>> So either base the branch on drm-next from
>>>
>>> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
>>>
>>> or the 3.17 release tag from Linus Torvalds. Apply your patches on top and
>>> create pull from there.
>>>
>>> I've just checked ... your drm patches apply cleanly against 3.17, so your
>>> branch to be pulled should probably look something like
>>>
>>> https://github.com/mmind/linux-rockchip/commits/tmp/drmtest
>>>
>>> Heiko
>> Hi Heiko
>> thanks for you check.
>>
>> Hi Dave
>> I have reupload a branch cleanly against 3.17:
> sorry, but I think this might need another round.
>
> Your current base commit 0429fbc0bdc2 is already part of the current 3.18
> merge window - which Dave won't have in his tree I guess. The commit you
> should base your patches on is bfe01a5ba249 - the 3.17 release.
>
> Simply do a
> git checkout v3.17
> git checkout -b drmupstream
>
> apply your patches and send the pull request with v3.17 as base.
>
>
> Heiko
>
I think that would be ok:
The following changes since commit bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9:
Linux 3.17 (2014-10-05 12:23:04 -0700)
are available in the git repository at:
https://github.com/markyzq/kernel-drm-rockchip.git drmrockchip
for you to fetch changes up to 45bb5f4e7e82b30e9e7069c73441413680c9a59f:
dt-bindings: video: Add documentation for rockchip vop (2014-10-17
16:39:31 +0800)
----------------------------------------------------------------
Mark yao (3):
drm: rockchip: Add basic drm driver
dt-bindings: video: Add for rockchip display subsytem
dt-bindings: video: Add documentation for rockchip vop
.../devicetree/bindings/video/rockchip-drm.txt | 19 +
.../devicetree/bindings/video/rockchip-vop.txt | 58 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/rockchip/Kconfig | 17 +
drivers/gpu/drm/rockchip/Makefile | 8 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 449 ++++++
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 54 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++
drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 +
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 +
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 293 ++++
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 54 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1427
++++++++++++++++++++
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 +++
16 files changed, 3036 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/rockchip-drm.txt
create mode 100644
Documentation/devicetree/bindings/video/rockchip-vop.txt
create mode 100644 drivers/gpu/drm/rockchip/Kconfig
create mode 100644 drivers/gpu/drm/rockchip/Makefile
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h
^ permalink raw reply
* Re: [PATCH v11 0/3] Add drm driver for Rockchip Socs
From: Heiko Stübner @ 2014-10-17 8:25 UTC (permalink / raw)
To: Mark yao
Cc: Dave Airlie, Boris BREZILLON, Rob Clark, Daniel Vetter,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Randy Dunlap, Grant Likely, Greg Kroah-Hartman, John Stultz,
Rom Lemarchand, devicetree@vger.kernel.org, linux-doc, LKML,
dri-devel, linux-api, linux-rockchip, dianders,
Stéphane Marchesin, dbehr
In-Reply-To: <5440D041.9020300@rock-chips.com>
Am Freitag, 17. Oktober 2014, 16:16:01 schrieb Mark yao:
> On 2014年10月17日 14:24, Heiko Stübner wrote:
> > Hi Mark,
> >
> > Am Freitag, 17. Oktober 2014, 12:22:53 schrieb Mark yao:
> >> On 2014年10月17日 08:46, Dave Airlie wrote:
> >>> On 17 October 2014 10:40, Mark yao <mark.yao@rock-chips.com> wrote:
> >>>> Hi
> >>>> I think Rockchip drm driver is ready now, can it land?
> >>>
> >>> I probably want to wait until -rc1 though I suppose since its a new
> >>> driver and self contained we might be able to see if Linus is
> >>> interested in squeezing it in.
> >>>
> >>> Can you send me a git pull request for it against drm-next or even 3.17.
> >>>
> >>> Dave.
> >>
> >> Hi, Dave
> >>
> >> the git pull request:
> >> The following changes since commit
4db36870b92cdf5a79615aeabc68efc97df13918:
> > I think this needs a fix. Your commit 4db36870b is the pending iommu
> > driver. Which isn't part of neither the mainline kernel nor the drm tree
> > Dave meant.
> >
> > What Dave meant was to base your patches on top of his "drm-next" branch
> > or
> > the raw 3.17 release.
> >
> > So either base the branch on drm-next from
> >
> > http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
> >
> > or the 3.17 release tag from Linus Torvalds. Apply your patches on top and
> > create pull from there.
> >
> > I've just checked ... your drm patches apply cleanly against 3.17, so your
> > branch to be pulled should probably look something like
> >
> > https://github.com/mmind/linux-rockchip/commits/tmp/drmtest
> >
> > Heiko
>
> Hi Heiko
> thanks for you check.
>
> Hi Dave
> I have reupload a branch cleanly against 3.17:
sorry, but I think this might need another round.
Your current base commit 0429fbc0bdc2 is already part of the current 3.18
merge window - which Dave won't have in his tree I guess. The commit you
should base your patches on is bfe01a5ba249 - the 3.17 release.
Simply do a
git checkout v3.17
git checkout -b drmupstream
apply your patches and send the pull request with v3.17 as base.
Heiko
>
> The following changes since commit 0429fbc0bdc297d64188483ba029a23773ae07b0:
>
> Merge branch 'for-3.18-consistent-ops' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu (2014-10-15
> 07:48:18 +0200)
>
> are available in the git repository at:
>
>
> https://github.com/markyzq/kernel-drm-rockchip.git drmupstream
>
> for you to fetch changes up to f92714d79376a4168ea3ae0b13ccd0b90a640f35:
>
> dt-bindings: video: Add documentation for rockchip vop (2014-10-17
> 16:09:23 +0800)
>
> ----------------------------------------------------------------
> Mark yao (3):
> drm: rockchip: Add basic drm driver
> dt-bindings: video: Add for rockchip display subsytem
> dt-bindings: video: Add documentation for rockchip vop
>
> .../devicetree/bindings/video/rockchip-drm.txt | 19 +
> .../devicetree/bindings/video/rockchip-vop.txt | 58 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/rockchip/Kconfig | 17 +
> drivers/gpu/drm/rockchip/Makefile | 8 +
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 449 ++++++
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 54 +
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++
> drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 +
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 +
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 293 ++++
> drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 54 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1427
> ++++++++++++++++++++
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 +++
> 16 files changed, 3036 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/video/rockchip-drm.txt
> create mode 100644
> Documentation/devicetree/bindings/video/rockchip-vop.txt
> create mode 100644 drivers/gpu/drm/rockchip/Kconfig
> create mode 100644 drivers/gpu/drm/rockchip/Makefile
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h
^ permalink raw reply
* Re: [PATCH v11 0/3] Add drm driver for Rockchip Socs
From: Mark yao @ 2014-10-17 8:16 UTC (permalink / raw)
To: Heiko Stübner
Cc: Dave Airlie, Boris BREZILLON, Rob Clark, Daniel Vetter,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Randy Dunlap, Grant Likely, Greg Kroah-Hartman, John Stultz,
Rom Lemarchand, devicetree@vger.kernel.org, linux-doc, LKML,
dri-devel, linux-api, linux-rockchip, dianders,
Stéphane Marchesin, dbehr
In-Reply-To: <282711393.zuCWIeu2Oz@phil>
On 2014年10月17日 14:24, Heiko Stübner wrote:
> Hi Mark,
>
> Am Freitag, 17. Oktober 2014, 12:22:53 schrieb Mark yao:
>> On 2014年10月17日 08:46, Dave Airlie wrote:
>>> On 17 October 2014 10:40, Mark yao <mark.yao@rock-chips.com> wrote:
>>>> Hi
>>>> I think Rockchip drm driver is ready now, can it land?
>>> I probably want to wait until -rc1 though I suppose since its a new
>>> driver and self contained we might be able to see if Linus is
>>> interested in squeezing it in.
>>>
>>> Can you send me a git pull request for it against drm-next or even 3.17.
>>>
>>> Dave.
>> Hi, Dave
>> the git pull request:
>>
>> The following changes since commit 4db36870b92cdf5a79615aeabc68efc97df13918:
> I think this needs a fix. Your commit 4db36870b is the pending iommu driver.
> Which isn't part of neither the mainline kernel nor the drm tree Dave meant.
>
> What Dave meant was to base your patches on top of his "drm-next" branch or
> the raw 3.17 release.
>
> So either base the branch on drm-next from
> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
>
> or the 3.17 release tag from Linus Torvalds. Apply your patches on top and
> create pull from there.
>
> I've just checked ... your drm patches apply cleanly against 3.17, so your
> branch to be pulled should probably look something like
> https://github.com/mmind/linux-rockchip/commits/tmp/drmtest
>
>
> Heiko
>
Hi Heiko
thanks for you check.
Hi Dave
I have reupload a branch cleanly against 3.17:
The following changes since commit 0429fbc0bdc297d64188483ba029a23773ae07b0:
Merge branch 'for-3.18-consistent-ops' of
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu (2014-10-15
07:48:18 +0200)
are available in the git repository at:
https://github.com/markyzq/kernel-drm-rockchip.git drmupstream
for you to fetch changes up to f92714d79376a4168ea3ae0b13ccd0b90a640f35:
dt-bindings: video: Add documentation for rockchip vop (2014-10-17
16:09:23 +0800)
----------------------------------------------------------------
Mark yao (3):
drm: rockchip: Add basic drm driver
dt-bindings: video: Add for rockchip display subsytem
dt-bindings: video: Add documentation for rockchip vop
.../devicetree/bindings/video/rockchip-drm.txt | 19 +
.../devicetree/bindings/video/rockchip-vop.txt | 58 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/rockchip/Kconfig | 17 +
drivers/gpu/drm/rockchip/Makefile | 8 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 449 ++++++
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 54 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++
drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 +
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 +
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 293 ++++
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 54 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1427
++++++++++++++++++++
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 +++
16 files changed, 3036 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/rockchip-drm.txt
create mode 100644
Documentation/devicetree/bindings/video/rockchip-vop.txt
create mode 100644 drivers/gpu/drm/rockchip/Kconfig
create mode 100644 drivers/gpu/drm/rockchip/Makefile
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h
^ permalink raw reply
* Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
From: Greg Kroah-Hartman @ 2014-10-17 8:01 UTC (permalink / raw)
To: John Stultz
Cc: devel, Anup Patel, Linux API, lkml, Arve Hjønnevåg,
Santosh Shilimkar, Rebecca Schultz Zavin, Sumit Semwal,
Christoffer Dall
In-Reply-To: <CALAqxLXDZ4Q_C456o_A-V_LkcY=wpoC30kvNavyVaZRu7uK9fQ@mail.gmail.com>
On Thu, Oct 16, 2014 at 08:25:33PM -0700, John Stultz wrote:
> On Thu, Oct 16, 2014 at 4:12 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Thu, Oct 16, 2014 at 10:09:04AM -0700, John Stultz wrote:
> >> On Thu, Oct 16, 2014 at 5:47 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> >
> >> > The Android binder code has been "stable" for many years now. No matter
> >>
> >> Well, ignoring the ABI break that landed in the last year. :)
> >
> > As no one noticed, it wasn't a "break" :)
> >
> >> > This was discussed in the Android miniconf at the Plumbers conference.
> >> > If anyone has any objections to this, please let me know, otherwise I'm
> >> > queueing this up for 3.19-rc1
> >>
> >> So my main concerns/thoughts here are:
> >>
> >> Who is going to maintain this? Has Arve agreed?
> >
> > Do we really need someone to do more work that has been done on it in
> > the past as an official "maintainer"? I'll be glad to do it, as I doubt
> > it will require any time at all.
>
> Ok. The only caution I have if Arve isn't involved is that we have in
> the past merged cleanup changes that introduced bugs, and it wasn't
> until Arve took at look at the new kernel that these were sorted out
> (see e194fd8a5d8e0a7eeed239a8534460724b62fe2d). So I think if at all
> possible getting his ack on things would be good.
I'll make sure to get his Ack on anything that could possibly cause a
problem.
> But yes, I'm fine with it going in. I'm just a bit surprised at how
> quickly thoughts change here.
Over the past year I've realized that code in staging needs to progress
either out of the kernel due to no need/use, or into the main part of
the kernel as people rely on it. The android code is something that
people rely on, and this code is "stable", so it should be merged into
the main kernel tree.
So yes, this does seem to be a change in the public stance, but it's
something that I have been talking about with people at the zillion
conferences I go to around the world.
> This does raise the question if the same standard could be held to
> ashmem then?
Ah, you beat me to it, I was going to wait to talk to you in person
about this :)
> That's a *much* simpler and easier to maintain chunk of
> code, and is just as isolated, logic wise. And while I think it would
> be ideal if the unpinning feature could be done more generically, if
> volatile ranges really doesn't have a future, then its maybe silly to
> hold ashmem out as well?
Yes, that was the second thing I was going to move, I'll send a patch
for that later today.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v11 0/3] Add drm driver for Rockchip Socs
From: Heiko Stübner @ 2014-10-17 6:24 UTC (permalink / raw)
To: Mark yao
Cc: Dave Airlie, Boris BREZILLON, Rob Clark, Daniel Vetter,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Randy Dunlap, Grant Likely, Greg Kroah-Hartman, John Stultz,
Rom Lemarchand, devicetree@vger.kernel.org, linux-doc, LKML,
dri-devel, linux-api, linux-rockchip, dianders,
Stéphane Marchesin, dbehr
In-Reply-To: <5440999D.5010601@rock-chips.com>
Hi Mark,
Am Freitag, 17. Oktober 2014, 12:22:53 schrieb Mark yao:
> On 2014年10月17日 08:46, Dave Airlie wrote:
> > On 17 October 2014 10:40, Mark yao <mark.yao@rock-chips.com> wrote:
> >> Hi
> >> I think Rockchip drm driver is ready now, can it land?
> >
> > I probably want to wait until -rc1 though I suppose since its a new
> > driver and self contained we might be able to see if Linus is
> > interested in squeezing it in.
> >
> > Can you send me a git pull request for it against drm-next or even 3.17.
> >
> > Dave.
>
> Hi, Dave
> the git pull request:
>
> The following changes since commit 4db36870b92cdf5a79615aeabc68efc97df13918:
I think this needs a fix. Your commit 4db36870b is the pending iommu driver.
Which isn't part of neither the mainline kernel nor the drm tree Dave meant.
What Dave meant was to base your patches on top of his "drm-next" branch or
the raw 3.17 release.
So either base the branch on drm-next from
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
or the 3.17 release tag from Linus Torvalds. Apply your patches on top and
create pull from there.
I've just checked ... your drm patches apply cleanly against 3.17, so your
branch to be pulled should probably look something like
https://github.com/mmind/linux-rockchip/commits/tmp/drmtest
Heiko
>
> FROMLIST: iommu/rockchip: rk3288 iommu driver (2014-10-17 10:26:18 +0800)
>
> are available in the git repository at:
>
> https://github.com/markyzq/kernel-drm-rockchip.git mydrm
>
> for you to fetch changes up to 0db2be88bea08ab8afe5e3d13f8a2c9e637a9514:
>
> dt-bindings: video: Add documentation for rockchip vop (2014-10-17
> 10:27:15 +0800)
>
> ----------------------------------------------------------------
> Mark yao (3):
> drm: rockchip: Add basic drm driver
> dt-bindings: video: Add for rockchip display subsytem
> dt-bindings: video: Add documentation for rockchip vop
>
> .../devicetree/bindings/video/rockchip-drm.txt | 19 +
> .../devicetree/bindings/video/rockchip-vop.txt | 58 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/rockchip/Kconfig | 17 +
> drivers/gpu/drm/rockchip/Makefile | 8 +
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 449 ++++++
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 54 +
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++
> drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 +
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 +
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 293 ++++
> drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 54 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1427
> ++++++++++++++++++++
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 +++
> 16 files changed, 3036 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/video/rockchip-drm.txt
> create mode 100644
> Documentation/devicetree/bindings/video/rockchip-vop.txt
> create mode 100644 drivers/gpu/drm/rockchip/Kconfig
> create mode 100644 drivers/gpu/drm/rockchip/Makefile
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h
^ permalink raw reply
* Re: [PATCH net-next RFC 1/3] virtio: support for urgent descriptors
From: Jason Wang @ 2014-10-17 5:23 UTC (permalink / raw)
To: Rusty Russell, mst, virtualization, netdev, linux-kernel; +Cc: linux-api, kvm
In-Reply-To: <877g01c2ml.fsf@rustcorp.com.au>
On 10/15/2014 01:40 PM, Rusty Russell wrote:
> Jason Wang <jasowang@redhat.com> writes:
>> Below should be useful for some experiments Jason is doing.
>> I thought I'd send it out for early review/feedback.
>>
>> event idx feature allows us to defer interrupts until
>> a specific # of descriptors were used.
>> Sometimes it might be useful to get an interrupt after
>> a specific descriptor, regardless.
>> This adds a descriptor flag for this, and an API
>> to create an urgent output descriptor.
>> This is still an RFC:
>> we'll need a feature bit for drivers to detect this,
>> but we've run out of feature bits for virtio 0.X.
>> For experimentation purposes, drivers can assume
>> this is set, or add a driver-specific feature bit.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> The new VRING_DESC_F_URGENT bit is theoretically nicer, but for
> networking (which tends to take packets in order) couldn't we just set
> the event counter to give us a tx interrupt at the packet we want?
>
> Cheers,
> Rusty.
Yes, we could. Recent RFC of enabling tx interrupt use this.
^ permalink raw reply
* Re: [PATCH v11 0/3] Add drm driver for Rockchip Socs
From: Mark yao @ 2014-10-17 4:22 UTC (permalink / raw)
To: Dave Airlie
Cc: heiko, Boris BREZILLON, Rob Clark, Daniel Vetter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Randy Dunlap,
Grant Likely, Greg Kroah-Hartman, John Stultz, Rom Lemarchand,
devicetree@vger.kernel.org, linux-doc, LKML, dri-devel, linux-api,
linux-rockchip, dianders, Stéphane Marchesin, dbehr
In-Reply-To: <CAPM=9twVrmni_BRV_9-QLk+JUbcgXEjAM0g-tYH6su8=sDQ35g@mail.gmail.com>
On 2014年10月17日 08:46, Dave Airlie wrote:
> On 17 October 2014 10:40, Mark yao <mark.yao@rock-chips.com> wrote:
>> Hi
>> I think Rockchip drm driver is ready now, can it land?
> I probably want to wait until -rc1 though I suppose since its a new
> driver and self contained we might be able to see if Linus is
> interested in squeezing it in.
>
> Can you send me a git pull request for it against drm-next or even 3.17.
>
> Dave.
Hi, Dave
the git pull request:
The following changes since commit 4db36870b92cdf5a79615aeabc68efc97df13918:
FROMLIST: iommu/rockchip: rk3288 iommu driver (2014-10-17 10:26:18 +0800)
are available in the git repository at:
https://github.com/markyzq/kernel-drm-rockchip.git mydrm
for you to fetch changes up to 0db2be88bea08ab8afe5e3d13f8a2c9e637a9514:
dt-bindings: video: Add documentation for rockchip vop (2014-10-17
10:27:15 +0800)
----------------------------------------------------------------
Mark yao (3):
drm: rockchip: Add basic drm driver
dt-bindings: video: Add for rockchip display subsytem
dt-bindings: video: Add documentation for rockchip vop
.../devicetree/bindings/video/rockchip-drm.txt | 19 +
.../devicetree/bindings/video/rockchip-vop.txt | 58 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/rockchip/Kconfig | 17 +
drivers/gpu/drm/rockchip/Makefile | 8 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 449 ++++++
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 54 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++
drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 +
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 +
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 293 ++++
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 54 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1427
++++++++++++++++++++
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 +++
16 files changed, 3036 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/rockchip-drm.txt
create mode 100644
Documentation/devicetree/bindings/video/rockchip-vop.txt
create mode 100644 drivers/gpu/drm/rockchip/Kconfig
create mode 100644 drivers/gpu/drm/rockchip/Makefile
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h
^ permalink raw reply
* Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
From: John Stultz @ 2014-10-17 3:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: lkml, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Linux API,
Santosh Shilimkar, Arve Hjønnevåg, Sumit Semwal,
Rebecca Schultz Zavin, Christoffer Dall, Anup Patel
In-Reply-To: <20141016231221.GA13592-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Thu, Oct 16, 2014 at 4:12 PM, Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Thu, Oct 16, 2014 at 10:09:04AM -0700, John Stultz wrote:
>> On Thu, Oct 16, 2014 at 5:47 AM, Greg Kroah-Hartman
>> <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
>> > From: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
>> >
>> > The Android binder code has been "stable" for many years now. No matter
>>
>> Well, ignoring the ABI break that landed in the last year. :)
>
> As no one noticed, it wasn't a "break" :)
>
>> > This was discussed in the Android miniconf at the Plumbers conference.
>> > If anyone has any objections to this, please let me know, otherwise I'm
>> > queueing this up for 3.19-rc1
>>
>> So my main concerns/thoughts here are:
>>
>> Who is going to maintain this? Has Arve agreed?
>
> Do we really need someone to do more work that has been done on it in
> the past as an official "maintainer"? I'll be glad to do it, as I doubt
> it will require any time at all.
Ok. The only caution I have if Arve isn't involved is that we have in
the past merged cleanup changes that introduced bugs, and it wasn't
until Arve took at look at the new kernel that these were sorted out
(see e194fd8a5d8e0a7eeed239a8534460724b62fe2d). So I think if at all
possible getting his ack on things would be good.
>> Are the Android guys comfortable with the ABI stability rules they'll
>> now face?
>
> Just because something is in staging, doesn't mean you don't have to
> follow the same ABI stability rules as the rest of the kernel. If a
> change had happened to this code that broke userspace in the past, I
> would have reverted it. So this should not be anything different from
> what has been happening inthe past.
>
> And the Android developers said they were happy to see this code move
> into the "real" part of the kernel.
Alright then.
>> Currently in the android space no one but libbinder should use the
>> kernel interface.
>
> That is correct. If you do that, you deserve all of the pain and
> suffering and rooted machines you will get.
You reference this issue quite a bit, and I have a handwavy sense of
the problem, but do you have a more detailed link to the specific
issue here?
>> Can we enforce that no one use this interface out-side of android (To
>> ensure its one of those "if the abi breaks and no one notices..." edge
>> cases)?
>
> This is the kernel, we can not dictate "use", that's the good part of
> the GPLv2 :)
>
> Again, as no one has done this before, I strongly doubt it will happen
> in the future.
Well, the longer something is in the kernel, the more likely someone
will depend on it.
>> I'm still hopeful that a libbinder over kdbus will eventually pan out.
>> I still see having two core IPC mechanisms (even if the use cases are
>> different in style) as a negative, and I worry this might reduce
>> motivation to unify things at the lower level. Granted, such work can
>> still continue, but the incentives do change.
>
> Yes, things are going to change in the future, there is work happening
> here, and there was a presentation at Plumbers about what is going to be
> coming.
>
> But all of the changes will be in new code. Be it kdbus, or something
> else if that doesn't work out. This existing binder.c file will not be
> changing at all. This existing ABI, and codebase, is something that we
> have to maintain forever for those millions of devices out there in the
> real world today. So as there really is nothing left to do on it, it
> deserves to be in the main part of the kernel source tree.
Well, realistically, those millions of devices out there will almost
*never* get a kernel version bump
But yes, I'm fine with it going in. I'm just a bit surprised at how
quickly thoughts change here.
This does raise the question if the same standard could be held to
ashmem then? That's a *much* simpler and easier to maintain chunk of
code, and is just as isolated, logic wise. And while I think it would
be ideal if the unpinning feature could be done more generically, if
volatile ranges really doesn't have a future, then its maybe silly to
hold ashmem out as well?
thanks
-john
^ permalink raw reply
* Re: [PATCH v11 0/3] Add drm driver for Rockchip Socs
From: Dave Airlie @ 2014-10-17 0:46 UTC (permalink / raw)
To: Mark yao
Cc: heiko-4mtYJXux2i+zQB+pC5nmwQ, Boris BREZILLON, Rob Clark,
Daniel Vetter, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Randy Dunlap, Grant Likely,
Greg Kroah-Hartman, John Stultz, Rom Lemarchand,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA, LKML, dri-devel,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dianders-F7+t8E8rja9g9hUCZPvPmw, Stéphane Marchesin,
dbehr-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <5440658D.6020504-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On 17 October 2014 10:40, Mark yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> Hi
> I think Rockchip drm driver is ready now, can it land?
I probably want to wait until -rc1 though I suppose since its a new
driver and self contained we might be able to see if Linus is
interested in squeezing it in.
Can you send me a git pull request for it against drm-next or even 3.17.
Dave.
^ permalink raw reply
* Re: [PATCH v11 0/3] Add drm driver for Rockchip Socs
From: Mark yao @ 2014-10-17 0:40 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ, Boris BREZILLON, David Airlie,
Rob Clark, Daniel Vetter, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Randy Dunlap, Grant Likely,
Greg Kroah-Hartman, John Stultz, Rom Lemarchand
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dianders-F7+t8E8rja9g9hUCZPvPmw, marcheu-F7+t8E8rja9g9hUCZPvPmw,
dbehr-F7+t8E8rja9g9hUCZPvPmw, olof-nZhT3qVonbNeoWH0uzbU5w,
djkurtz-F7+t8E8rja9g9hUCZPvPmw, xjq-TNX95d0MmH7DzftRWevZcw,
kfx-TNX95d0MmH7DzftRWevZcw, cym-TNX95d0MmH7DzftRWevZcw,
cf-TNX95d0MmH7DzftRWevZcw, zyw-TNX95d0MmH7DzftRWevZcw,
xxm-TNX95d0MmH7DzftRWevZcw, huangtao-TNX95d0MmH7DzftRWevZcw,
kever.yang-TNX95d0MmH7DzftRWevZcw, yxj-TNX95d0MmH7DzftRWevZcw,
wxt-TNX95d0MmH7DzftRWevZcw, xw-TNX95d0MmH7DzftRWevZcw, Mark Yao
In-Reply-To: <1412763781-31533-1-git-send-email-mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi
I think Rockchip drm driver is ready now, can it land?
Thanks.
On 2014年10月08日 18:23, Mark Yao wrote:
> This a series of patches is a DRM Driver for Rockchip Socs, add support
> for vop devices. Future patches will add additional encoders/connectors,
> such as eDP, HDMI.
>
> The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
> the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar
> Vop devices. Vop devices support iommu mapping, we use dma-mapping API with
> ARM_DMA_USE_IOMMU.
>
> Changes in v2:
> - add DRM master device node to list all display nodes that comprise
> the graphics subsystem.
> - use the component framework to defer main drm driver probe
> until all VOP devices have been probed.
> - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
> master device and each vop device can shared the drm dma mapping.
> - use drm_crtc_init_with_planes and drm_universal_plane_init.
> - remove unnecessary middle layers.
> - add cursor set, move funcs to rockchip drm crtc.
> - add vop reset.
>
> Changes in v3:
> - change "crtc->fb" to "crtc->primary-fb"
> Adviced by Daniel Vetter
> - init cursor plane with universal api, remove unnecessary cursor set,move
>
> Changes in v4:
> Adviced by David Herrmann
> - remove drm_platform_*() usage, use register drm device directly.
> Adviced by Rob Clark
> - remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset
>
> Changes in v5:
> Adviced by Arnd Bergmann
> - doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
> - fix some incorrect dependencies.
> Adviced by Boris BREZILLON
> - fix some mistake and bugs.
> Adviced by Daniel Vetter
> - drop all special ioctl and use generic kms ioctl instead.
> Adviced by Rob Clark
> - use unlocked api for drm_fb_helper_restore_fbdev_mode.
> - remove unused rockchip_gem_prime_import_sg_table.
>
> Changes in v6:
> - set gem buffer pitch 64 bytes align, needed by mali gpu.
> Adviced by Daniel Kurtz
> - fix some mistake, bugs, remove unused define, more better code style etc.
> - use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
> at runtime instead of clk_prepare_enable().
> - provide a help function from vop for encoder to do mode config, instead of
> using drm_diaplay_mode private method.
> - change vop mode_set timing to make it more safely.
>
> Changes in v7:
> - fix memory leakage problem.
>
> Changes in v8:
> - fix iommu crash when use dual crtc.
> - use frame start interrupt for vsync instead of line flag interrupt,
> because the win config take affect at frame start time, if we use ling flag
> interrupt, the address check often failed.
> Adviced by Daniel Kurtz
> - fix some bugs, mistake, remove unused function
> - keep clock and vop disabled when probe end
> - use drm_plane_helper_check_update to check update_plane if vaild
>
> Changes in v9:
> - fix suspend and resume bug, make iommu attach and detach safely.
> - fix mail info style.
>
> Changes in v10:
> Adviced by Andrzej Hajda
> - check drm_dev if it's NULL at PM suspend/resume
> Adviced by Sean Paul
> - use drm_fb_helper_prepare to init fb_helper funcs
> - Optimized code structure and remove some unnecessary Variables.
>
> Changes in v11:
> - fix mistake that use wrong variable at rockchip sys_resume/sys_suspend
>
> Mark yao (3):
> drm: rockchip: Add basic drm driver
> dt-bindings: video: Add for rockchip display subsytem
> dt-bindings: video: Add documentation for rockchip vop
>
> .../devicetree/bindings/video/rockchip-drm.txt | 19 +
> .../devicetree/bindings/video/rockchip-vop.txt | 58 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/rockchip/Kconfig | 17 +
> drivers/gpu/drm/rockchip/Makefile | 8 +
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 449 ++++++
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 54 +
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 200 +++
> drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 28 +
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 210 +++
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 20 +
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 293 ++++
> drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 54 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1427 ++++++++++++++++++++
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 196 +++
> 16 files changed, 3036 insertions(+)
>
^ permalink raw reply
* Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
From: Greg Kroah-Hartman @ 2014-10-16 23:14 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: devel, Anup Patel, Linux API, lkml, Arve Hjønnevåg,
Santosh Shilimkar, Rebecca Schultz Zavin, John Stultz,
Sumit Semwal, Christoffer Dall
In-Reply-To: <CAKgNAkiPg8G13XZXG6CiaBFZ1yqY2J7_OAppDOGweuNpRaojuA@mail.gmail.com>
On Thu, Oct 16, 2014 at 04:18:02PM +0200, Michael Kerrisk (man-pages) wrote:
> On Thu, Oct 16, 2014 at 2:47 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > The Android binder code has been "stable" for many years now. No matter
> > what comes in the future, we are going to have to support this API, so
> > might as well move it to the "real" part of the kernel as there's no
> > real work that needs to be done to the existing code.
>
> Where does one find the canonical documentation of the user-space API?
There really is only one "canonical" thing, and that is in the libbinder
code in the Android userspace repository. And it's not really
"documentation" so much as, "a C file that interacts with the ioctls in
the binder kernel code" :(
Think of this as just a random character driver with some funny ioctls
that will never get really documented as there is only one user of it.
sorry,
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: android: binder: move to the "real" part of the kernel
From: Greg Kroah-Hartman @ 2014-10-16 23:12 UTC (permalink / raw)
To: John Stultz
Cc: lkml, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Linux API,
Santosh Shilimkar, Arve Hjønnevåg, Sumit Semwal,
Rebecca Schultz Zavin, Christoffer Dall, Anup Patel
In-Reply-To: <CALAqxLU05D8qQA47E77PiuuN7eVt66WEq1qn+PqdE-tpEUzFpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Oct 16, 2014 at 10:09:04AM -0700, John Stultz wrote:
> On Thu, Oct 16, 2014 at 5:47 AM, Greg Kroah-Hartman
> <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> > From: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> >
> > The Android binder code has been "stable" for many years now. No matter
>
> Well, ignoring the ABI break that landed in the last year. :)
As no one noticed, it wasn't a "break" :)
> > This was discussed in the Android miniconf at the Plumbers conference.
> > If anyone has any objections to this, please let me know, otherwise I'm
> > queueing this up for 3.19-rc1
>
> So my main concerns/thoughts here are:
>
> Who is going to maintain this? Has Arve agreed?
Do we really need someone to do more work that has been done on it in
the past as an official "maintainer"? I'll be glad to do it, as I doubt
it will require any time at all.
> Are the Android guys comfortable with the ABI stability rules they'll
> now face?
Just because something is in staging, doesn't mean you don't have to
follow the same ABI stability rules as the rest of the kernel. If a
change had happened to this code that broke userspace in the past, I
would have reverted it. So this should not be anything different from
what has been happening inthe past.
And the Android developers said they were happy to see this code move
into the "real" part of the kernel.
> Currently in the android space no one but libbinder should use the
> kernel interface.
That is correct. If you do that, you deserve all of the pain and
suffering and rooted machines you will get.
> Can we enforce that no one use this interface out-side of android (To
> ensure its one of those "if the abi breaks and no one notices..." edge
> cases)?
This is the kernel, we can not dictate "use", that's the good part of
the GPLv2 :)
Again, as no one has done this before, I strongly doubt it will happen
in the future.
> I'm still hopeful that a libbinder over kdbus will eventually pan out.
> I still see having two core IPC mechanisms (even if the use cases are
> different in style) as a negative, and I worry this might reduce
> motivation to unify things at the lower level. Granted, such work can
> still continue, but the incentives do change.
Yes, things are going to change in the future, there is work happening
here, and there was a presentation at Plumbers about what is going to be
coming.
But all of the changes will be in new code. Be it kdbus, or something
else if that doesn't work out. This existing binder.c file will not be
changing at all. This existing ABI, and codebase, is something that we
have to maintain forever for those millions of devices out there in the
real world today. So as there really is nothing left to do on it, it
deserves to be in the main part of the kernel source tree.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
From: Serge E. Hallyn @ 2014-10-16 21:47 UTC (permalink / raw)
To: Aditya Kali
Cc: Linux API, Linux Containers, Serge Hallyn,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andy Lutomirski, Tejun Heo, cgroups-u79uwXL29TY76Z2rM5mHXA,
Ingo Molnar
In-Reply-To: <CAGr1F2EH0ynfFihTh1dv=n1faxUh0zS3ggk303bwGnDnW2PUCw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Quoting Aditya Kali (adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> On Thu, Oct 16, 2014 at 2:12 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
> > Quoting Aditya Kali (adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> >> setns on a cgroup namespace is allowed only if
> >> * task has CAP_SYS_ADMIN in its current user-namespace and
> >> over the user-namespace associated with target cgroupns.
> >> * task's current cgroup is descendent of the target cgroupns-root
> >> cgroup.
> >
> > What is the point of this?
> >
> > If I'm a user logged into
> > /lxc/c1/user.slice/user-1000.slice/session-c12.scope and I start
> > a container which is in
> > /lxc/c1/user.slice/user-1000.slice/session-c12.scope/x1
> > then I will want to be able to enter the container's cgroup.
> > The container's cgroup root is under my own (satisfying the
> > below condition0 but my cgroup is not a descendent of the
> > container's cgroup.
> >
> This condition is there because we don't want to do implicit cgroup
> changes when a process attaches to another cgroupns. cgroupns tries to
> preserve the invariant that at any point, your current cgroup is
> always under the cgroupns-root of your cgroup namespace. But in your
> example, if we allow a process in "session-c12.scope" container to
> attach to cgroupns root'ed at "session-c12.scope/x1" container
> (without implicitly moving its cgroup), then this invariant won't
> hold.
Oh, I see. Guess that should be workable. Thanks.
-serge
^ permalink raw reply
* Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
From: Aditya Kali @ 2014-10-16 21:22 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Linux API, Linux Containers, Serge Hallyn,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andy Lutomirski, Tejun Heo, cgroups-u79uwXL29TY76Z2rM5mHXA,
Ingo Molnar
In-Reply-To: <20141016211236.GA4308-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
On Thu, Oct 16, 2014 at 2:12 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
> Quoting Aditya Kali (adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
>> setns on a cgroup namespace is allowed only if
>> * task has CAP_SYS_ADMIN in its current user-namespace and
>> over the user-namespace associated with target cgroupns.
>> * task's current cgroup is descendent of the target cgroupns-root
>> cgroup.
>
> What is the point of this?
>
> If I'm a user logged into
> /lxc/c1/user.slice/user-1000.slice/session-c12.scope and I start
> a container which is in
> /lxc/c1/user.slice/user-1000.slice/session-c12.scope/x1
> then I will want to be able to enter the container's cgroup.
> The container's cgroup root is under my own (satisfying the
> below condition0 but my cgroup is not a descendent of the
> container's cgroup.
>
This condition is there because we don't want to do implicit cgroup
changes when a process attaches to another cgroupns. cgroupns tries to
preserve the invariant that at any point, your current cgroup is
always under the cgroupns-root of your cgroup namespace. But in your
example, if we allow a process in "session-c12.scope" container to
attach to cgroupns root'ed at "session-c12.scope/x1" container
(without implicitly moving its cgroup), then this invariant won't
hold.
>
>> * target cgroupns-root is same as or deeper than task's current
>> cgroupns-root. This is so that the task cannot escape out of its
>> cgroupns-root. This also ensures that setns() only makes the task
>> get restricted to a deeper cgroup hierarchy.
>>
>> Signed-off-by: Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>> ---
>> kernel/cgroup_namespace.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 42 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/cgroup_namespace.c b/kernel/cgroup_namespace.c
>> index c16604f..c612946 100644
>> --- a/kernel/cgroup_namespace.c
>> +++ b/kernel/cgroup_namespace.c
>> @@ -80,8 +80,48 @@ err_out:
>>
>> static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
>> {
>> - pr_info("setns not supported for cgroup namespace");
>> - return -EINVAL;
>> + struct cgroup_namespace *cgroup_ns = ns;
>> + struct task_struct *task = current;
>> + struct cgroup *cgrp = NULL;
>> + int err = 0;
>> +
>> + if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN) ||
>> + !ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + /* Prevent cgroup changes for this task. */
>> + threadgroup_lock(task);
>> +
>> + cgrp = get_task_cgroup(task);
>> +
>> + err = -EINVAL;
>> + if (!cgroup_on_dfl(cgrp))
>> + goto out_unlock;
>> +
>> + /* Allow switch only if the task's current cgroup is descendant of the
>> + * target cgroup_ns->root_cgrp.
>> + */
>> + if (!cgroup_is_descendant(cgrp, cgroup_ns->root_cgrp))
>> + goto out_unlock;
>> +
>> + /* Only allow setns to a cgroupns root-ed deeper than task's current
>> + * cgroupns-root. This will make sure that tasks cannot escape their
>> + * cgroupns by attaching to parent cgroupns.
>> + */
>> + if (!cgroup_is_descendant(cgroup_ns->root_cgrp,
>> + task_cgroupns_root(task)))
>> + goto out_unlock;
>> +
>> + err = 0;
>> + get_cgroup_ns(cgroup_ns);
>> + put_cgroup_ns(nsproxy->cgroup_ns);
>> + nsproxy->cgroup_ns = cgroup_ns;
>> +
>> +out_unlock:
>> + threadgroup_unlock(current);
>> + if (cgrp)
>> + cgroup_put(cgrp);
>> + return err;
>> }
>>
>> static void *cgroupns_get(struct task_struct *task)
>> --
>> 2.1.0.rc2.206.gedb03e5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
Aditya
^ permalink raw reply
* Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
From: Andy Lutomirski @ 2014-10-16 21:17 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Linux API, Linux Containers, Serge Hallyn,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tejun Heo,
cgroups-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar
In-Reply-To: <20141016211236.GA4308-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
On Thu, Oct 16, 2014 at 2:12 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
> Quoting Aditya Kali (adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
>> setns on a cgroup namespace is allowed only if
>> * task has CAP_SYS_ADMIN in its current user-namespace and
>> over the user-namespace associated with target cgroupns.
>> * task's current cgroup is descendent of the target cgroupns-root
>> cgroup.
>
> What is the point of this?
>
> If I'm a user logged into
> /lxc/c1/user.slice/user-1000.slice/session-c12.scope and I start
> a container which is in
> /lxc/c1/user.slice/user-1000.slice/session-c12.scope/x1
> then I will want to be able to enter the container's cgroup.
> The container's cgroup root is under my own (satisfying the
> below condition0 but my cgroup is not a descendent of the
> container's cgroup.
>
Presumably you need to ask your friendly cgroup manager to stick you
in that cgroup first. Or we need to generally allow tasks to move
themselves deeper in the hierarchy, but that seems like a big change.
--Andy
>
>> * target cgroupns-root is same as or deeper than task's current
>> cgroupns-root. This is so that the task cannot escape out of its
>> cgroupns-root. This also ensures that setns() only makes the task
>> get restricted to a deeper cgroup hierarchy.
>>
>> Signed-off-by: Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>> ---
>> kernel/cgroup_namespace.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 42 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/cgroup_namespace.c b/kernel/cgroup_namespace.c
>> index c16604f..c612946 100644
>> --- a/kernel/cgroup_namespace.c
>> +++ b/kernel/cgroup_namespace.c
>> @@ -80,8 +80,48 @@ err_out:
>>
>> static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
>> {
>> - pr_info("setns not supported for cgroup namespace");
>> - return -EINVAL;
>> + struct cgroup_namespace *cgroup_ns = ns;
>> + struct task_struct *task = current;
>> + struct cgroup *cgrp = NULL;
>> + int err = 0;
>> +
>> + if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN) ||
>> + !ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + /* Prevent cgroup changes for this task. */
>> + threadgroup_lock(task);
>> +
>> + cgrp = get_task_cgroup(task);
>> +
>> + err = -EINVAL;
>> + if (!cgroup_on_dfl(cgrp))
>> + goto out_unlock;
>> +
>> + /* Allow switch only if the task's current cgroup is descendant of the
>> + * target cgroup_ns->root_cgrp.
>> + */
>> + if (!cgroup_is_descendant(cgrp, cgroup_ns->root_cgrp))
>> + goto out_unlock;
>> +
>> + /* Only allow setns to a cgroupns root-ed deeper than task's current
>> + * cgroupns-root. This will make sure that tasks cannot escape their
>> + * cgroupns by attaching to parent cgroupns.
>> + */
>> + if (!cgroup_is_descendant(cgroup_ns->root_cgrp,
>> + task_cgroupns_root(task)))
>> + goto out_unlock;
>> +
>> + err = 0;
>> + get_cgroup_ns(cgroup_ns);
>> + put_cgroup_ns(nsproxy->cgroup_ns);
>> + nsproxy->cgroup_ns = cgroup_ns;
>> +
>> +out_unlock:
>> + threadgroup_unlock(current);
>> + if (cgrp)
>> + cgroup_put(cgrp);
>> + return err;
>> }
>>
>> static void *cgroupns_get(struct task_struct *task)
>> --
>> 2.1.0.rc2.206.gedb03e5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
From: Serge E. Hallyn @ 2014-10-16 21:12 UTC (permalink / raw)
To: Aditya Kali
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, luto-kltTT9wpgjJwATOyAt5JVQ,
tj-DgEjT+Ai2ygdnm+yROfE0A, cgroups-u79uwXL29TY76Z2rM5mHXA,
mingo-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1413235430-22944-8-git-send-email-adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Quoting Aditya Kali (adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org):
> setns on a cgroup namespace is allowed only if
> * task has CAP_SYS_ADMIN in its current user-namespace and
> over the user-namespace associated with target cgroupns.
> * task's current cgroup is descendent of the target cgroupns-root
> cgroup.
What is the point of this?
If I'm a user logged into
/lxc/c1/user.slice/user-1000.slice/session-c12.scope and I start
a container which is in
/lxc/c1/user.slice/user-1000.slice/session-c12.scope/x1
then I will want to be able to enter the container's cgroup.
The container's cgroup root is under my own (satisfying the
below condition0 but my cgroup is not a descendent of the
container's cgroup.
> * target cgroupns-root is same as or deeper than task's current
> cgroupns-root. This is so that the task cannot escape out of its
> cgroupns-root. This also ensures that setns() only makes the task
> get restricted to a deeper cgroup hierarchy.
>
> Signed-off-by: Aditya Kali <adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
> kernel/cgroup_namespace.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cgroup_namespace.c b/kernel/cgroup_namespace.c
> index c16604f..c612946 100644
> --- a/kernel/cgroup_namespace.c
> +++ b/kernel/cgroup_namespace.c
> @@ -80,8 +80,48 @@ err_out:
>
> static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
> {
> - pr_info("setns not supported for cgroup namespace");
> - return -EINVAL;
> + struct cgroup_namespace *cgroup_ns = ns;
> + struct task_struct *task = current;
> + struct cgroup *cgrp = NULL;
> + int err = 0;
> +
> + if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN) ||
> + !ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + /* Prevent cgroup changes for this task. */
> + threadgroup_lock(task);
> +
> + cgrp = get_task_cgroup(task);
> +
> + err = -EINVAL;
> + if (!cgroup_on_dfl(cgrp))
> + goto out_unlock;
> +
> + /* Allow switch only if the task's current cgroup is descendant of the
> + * target cgroup_ns->root_cgrp.
> + */
> + if (!cgroup_is_descendant(cgrp, cgroup_ns->root_cgrp))
> + goto out_unlock;
> +
> + /* Only allow setns to a cgroupns root-ed deeper than task's current
> + * cgroupns-root. This will make sure that tasks cannot escape their
> + * cgroupns by attaching to parent cgroupns.
> + */
> + if (!cgroup_is_descendant(cgroup_ns->root_cgrp,
> + task_cgroupns_root(task)))
> + goto out_unlock;
> +
> + err = 0;
> + get_cgroup_ns(cgroup_ns);
> + put_cgroup_ns(nsproxy->cgroup_ns);
> + nsproxy->cgroup_ns = cgroup_ns;
> +
> +out_unlock:
> + threadgroup_unlock(current);
> + if (cgrp)
> + cgroup_put(cgrp);
> + return err;
> }
>
> static void *cgroupns_get(struct task_struct *task)
> --
> 2.1.0.rc2.206.gedb03e5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox