* Re: [PATCH] seccomp: add ptrace commands for suspend/resume
From: Tycho Andersen @ 2015-06-01 20:00 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Kees Cook, Will Drewry, Roland McGrath, Oleg Nesterov,
Pavel Emelyanov, Serge E. Hallyn
In-Reply-To: <CALCETrVaE5UsTSQDf=48R8J9gG6YiMdp30wOMD+aZvxtOjrLRQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jun 01, 2015 at 12:38:57PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 1, 2015 at 12:28 PM, Tycho Andersen
> <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> > This patch is the first step in enabling checkpoint/restore of processes
> > with seccomp enabled.
> >
> > One of the things CRIU does while dumping tasks is inject code into them
> > via ptrace to collect information that is only available to the process
> > itself. However, if we are in a seccomp mode where these processes are
> > prohibited from making these syscalls, then what CRIU does kills the task.
> >
> > This patch adds a new ptrace command, PTRACE_SUSPEND_SECCOMP that enables a
> > task from the init user namespace which has CAP_SYS_ADMIN to disable (and
> > re-enable) seccomp filters for another task so that they can be
> > successfully dumped (and restored).
> >
> > Signed-off-by: Tycho Andersen <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> > CC: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > CC: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> > CC: Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > CC: Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org>
> > CC: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > CC: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> > CC: Serge E. Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
> > ---
> > include/linux/seccomp.h | 8 ++++++
> > include/uapi/linux/ptrace.h | 1 +
> > kernel/ptrace.c | 10 ++++++++
> > kernel/seccomp.c | 62 ++++++++++++++++++++++++++++++++++++++++++++-
> > 4 files changed, 80 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
> > index a19ddac..7cc870f 100644
> > --- a/include/linux/seccomp.h
> > +++ b/include/linux/seccomp.h
> > @@ -25,6 +25,9 @@ struct seccomp_filter;
> > struct seccomp {
> > int mode;
> > struct seccomp_filter *filter;
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > + bool suspended;
> > +#endif
> > };
> >
> > #ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
> > @@ -53,6 +56,11 @@ static inline int seccomp_mode(struct seccomp *s)
> > return s->mode;
> > }
> >
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > +extern int suspend_seccomp(struct task_struct *);
> > +extern int resume_seccomp(struct task_struct *);
> > +#endif
> > +
> > #else /* CONFIG_SECCOMP */
> >
> > #include <linux/errno.h>
> > diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
> > index cf1019e..8ba4e4f 100644
> > --- a/include/uapi/linux/ptrace.h
> > +++ b/include/uapi/linux/ptrace.h
> > @@ -17,6 +17,7 @@
> > #define PTRACE_CONT 7
> > #define PTRACE_KILL 8
> > #define PTRACE_SINGLESTEP 9
> > +#define PTRACE_SUSPEND_SECCOMP 10
> >
> > #define PTRACE_ATTACH 16
> > #define PTRACE_DETACH 17
> > diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> > index c8e0e05..a6b6527 100644
> > --- a/kernel/ptrace.c
> > +++ b/kernel/ptrace.c
> > @@ -15,6 +15,7 @@
> > #include <linux/highmem.h>
> > #include <linux/pagemap.h>
> > #include <linux/ptrace.h>
> > +#include <linux/seccomp.h>
> > #include <linux/security.h>
> > #include <linux/signal.h>
> > #include <linux/uio.h>
> > @@ -1003,6 +1004,15 @@ int ptrace_request(struct task_struct *child, long request,
> > break;
> > }
> > #endif
> > +
> > +#if defined(CONFIG_SECCOMP) && defined(CONFIG_CHECKPOINT_RESTORE)
> > + case PTRACE_SUSPEND_SECCOMP:
> > + if (data)
> > + return suspend_seccomp(child);
> > + else
> > + return resume_seccomp(child);
> > +#endif
> > +
> > default:
> > break;
> > }
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index 980fd26..a358a58 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -569,6 +569,7 @@ static int mode1_syscalls_32[] = {
> > static void __secure_computing_strict(int this_syscall)
> > {
> > int *syscall_whitelist = mode1_syscalls;
> > +
> > #ifdef CONFIG_COMPAT
> > if (is_compat_task())
> > syscall_whitelist = mode1_syscalls_32;
> > @@ -590,6 +591,11 @@ void secure_computing_strict(int this_syscall)
> > {
> > int mode = current->seccomp.mode;
> >
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > + if (current->seccomp.suspended)
> > + return;
> > +#endif
>
> IMO it's unfortunate that this has any runtime overhead at all. Can
> it be suspend be multiplexed into mode to avoid this?
Yes, I can make that change. Something like:
#define SECCOMP_SUSPENDED 0x8000000
and then masking it off at the appropriate places?
Tycho
^ permalink raw reply
* Re: [PATCH] seccomp: add ptrace commands for suspend/resume
From: Andy Lutomirski @ 2015-06-01 19:51 UTC (permalink / raw)
To: Tycho Andersen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Kees Cook, Will Drewry, Roland McGrath, Oleg Nesterov,
Pavel Emelyanov, Serge E. Hallyn
In-Reply-To: <20150601194707.GA2818@hopstrocity>
On Mon, Jun 1, 2015 at 12:47 PM, Tycho Andersen
<tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> On Mon, Jun 01, 2015 at 12:38:57PM -0700, Andy Lutomirski wrote:
>> On Mon, Jun 1, 2015 at 12:28 PM, Tycho Andersen
>> <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
>> > This patch is the first step in enabling checkpoint/restore of processes
>> > with seccomp enabled.
>> >
>> > One of the things CRIU does while dumping tasks is inject code into them
>> > via ptrace to collect information that is only available to the process
>> > itself. However, if we are in a seccomp mode where these processes are
>> > prohibited from making these syscalls, then what CRIU does kills the task.
>> >
>> > This patch adds a new ptrace command, PTRACE_SUSPEND_SECCOMP that enables a
>> > task from the init user namespace which has CAP_SYS_ADMIN to disable (and
>> > re-enable) seccomp filters for another task so that they can be
>> > successfully dumped (and restored).
>> >
>> > Signed-off-by: Tycho Andersen <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
>> > CC: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> > CC: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
>> > CC: Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> > CC: Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org>
>> > CC: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> > CC: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>> > CC: Serge E. Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
>> > ---
>> > include/linux/seccomp.h | 8 ++++++
>> > include/uapi/linux/ptrace.h | 1 +
>> > kernel/ptrace.c | 10 ++++++++
>> > kernel/seccomp.c | 62 ++++++++++++++++++++++++++++++++++++++++++++-
>> > 4 files changed, 80 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
>> > index a19ddac..7cc870f 100644
>> > --- a/include/linux/seccomp.h
>> > +++ b/include/linux/seccomp.h
>> > @@ -25,6 +25,9 @@ struct seccomp_filter;
>> > struct seccomp {
>> > int mode;
>> > struct seccomp_filter *filter;
>> > +#ifdef CONFIG_CHECKPOINT_RESTORE
>> > + bool suspended;
>> > +#endif
>> > };
>> >
>> > #ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
>> > @@ -53,6 +56,11 @@ static inline int seccomp_mode(struct seccomp *s)
>> > return s->mode;
>> > }
>> >
>> > +#ifdef CONFIG_CHECKPOINT_RESTORE
>> > +extern int suspend_seccomp(struct task_struct *);
>> > +extern int resume_seccomp(struct task_struct *);
>> > +#endif
>> > +
>> > #else /* CONFIG_SECCOMP */
>> >
>> > #include <linux/errno.h>
>> > diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
>> > index cf1019e..8ba4e4f 100644
>> > --- a/include/uapi/linux/ptrace.h
>> > +++ b/include/uapi/linux/ptrace.h
>> > @@ -17,6 +17,7 @@
>> > #define PTRACE_CONT 7
>> > #define PTRACE_KILL 8
>> > #define PTRACE_SINGLESTEP 9
>> > +#define PTRACE_SUSPEND_SECCOMP 10
>> >
>> > #define PTRACE_ATTACH 16
>> > #define PTRACE_DETACH 17
>> > diff --git a/kernel/ptrace.c b/kernel/ptrace.c
>> > index c8e0e05..a6b6527 100644
>> > --- a/kernel/ptrace.c
>> > +++ b/kernel/ptrace.c
>> > @@ -15,6 +15,7 @@
>> > #include <linux/highmem.h>
>> > #include <linux/pagemap.h>
>> > #include <linux/ptrace.h>
>> > +#include <linux/seccomp.h>
>> > #include <linux/security.h>
>> > #include <linux/signal.h>
>> > #include <linux/uio.h>
>> > @@ -1003,6 +1004,15 @@ int ptrace_request(struct task_struct *child, long request,
>> > break;
>> > }
>> > #endif
>> > +
>> > +#if defined(CONFIG_SECCOMP) && defined(CONFIG_CHECKPOINT_RESTORE)
>> > + case PTRACE_SUSPEND_SECCOMP:
>> > + if (data)
>> > + return suspend_seccomp(child);
>> > + else
>> > + return resume_seccomp(child);
>> > +#endif
>> > +
>> > default:
>> > break;
>> > }
>> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
>> > index 980fd26..a358a58 100644
>> > --- a/kernel/seccomp.c
>> > +++ b/kernel/seccomp.c
>> > @@ -569,6 +569,7 @@ static int mode1_syscalls_32[] = {
>> > static void __secure_computing_strict(int this_syscall)
>> > {
>> > int *syscall_whitelist = mode1_syscalls;
>> > +
>> > #ifdef CONFIG_COMPAT
>> > if (is_compat_task())
>> > syscall_whitelist = mode1_syscalls_32;
>> > @@ -590,6 +591,11 @@ void secure_computing_strict(int this_syscall)
>> > {
>> > int mode = current->seccomp.mode;
>> >
>> > +#ifdef CONFIG_CHECKPOINT_RESTORE
>> > + if (current->seccomp.suspended)
>> > + return;
>> > +#endif
>>
>> IMO it's unfortunate that this has any runtime overhead at all. Can
>> it be suspend be multiplexed into mode to avoid this?
>>
>> >
>> > +#ifdef CONFIG_CHECKPOINT_RESTORE
>> > + if (unlikely(current->seccomp.suspended))
>> > + return SECCOMP_PHASE1_OK;
>> > +#endif
>> > +
>>
>> Ditto.
>>
>> > @@ -769,7 +780,8 @@ static long seccomp_set_mode_strict(void)
>> > goto out;
>> >
>> > #ifdef TIF_NOTSC
>> > - disable_TSC();
>> > + if (!current->seccomp.suspended)
>> > + disable_TSC();
>> > #endif
>>
>> If you get here with seccomp suspended, you have already utterly
>> failed. Please don't try to pretend that you're going to do something
>> sensible if this happens.
>>
>> CRIU needs to freeze the target task reliably before suspending
>> seccomp to avoid massive security holes.
>
> Sorry, I should probably have mentioned this. It actually useful on
> restore: the problem is that CRIU maps its restorer code into memory,
> does all of the necessary work to restore (including restore the
> seccomp stuff), and then tries to unmap that blob and gets killed.
>
> So, the criu restore procedure is to suspend seccomp, restore the
> seccomp state, and then let criu resume the seccomp state just before
> the final task resume.
>
>> > seccomp_assign_mode(current, seccomp_mode);
>> > ret = 0;
>> > @@ -901,3 +913,51 @@ long prctl_set_seccomp(unsigned long seccomp_mode, char __user *filter)
>> > /* prctl interface doesn't have flags, so they are always zero. */
>> > return do_seccomp(op, 0, uargs);
>> > }
>> > +
>> > +#ifdef CONFIG_CHECKPOINT_RESTORE
>> > +int suspend_seccomp(struct task_struct *task)
>> > +{
>> > + int ret = -EACCES;
>> > +
>> > + spin_lock_irq(&task->sighand->siglock);
>> > +
>> > + if (!capable(CAP_SYS_ADMIN))
>> > + goto out;
>> > +
>> > + task->seccomp.suspended = true;
>> > +
>> > +#ifdef TIF_NOTSC
>> > + if (task->seccomp.mode == SECCOMP_MODE_STRICT)
>> > + clear_tsk_thread_flag(task, TIF_NOTSC);
>> > +#endif
>>
>> And what if the task is running?
>>
>> > +
>> > + ret = 0;
>> > +out:
>> > + spin_unlock_irq(&task->sighand->siglock);
>> > +
>> > + return ret;
>> > +}
>> > +
>> > +int resume_seccomp(struct task_struct *task)
>> > +{
>> > + int ret = -EACCES;
>> > +
>> > + spin_lock_irq(&task->sighand->siglock);
>> > +
>> > + if (!capable(CAP_SYS_ADMIN))
>> > + goto out;
>> > +
>> > + task->seccomp.suspended = false;
>> > +
>> > +#ifdef TIF_NOTSC
>> > + if (task->seccomp.mode == SECCOMP_MODE_STRICT)
>> > + set_tsk_thread_flag(task, TIF_NOTSC);
>> > +#endif
>>
>> Ditto. Or can the task not be running here?
>
> It is stopped since ptrace requires it to be stopped; I don't know if
> that's enough to guarantee correctness, though. Is there some
> additional barrier that is needed?
Dunno. Does ptrace actually guarantee that for new operations?
In any event, I'm not sure I see why you need to manipulate NOTSC like
this at all. What goes wrong if you let the NOTSC take effect
immediately?
--Andy
^ permalink raw reply
* Re: [PATCH] seccomp: add ptrace commands for suspend/resume
From: Tycho Andersen @ 2015-06-01 19:47 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Kees Cook, Will Drewry, Roland McGrath, Oleg Nesterov,
Pavel Emelyanov, Serge E. Hallyn
In-Reply-To: <CALCETrVaE5UsTSQDf=48R8J9gG6YiMdp30wOMD+aZvxtOjrLRQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jun 01, 2015 at 12:38:57PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 1, 2015 at 12:28 PM, Tycho Andersen
> <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> > This patch is the first step in enabling checkpoint/restore of processes
> > with seccomp enabled.
> >
> > One of the things CRIU does while dumping tasks is inject code into them
> > via ptrace to collect information that is only available to the process
> > itself. However, if we are in a seccomp mode where these processes are
> > prohibited from making these syscalls, then what CRIU does kills the task.
> >
> > This patch adds a new ptrace command, PTRACE_SUSPEND_SECCOMP that enables a
> > task from the init user namespace which has CAP_SYS_ADMIN to disable (and
> > re-enable) seccomp filters for another task so that they can be
> > successfully dumped (and restored).
> >
> > Signed-off-by: Tycho Andersen <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> > CC: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > CC: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> > CC: Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > CC: Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org>
> > CC: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > CC: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> > CC: Serge E. Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
> > ---
> > include/linux/seccomp.h | 8 ++++++
> > include/uapi/linux/ptrace.h | 1 +
> > kernel/ptrace.c | 10 ++++++++
> > kernel/seccomp.c | 62 ++++++++++++++++++++++++++++++++++++++++++++-
> > 4 files changed, 80 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
> > index a19ddac..7cc870f 100644
> > --- a/include/linux/seccomp.h
> > +++ b/include/linux/seccomp.h
> > @@ -25,6 +25,9 @@ struct seccomp_filter;
> > struct seccomp {
> > int mode;
> > struct seccomp_filter *filter;
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > + bool suspended;
> > +#endif
> > };
> >
> > #ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
> > @@ -53,6 +56,11 @@ static inline int seccomp_mode(struct seccomp *s)
> > return s->mode;
> > }
> >
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > +extern int suspend_seccomp(struct task_struct *);
> > +extern int resume_seccomp(struct task_struct *);
> > +#endif
> > +
> > #else /* CONFIG_SECCOMP */
> >
> > #include <linux/errno.h>
> > diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
> > index cf1019e..8ba4e4f 100644
> > --- a/include/uapi/linux/ptrace.h
> > +++ b/include/uapi/linux/ptrace.h
> > @@ -17,6 +17,7 @@
> > #define PTRACE_CONT 7
> > #define PTRACE_KILL 8
> > #define PTRACE_SINGLESTEP 9
> > +#define PTRACE_SUSPEND_SECCOMP 10
> >
> > #define PTRACE_ATTACH 16
> > #define PTRACE_DETACH 17
> > diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> > index c8e0e05..a6b6527 100644
> > --- a/kernel/ptrace.c
> > +++ b/kernel/ptrace.c
> > @@ -15,6 +15,7 @@
> > #include <linux/highmem.h>
> > #include <linux/pagemap.h>
> > #include <linux/ptrace.h>
> > +#include <linux/seccomp.h>
> > #include <linux/security.h>
> > #include <linux/signal.h>
> > #include <linux/uio.h>
> > @@ -1003,6 +1004,15 @@ int ptrace_request(struct task_struct *child, long request,
> > break;
> > }
> > #endif
> > +
> > +#if defined(CONFIG_SECCOMP) && defined(CONFIG_CHECKPOINT_RESTORE)
> > + case PTRACE_SUSPEND_SECCOMP:
> > + if (data)
> > + return suspend_seccomp(child);
> > + else
> > + return resume_seccomp(child);
> > +#endif
> > +
> > default:
> > break;
> > }
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index 980fd26..a358a58 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -569,6 +569,7 @@ static int mode1_syscalls_32[] = {
> > static void __secure_computing_strict(int this_syscall)
> > {
> > int *syscall_whitelist = mode1_syscalls;
> > +
> > #ifdef CONFIG_COMPAT
> > if (is_compat_task())
> > syscall_whitelist = mode1_syscalls_32;
> > @@ -590,6 +591,11 @@ void secure_computing_strict(int this_syscall)
> > {
> > int mode = current->seccomp.mode;
> >
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > + if (current->seccomp.suspended)
> > + return;
> > +#endif
>
> IMO it's unfortunate that this has any runtime overhead at all. Can
> it be suspend be multiplexed into mode to avoid this?
>
> >
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > + if (unlikely(current->seccomp.suspended))
> > + return SECCOMP_PHASE1_OK;
> > +#endif
> > +
>
> Ditto.
>
> > @@ -769,7 +780,8 @@ static long seccomp_set_mode_strict(void)
> > goto out;
> >
> > #ifdef TIF_NOTSC
> > - disable_TSC();
> > + if (!current->seccomp.suspended)
> > + disable_TSC();
> > #endif
>
> If you get here with seccomp suspended, you have already utterly
> failed. Please don't try to pretend that you're going to do something
> sensible if this happens.
>
> CRIU needs to freeze the target task reliably before suspending
> seccomp to avoid massive security holes.
Sorry, I should probably have mentioned this. It actually useful on
restore: the problem is that CRIU maps its restorer code into memory,
does all of the necessary work to restore (including restore the
seccomp stuff), and then tries to unmap that blob and gets killed.
So, the criu restore procedure is to suspend seccomp, restore the
seccomp state, and then let criu resume the seccomp state just before
the final task resume.
> > seccomp_assign_mode(current, seccomp_mode);
> > ret = 0;
> > @@ -901,3 +913,51 @@ long prctl_set_seccomp(unsigned long seccomp_mode, char __user *filter)
> > /* prctl interface doesn't have flags, so they are always zero. */
> > return do_seccomp(op, 0, uargs);
> > }
> > +
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > +int suspend_seccomp(struct task_struct *task)
> > +{
> > + int ret = -EACCES;
> > +
> > + spin_lock_irq(&task->sighand->siglock);
> > +
> > + if (!capable(CAP_SYS_ADMIN))
> > + goto out;
> > +
> > + task->seccomp.suspended = true;
> > +
> > +#ifdef TIF_NOTSC
> > + if (task->seccomp.mode == SECCOMP_MODE_STRICT)
> > + clear_tsk_thread_flag(task, TIF_NOTSC);
> > +#endif
>
> And what if the task is running?
>
> > +
> > + ret = 0;
> > +out:
> > + spin_unlock_irq(&task->sighand->siglock);
> > +
> > + return ret;
> > +}
> > +
> > +int resume_seccomp(struct task_struct *task)
> > +{
> > + int ret = -EACCES;
> > +
> > + spin_lock_irq(&task->sighand->siglock);
> > +
> > + if (!capable(CAP_SYS_ADMIN))
> > + goto out;
> > +
> > + task->seccomp.suspended = false;
> > +
> > +#ifdef TIF_NOTSC
> > + if (task->seccomp.mode == SECCOMP_MODE_STRICT)
> > + set_tsk_thread_flag(task, TIF_NOTSC);
> > +#endif
>
> Ditto. Or can the task not be running here?
It is stopped since ptrace requires it to be stopped; I don't know if
that's enough to guarantee correctness, though. Is there some
additional barrier that is needed?
Tycho
> --Andy
^ permalink raw reply
* Re: [PATCH] seccomp: add ptrace commands for suspend/resume
From: Andy Lutomirski @ 2015-06-01 19:38 UTC (permalink / raw)
To: Tycho Andersen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Kees Cook, Will Drewry, Roland McGrath, Oleg Nesterov,
Pavel Emelyanov, Serge E. Hallyn
In-Reply-To: <1433186918-9626-1-git-send-email-tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
On Mon, Jun 1, 2015 at 12:28 PM, Tycho Andersen
<tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> This patch is the first step in enabling checkpoint/restore of processes
> with seccomp enabled.
>
> One of the things CRIU does while dumping tasks is inject code into them
> via ptrace to collect information that is only available to the process
> itself. However, if we are in a seccomp mode where these processes are
> prohibited from making these syscalls, then what CRIU does kills the task.
>
> This patch adds a new ptrace command, PTRACE_SUSPEND_SECCOMP that enables a
> task from the init user namespace which has CAP_SYS_ADMIN to disable (and
> re-enable) seccomp filters for another task so that they can be
> successfully dumped (and restored).
>
> Signed-off-by: Tycho Andersen <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> CC: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> CC: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> CC: Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> CC: Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org>
> CC: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> CC: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> CC: Serge E. Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
> ---
> include/linux/seccomp.h | 8 ++++++
> include/uapi/linux/ptrace.h | 1 +
> kernel/ptrace.c | 10 ++++++++
> kernel/seccomp.c | 62 ++++++++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 80 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
> index a19ddac..7cc870f 100644
> --- a/include/linux/seccomp.h
> +++ b/include/linux/seccomp.h
> @@ -25,6 +25,9 @@ struct seccomp_filter;
> struct seccomp {
> int mode;
> struct seccomp_filter *filter;
> +#ifdef CONFIG_CHECKPOINT_RESTORE
> + bool suspended;
> +#endif
> };
>
> #ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
> @@ -53,6 +56,11 @@ static inline int seccomp_mode(struct seccomp *s)
> return s->mode;
> }
>
> +#ifdef CONFIG_CHECKPOINT_RESTORE
> +extern int suspend_seccomp(struct task_struct *);
> +extern int resume_seccomp(struct task_struct *);
> +#endif
> +
> #else /* CONFIG_SECCOMP */
>
> #include <linux/errno.h>
> diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
> index cf1019e..8ba4e4f 100644
> --- a/include/uapi/linux/ptrace.h
> +++ b/include/uapi/linux/ptrace.h
> @@ -17,6 +17,7 @@
> #define PTRACE_CONT 7
> #define PTRACE_KILL 8
> #define PTRACE_SINGLESTEP 9
> +#define PTRACE_SUSPEND_SECCOMP 10
>
> #define PTRACE_ATTACH 16
> #define PTRACE_DETACH 17
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index c8e0e05..a6b6527 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -15,6 +15,7 @@
> #include <linux/highmem.h>
> #include <linux/pagemap.h>
> #include <linux/ptrace.h>
> +#include <linux/seccomp.h>
> #include <linux/security.h>
> #include <linux/signal.h>
> #include <linux/uio.h>
> @@ -1003,6 +1004,15 @@ int ptrace_request(struct task_struct *child, long request,
> break;
> }
> #endif
> +
> +#if defined(CONFIG_SECCOMP) && defined(CONFIG_CHECKPOINT_RESTORE)
> + case PTRACE_SUSPEND_SECCOMP:
> + if (data)
> + return suspend_seccomp(child);
> + else
> + return resume_seccomp(child);
> +#endif
> +
> default:
> break;
> }
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 980fd26..a358a58 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -569,6 +569,7 @@ static int mode1_syscalls_32[] = {
> static void __secure_computing_strict(int this_syscall)
> {
> int *syscall_whitelist = mode1_syscalls;
> +
> #ifdef CONFIG_COMPAT
> if (is_compat_task())
> syscall_whitelist = mode1_syscalls_32;
> @@ -590,6 +591,11 @@ void secure_computing_strict(int this_syscall)
> {
> int mode = current->seccomp.mode;
>
> +#ifdef CONFIG_CHECKPOINT_RESTORE
> + if (current->seccomp.suspended)
> + return;
> +#endif
IMO it's unfortunate that this has any runtime overhead at all. Can
it be suspend be multiplexed into mode to avoid this?
>
> +#ifdef CONFIG_CHECKPOINT_RESTORE
> + if (unlikely(current->seccomp.suspended))
> + return SECCOMP_PHASE1_OK;
> +#endif
> +
Ditto.
> @@ -769,7 +780,8 @@ static long seccomp_set_mode_strict(void)
> goto out;
>
> #ifdef TIF_NOTSC
> - disable_TSC();
> + if (!current->seccomp.suspended)
> + disable_TSC();
> #endif
If you get here with seccomp suspended, you have already utterly
failed. Please don't try to pretend that you're going to do something
sensible if this happens.
CRIU needs to freeze the target task reliably before suspending
seccomp to avoid massive security holes.
> seccomp_assign_mode(current, seccomp_mode);
> ret = 0;
> @@ -901,3 +913,51 @@ long prctl_set_seccomp(unsigned long seccomp_mode, char __user *filter)
> /* prctl interface doesn't have flags, so they are always zero. */
> return do_seccomp(op, 0, uargs);
> }
> +
> +#ifdef CONFIG_CHECKPOINT_RESTORE
> +int suspend_seccomp(struct task_struct *task)
> +{
> + int ret = -EACCES;
> +
> + spin_lock_irq(&task->sighand->siglock);
> +
> + if (!capable(CAP_SYS_ADMIN))
> + goto out;
> +
> + task->seccomp.suspended = true;
> +
> +#ifdef TIF_NOTSC
> + if (task->seccomp.mode == SECCOMP_MODE_STRICT)
> + clear_tsk_thread_flag(task, TIF_NOTSC);
> +#endif
And what if the task is running?
> +
> + ret = 0;
> +out:
> + spin_unlock_irq(&task->sighand->siglock);
> +
> + return ret;
> +}
> +
> +int resume_seccomp(struct task_struct *task)
> +{
> + int ret = -EACCES;
> +
> + spin_lock_irq(&task->sighand->siglock);
> +
> + if (!capable(CAP_SYS_ADMIN))
> + goto out;
> +
> + task->seccomp.suspended = false;
> +
> +#ifdef TIF_NOTSC
> + if (task->seccomp.mode == SECCOMP_MODE_STRICT)
> + set_tsk_thread_flag(task, TIF_NOTSC);
> +#endif
Ditto. Or can the task not be running here?
--Andy
^ permalink raw reply
* [PATCH] seccomp: add ptrace commands for suspend/resume
From: Tycho Andersen @ 2015-06-01 19:28 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
Cc: Tycho Andersen, Kees Cook, Andy Lutomirski, Will Drewry,
Roland McGrath, Oleg Nesterov, Pavel Emelyanov, Serge E. Hallyn
This patch is the first step in enabling checkpoint/restore of processes
with seccomp enabled.
One of the things CRIU does while dumping tasks is inject code into them
via ptrace to collect information that is only available to the process
itself. However, if we are in a seccomp mode where these processes are
prohibited from making these syscalls, then what CRIU does kills the task.
This patch adds a new ptrace command, PTRACE_SUSPEND_SECCOMP that enables a
task from the init user namespace which has CAP_SYS_ADMIN to disable (and
re-enable) seccomp filters for another task so that they can be
successfully dumped (and restored).
Signed-off-by: Tycho Andersen <tycho.andersen-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
CC: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
CC: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
CC: Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
CC: Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org>
CC: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
CC: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
CC: Serge E. Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
---
include/linux/seccomp.h | 8 ++++++
include/uapi/linux/ptrace.h | 1 +
kernel/ptrace.c | 10 ++++++++
kernel/seccomp.c | 62 ++++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index a19ddac..7cc870f 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -25,6 +25,9 @@ struct seccomp_filter;
struct seccomp {
int mode;
struct seccomp_filter *filter;
+#ifdef CONFIG_CHECKPOINT_RESTORE
+ bool suspended;
+#endif
};
#ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
@@ -53,6 +56,11 @@ static inline int seccomp_mode(struct seccomp *s)
return s->mode;
}
+#ifdef CONFIG_CHECKPOINT_RESTORE
+extern int suspend_seccomp(struct task_struct *);
+extern int resume_seccomp(struct task_struct *);
+#endif
+
#else /* CONFIG_SECCOMP */
#include <linux/errno.h>
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index cf1019e..8ba4e4f 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -17,6 +17,7 @@
#define PTRACE_CONT 7
#define PTRACE_KILL 8
#define PTRACE_SINGLESTEP 9
+#define PTRACE_SUSPEND_SECCOMP 10
#define PTRACE_ATTACH 16
#define PTRACE_DETACH 17
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index c8e0e05..a6b6527 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -15,6 +15,7 @@
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <linux/ptrace.h>
+#include <linux/seccomp.h>
#include <linux/security.h>
#include <linux/signal.h>
#include <linux/uio.h>
@@ -1003,6 +1004,15 @@ int ptrace_request(struct task_struct *child, long request,
break;
}
#endif
+
+#if defined(CONFIG_SECCOMP) && defined(CONFIG_CHECKPOINT_RESTORE)
+ case PTRACE_SUSPEND_SECCOMP:
+ if (data)
+ return suspend_seccomp(child);
+ else
+ return resume_seccomp(child);
+#endif
+
default:
break;
}
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 980fd26..a358a58 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -569,6 +569,7 @@ static int mode1_syscalls_32[] = {
static void __secure_computing_strict(int this_syscall)
{
int *syscall_whitelist = mode1_syscalls;
+
#ifdef CONFIG_COMPAT
if (is_compat_task())
syscall_whitelist = mode1_syscalls_32;
@@ -590,6 +591,11 @@ void secure_computing_strict(int this_syscall)
{
int mode = current->seccomp.mode;
+#ifdef CONFIG_CHECKPOINT_RESTORE
+ if (current->seccomp.suspended)
+ return;
+#endif
+
if (mode == 0)
return;
else if (mode == SECCOMP_MODE_STRICT)
@@ -691,6 +697,11 @@ u32 seccomp_phase1(struct seccomp_data *sd)
int this_syscall = sd ? sd->nr :
syscall_get_nr(current, task_pt_regs(current));
+#ifdef CONFIG_CHECKPOINT_RESTORE
+ if (unlikely(current->seccomp.suspended))
+ return SECCOMP_PHASE1_OK;
+#endif
+
switch (mode) {
case SECCOMP_MODE_STRICT:
__secure_computing_strict(this_syscall); /* may call do_exit */
@@ -769,7 +780,8 @@ static long seccomp_set_mode_strict(void)
goto out;
#ifdef TIF_NOTSC
- disable_TSC();
+ if (!current->seccomp.suspended)
+ disable_TSC();
#endif
seccomp_assign_mode(current, seccomp_mode);
ret = 0;
@@ -901,3 +913,51 @@ long prctl_set_seccomp(unsigned long seccomp_mode, char __user *filter)
/* prctl interface doesn't have flags, so they are always zero. */
return do_seccomp(op, 0, uargs);
}
+
+#ifdef CONFIG_CHECKPOINT_RESTORE
+int suspend_seccomp(struct task_struct *task)
+{
+ int ret = -EACCES;
+
+ spin_lock_irq(&task->sighand->siglock);
+
+ if (!capable(CAP_SYS_ADMIN))
+ goto out;
+
+ task->seccomp.suspended = true;
+
+#ifdef TIF_NOTSC
+ if (task->seccomp.mode == SECCOMP_MODE_STRICT)
+ clear_tsk_thread_flag(task, TIF_NOTSC);
+#endif
+
+ ret = 0;
+out:
+ spin_unlock_irq(&task->sighand->siglock);
+
+ return ret;
+}
+
+int resume_seccomp(struct task_struct *task)
+{
+ int ret = -EACCES;
+
+ spin_lock_irq(&task->sighand->siglock);
+
+ if (!capable(CAP_SYS_ADMIN))
+ goto out;
+
+ task->seccomp.suspended = false;
+
+#ifdef TIF_NOTSC
+ if (task->seccomp.mode == SECCOMP_MODE_STRICT)
+ set_tsk_thread_flag(task, TIF_NOTSC);
+#endif
+
+ ret = 0;
+out:
+ spin_unlock_irq(&task->sighand->siglock);
+
+ return ret;
+}
+#endif /* CONFIG_CHECKPOINT_RESTORE */
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 25/98] sctp.h: use __u8 and __u32 from linux/types.h
From: Neil Horman @ 2015-06-01 13:40 UTC (permalink / raw)
To: Mikko Rapeli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vlad Yasevich,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1433000370-19509-26-git-send-email-mikko.rapeli-X3B1VOXEql0@public.gmane.org>
On Sat, May 30, 2015 at 05:38:17PM +0200, Mikko Rapeli wrote:
> Fixes userspace compilation errors like:
>
> linux/sctp.h:652:2: error: unknown type name ‘uint32_t’
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> ---
> include/uapi/linux/sctp.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> index ce70fe6..dd0a9c2 100644
> --- a/include/uapi/linux/sctp.h
> +++ b/include/uapi/linux/sctp.h
> @@ -718,13 +718,13 @@ struct sctp_authkeyid {
> */
> struct sctp_sack_info {
> sctp_assoc_t sack_assoc_id;
> - uint32_t sack_delay;
> - uint32_t sack_freq;
> + __u32 sack_delay;
> + __u32 sack_freq;
> };
>
> struct sctp_assoc_value {
> sctp_assoc_t assoc_id;
> - uint32_t assoc_value;
> + __u32 assoc_value;
> };
>
> /*
> @@ -794,7 +794,7 @@ struct sctp_status {
> struct sctp_authchunks {
> sctp_assoc_t gauth_assoc_id;
> __u32 gauth_number_of_chunks;
> - uint8_t gauth_chunks[];
> + __u8 gauth_chunks[];
> };
>
> /* The broken spelling has been released already in lksctp-tools header,
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v5 10/12] KVM: arm64: guest debug, HW assisted debug support
From: Alex Bennée @ 2015-06-01 12:41 UTC (permalink / raw)
To: Will Deacon
Cc: kvm@vger.kernel.org, open list:DOCUMENTA TION, Peter Zijlstra,
jan.kiszka@siemens.com, Ingo Molnar, Lorenzo Pieralisi,
Russell King, Jonathan Corbet, kvmarm@lists.cs.columbia.edu,
Gleb Natapov, zhichao.huang@linaro.org, Catalin Marinas,
bp@suse.de, Marc Zyngier, r65777@freescale.com,
linux-arm-kernel@lists.infradead.org, open list:ABI/API,
open list, dahi@linux.vnet.ibm.com, pbonzini
In-Reply-To: <20150601091552.GA1641@arm.com>
Will Deacon <will.deacon@arm.com> writes:
> Hi Alex,
>
> On Fri, May 29, 2015 at 10:30:26AM +0100, Alex Bennée wrote:
>> This adds support for userspace to control the HW debug registers for
>> guest debug. In the debug ioctl we copy the IMPDEF defined number of
>> registers into a new register set called host_debug_state. There is now
>> a new vcpu parameter called debug_ptr which selects which register set
>> is to copied into the real registers when world switch occurs.
>>
>> I've moved some helper functions into the hw_breakpoint.h header for
>> re-use.
>>
>> As with single step we need to tweak the guest registers to enable the
>> exceptions so we need to save and restore those bits.
>>
>> Two new capabilities have been added to the KVM_EXTENSION ioctl to allow
>> userspace to query the number of hardware break and watch points
>> available on the host hardware.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
> [...]
>
>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>> index 33c8143..ada57df 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -2668,7 +2668,7 @@ The top 16 bits of the control field are architecture specific control
>> flags which can include the following:
>>
>> - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86, arm64]
>> - - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390]
>> + - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390, arm64]
>> - KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
>> - KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
>> - KVM_GUESTDBG_EXIT_PENDING: trigger an immediate guest exit [s390]
>> @@ -2683,6 +2683,11 @@ updated to the correct (supplied) values.
>> The second part of the structure is architecture specific and
>> typically contains a set of debug registers.
>>
>> +For arm64 the number of debug registers is implementation defined and
>> +can be determined by querying the KVM_CAP_GUEST_DEBUG_HW_BPS and
>> +KVM_CAP_GUEST_DEBUG_HW_WPS capabilities which return a positive number
>> +indicating the number of supported registers.
>> +
>> When debug events exit the main run loop with the reason
>> KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run
>> structure containing architecture specific debug information.
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 0d17c7b..6df47c1 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -307,6 +307,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>>
>> #define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE | \
>> KVM_GUESTDBG_USE_SW_BP | \
>> + KVM_GUESTDBG_USE_HW_BP | \
>> KVM_GUESTDBG_SINGLESTEP)
>>
>> /**
>> @@ -327,6 +328,12 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>>
>> if (dbg->control & KVM_GUESTDBG_ENABLE) {
>> vcpu->guest_debug = dbg->control;
>> +
>> + /* Hardware assisted Break and Watch points */
>> + if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
>> + vcpu->arch.external_debug_state = dbg->arch;
>> + }
>> +
>> } else {
>> /* If not enabled clear all flags */
>> vcpu->guest_debug = 0;
>> diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
>> index 52b484b..c450552 100644
>> --- a/arch/arm64/include/asm/hw_breakpoint.h
>> +++ b/arch/arm64/include/asm/hw_breakpoint.h
>> @@ -130,6 +130,18 @@ static inline void ptrace_hw_copy_thread(struct task_struct *task)
>> }
>> #endif
>>
>> +/* Determine number of BRP registers available. */
>> +static inline int get_num_brps(void)
>> +{
>> + return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
>> +}
>> +
>> +/* Determine number of WRP registers available. */
>> +static inline int get_num_wrps(void)
>> +{
>> + return ((read_cpuid(ID_AA64DFR0_EL1) >> 20) & 0xf) + 1;
>> +}
>
> I'm fine with moving these into the header file, but we should probably
> revisit this at some point so that we use a shadow value to indicate the
> minimum number of registers across the system for e.g. big.LITTLE platforms
> that don't have uniform debug resources.
There is work going forward in QEMU to specify this limitation when
creating vcpus. At the moment the kernel sanity checks these are all the
same on boot up but I guess we will have to decide where the smarts will
end up. Do we:
- report the real number per real-cpu (QEMU figures out vcpu config)
or
- report the lowest common denominator
>
>> extern struct pmu perf_ops_bp;
>>
>> #endif /* __KERNEL__ */
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index e5040b6..498d4f7 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -113,12 +113,13 @@ struct kvm_vcpu_arch {
>>
>> /*
>> * For debugging the guest we need to keep a set of debug
>> - * registers which can override the guests own debug state
>> + * registers which can override the guest's own debug state
>> * while being used. These are set via the KVM_SET_GUEST_DEBUG
>> * ioctl.
>> */
>> struct kvm_guest_debug_arch *debug_ptr;
>> struct kvm_guest_debug_arch vcpu_debug_state;
>> + struct kvm_guest_debug_arch external_debug_state;
>>
>> /* Pointer to host CPU context */
>> kvm_cpu_context_t *host_cpu_context;
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 43758e7..95168c2 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -116,7 +116,7 @@ struct kvm_guest_debug_arch {
>>
>> struct kvm_debug_exit_arch {
>> __u32 hsr;
>> - __u64 far;
>> + __u64 far; /* used for watchpoints */
>
> Why not just add the comment with the field in your earlier patch?
I can fix that up if there is need to a re-spin.
--
Alex Bennée
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [PATCH v6 3/8] macvtap: introduce macvtap_is_little_endian() helper
From: Michael S. Tsirkin @ 2015-06-01 10:30 UTC (permalink / raw)
To: Greg Kurz
Cc: Thomas Huth, kvm, linux-api, linux-kernel, virtualization, netdev,
David Miller
In-Reply-To: <20150424122446.19156.93123.stgit@bahia.local>
On Fri, Apr 24, 2015 at 02:24:48PM +0200, Greg Kurz wrote:
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Dave, could you pls ack merging this through the virtio tree?
> ---
> drivers/net/macvtap.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 27ecc5c..a2f2958 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -49,14 +49,19 @@ struct macvtap_queue {
>
> #define MACVTAP_VNET_LE 0x80000000
>
> +static inline bool macvtap_is_little_endian(struct macvtap_queue *q)
> +{
> + return q->flags & MACVTAP_VNET_LE;
> +}
> +
> static inline u16 macvtap16_to_cpu(struct macvtap_queue *q, __virtio16 val)
> {
> - return __virtio16_to_cpu(q->flags & MACVTAP_VNET_LE, val);
> + return __virtio16_to_cpu(macvtap_is_little_endian(q), val);
> }
>
> static inline __virtio16 cpu_to_macvtap16(struct macvtap_queue *q, u16 val)
> {
> - return __cpu_to_virtio16(q->flags & MACVTAP_VNET_LE, val);
> + return __cpu_to_virtio16(macvtap_is_little_endian(q), val);
> }
>
> static struct proto macvtap_proto = {
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v6 2/8] tun: add tun_is_little_endian() helper
From: Michael S. Tsirkin @ 2015-06-01 10:29 UTC (permalink / raw)
To: Greg Kurz
Cc: Thomas Huth, kvm, linux-api, linux-kernel, virtualization, netdev,
David Miller
In-Reply-To: <20150424122435.19156.18985.stgit@bahia.local>
On Fri, Apr 24, 2015 at 02:24:38PM +0200, Greg Kurz wrote:
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Dave, could you please ack merging this through
the virtio tree?
> ---
> drivers/net/tun.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 857dca4..3c3d6c0 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -206,14 +206,19 @@ struct tun_struct {
> u32 flow_count;
> };
>
> +static inline bool tun_is_little_endian(struct tun_struct *tun)
> +{
> + return tun->flags & TUN_VNET_LE;
> +}
> +
> static inline u16 tun16_to_cpu(struct tun_struct *tun, __virtio16 val)
> {
> - return __virtio16_to_cpu(tun->flags & TUN_VNET_LE, val);
> + return __virtio16_to_cpu(tun_is_little_endian(tun), val);
> }
>
> static inline __virtio16 cpu_to_tun16(struct tun_struct *tun, u16 val)
> {
> - return __cpu_to_virtio16(tun->flags & TUN_VNET_LE, val);
> + return __cpu_to_virtio16(tun_is_little_endian(tun), val);
> }
>
> static inline u32 tun_hashfn(u32 rxhash)
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h
From: Christian König @ 2015-06-01 9:51 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mikko Rapeli, Krzysztof Kozlowski,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Seung-Woo Kim,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Kyungmin Park,
Kukjin Kim, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20150601093808.GP2067-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
On 01.06.2015 11:38, Russell King - ARM Linux wrote:
> On Mon, Jun 01, 2015 at 11:08:21AM +0200, Christian König wrote:
>> Yeah, completely agree with Linus on the visibility problem and that's
>> exactly the reason why we don't include <stdint.h> in the kernel header and
>> expect userspace to define the ISO types somewhere.
>>
>> But using the types from "include/linux/types.h" and especially including it
>> into the uapi headers doesn't make the situation better, but rather worse.
>>
>> With this step we not only make the headers depend on another header that
>> isn't part of the uapi, but also pollute the user space namespace with __sXX
>> and __uXX types which aren't defined anywhere else.
> 1) Header files are permitted to pollute userspace with __-defined stuff.
>
> 2) __[su]XX types are defined as part of the kernel's uapi.
> include/uapi/linux/types.h includes asm/types.h, which in userspace
> picks up include/uapi/asm-generic/types.h. That picks up
> asm-generic/int-ll64.h, which defines these types.
>
> Moreover, this is done throughout the kernel headers _already_ (as you
> would expect for a policy set 10+ years ago).
>
> Please, I'm not interested in this discussion, so please don't argue
> with me - I may agree with your position, but what you think and what
> I think are really not relevant here. If you have a problem, take it
> up with Linus - I made that clear in my email.
>
In this case I'm fine with the changes, but I'm still not sure if that's
a good idea or not.
Sticking to ISO C still sounds better than doing something on our own.
And it now looks a bit different than it was in 2004, stdint.h is widely
adopted in userspace if I'm not completely mistaken.
Anyway you're perfectly right that Linus need to decide and I'm not in
the mod to argue with him either (got way to much other things to do as
well).
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h
From: Russell King - ARM Linux @ 2015-06-01 9:38 UTC (permalink / raw)
To: Christian König
Cc: Mikko Rapeli, Krzysztof Kozlowski,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Seung-Woo Kim,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Kyungmin Park,
Kukjin Kim, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <556C2105.2090607-5C7GfCeVMHo@public.gmane.org>
On Mon, Jun 01, 2015 at 11:08:21AM +0200, Christian König wrote:
> Yeah, completely agree with Linus on the visibility problem and that's
> exactly the reason why we don't include <stdint.h> in the kernel header and
> expect userspace to define the ISO types somewhere.
>
> But using the types from "include/linux/types.h" and especially including it
> into the uapi headers doesn't make the situation better, but rather worse.
>
> With this step we not only make the headers depend on another header that
> isn't part of the uapi, but also pollute the user space namespace with __sXX
> and __uXX types which aren't defined anywhere else.
1) Header files are permitted to pollute userspace with __-defined stuff.
2) __[su]XX types are defined as part of the kernel's uapi.
include/uapi/linux/types.h includes asm/types.h, which in userspace
picks up include/uapi/asm-generic/types.h. That picks up
asm-generic/int-ll64.h, which defines these types.
Moreover, this is done throughout the kernel headers _already_ (as you
would expect for a policy set 10+ years ago).
Please, I'm not interested in this discussion, so please don't argue
with me - I may agree with your position, but what you think and what
I think are really not relevant here. If you have a problem, take it
up with Linus - I made that clear in my email.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH v5 10/12] KVM: arm64: guest debug, HW assisted debug support
From: Will Deacon @ 2015-06-01 9:15 UTC (permalink / raw)
To: Alex Bennée
Cc: kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org,
Marc Zyngier, peter.maydell@linaro.org, agraf@suse.de,
drjones@redhat.com, pbonzini@redhat.com, zhichao.huang@linaro.org,
jan.kiszka@siemens.com, dahi@linux.vnet.ibm.com,
r65777@freescale.com, bp@suse.de, Gleb Natapov, Jonathan Corbet,
Russell King, Catalin Marinas, Ingo Molnar, Pe
In-Reply-To: <1432891828-4816-11-git-send-email-alex.bennee@linaro.org>
Hi Alex,
On Fri, May 29, 2015 at 10:30:26AM +0100, Alex Bennée wrote:
> This adds support for userspace to control the HW debug registers for
> guest debug. In the debug ioctl we copy the IMPDEF defined number of
> registers into a new register set called host_debug_state. There is now
> a new vcpu parameter called debug_ptr which selects which register set
> is to copied into the real registers when world switch occurs.
>
> I've moved some helper functions into the hw_breakpoint.h header for
> re-use.
>
> As with single step we need to tweak the guest registers to enable the
> exceptions so we need to save and restore those bits.
>
> Two new capabilities have been added to the KVM_EXTENSION ioctl to allow
> userspace to query the number of hardware break and watch points
> available on the host hardware.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
[...]
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 33c8143..ada57df 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2668,7 +2668,7 @@ The top 16 bits of the control field are architecture specific control
> flags which can include the following:
>
> - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86, arm64]
> - - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390]
> + - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390, arm64]
> - KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
> - KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
> - KVM_GUESTDBG_EXIT_PENDING: trigger an immediate guest exit [s390]
> @@ -2683,6 +2683,11 @@ updated to the correct (supplied) values.
> The second part of the structure is architecture specific and
> typically contains a set of debug registers.
>
> +For arm64 the number of debug registers is implementation defined and
> +can be determined by querying the KVM_CAP_GUEST_DEBUG_HW_BPS and
> +KVM_CAP_GUEST_DEBUG_HW_WPS capabilities which return a positive number
> +indicating the number of supported registers.
> +
> When debug events exit the main run loop with the reason
> KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run
> structure containing architecture specific debug information.
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 0d17c7b..6df47c1 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -307,6 +307,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>
> #define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE | \
> KVM_GUESTDBG_USE_SW_BP | \
> + KVM_GUESTDBG_USE_HW_BP | \
> KVM_GUESTDBG_SINGLESTEP)
>
> /**
> @@ -327,6 +328,12 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>
> if (dbg->control & KVM_GUESTDBG_ENABLE) {
> vcpu->guest_debug = dbg->control;
> +
> + /* Hardware assisted Break and Watch points */
> + if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
> + vcpu->arch.external_debug_state = dbg->arch;
> + }
> +
> } else {
> /* If not enabled clear all flags */
> vcpu->guest_debug = 0;
> diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
> index 52b484b..c450552 100644
> --- a/arch/arm64/include/asm/hw_breakpoint.h
> +++ b/arch/arm64/include/asm/hw_breakpoint.h
> @@ -130,6 +130,18 @@ static inline void ptrace_hw_copy_thread(struct task_struct *task)
> }
> #endif
>
> +/* Determine number of BRP registers available. */
> +static inline int get_num_brps(void)
> +{
> + return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
> +}
> +
> +/* Determine number of WRP registers available. */
> +static inline int get_num_wrps(void)
> +{
> + return ((read_cpuid(ID_AA64DFR0_EL1) >> 20) & 0xf) + 1;
> +}
I'm fine with moving these into the header file, but we should probably
revisit this at some point so that we use a shadow value to indicate the
minimum number of registers across the system for e.g. big.LITTLE platforms
that don't have uniform debug resources.
> extern struct pmu perf_ops_bp;
>
> #endif /* __KERNEL__ */
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index e5040b6..498d4f7 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -113,12 +113,13 @@ struct kvm_vcpu_arch {
>
> /*
> * For debugging the guest we need to keep a set of debug
> - * registers which can override the guests own debug state
> + * registers which can override the guest's own debug state
> * while being used. These are set via the KVM_SET_GUEST_DEBUG
> * ioctl.
> */
> struct kvm_guest_debug_arch *debug_ptr;
> struct kvm_guest_debug_arch vcpu_debug_state;
> + struct kvm_guest_debug_arch external_debug_state;
>
> /* Pointer to host CPU context */
> kvm_cpu_context_t *host_cpu_context;
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 43758e7..95168c2 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -116,7 +116,7 @@ struct kvm_guest_debug_arch {
>
> struct kvm_debug_exit_arch {
> __u32 hsr;
> - __u64 far;
> + __u64 far; /* used for watchpoints */
Why not just add the comment with the field in your earlier patch?
Will
^ permalink raw reply
* Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h
From: Mikko Rapeli @ 2015-06-01 9:15 UTC (permalink / raw)
To: Christian König
Cc: Russell King - ARM Linux, Krzysztof Kozlowski,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Seung-Woo Kim,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Kyungmin Park,
Kukjin Kim, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <556C15BA.7000909-5C7GfCeVMHo@public.gmane.org>
On Mon, Jun 01, 2015 at 10:20:10AM +0200, Christian König wrote:
> Additional to that "linux/types.h" is not part of the uapi as far as
> I know, so including it in a header which is part of the uapi should
> be forbidden.
linux/types.h is part of uapi. See usr/include after 'make headers_install'.
-Mikko
^ permalink raw reply
* Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h
From: Frans Klaver @ 2015-06-01 9:14 UTC (permalink / raw)
To: Christian König
Cc: Russell King - ARM Linux, Krzysztof Kozlowski, linux-samsung-soc,
Mikko Rapeli, Seung-Woo Kim, linux-kernel@vger.kernel.org,
DRI mailing list, Kyungmin Park, Kukjin Kim, linux-api,
linux-arm-kernel
In-Reply-To: <556C2105.2090607@amd.com>
On Mon, Jun 1, 2015 at 11:08 AM, Christian König
<christian.koenig@amd.com> wrote:
> Yeah, completely agree with Linus on the visibility problem and that's
> exactly the reason why we don't include <stdint.h> in the kernel header and
> expect userspace to define the ISO types somewhere.
>
> But using the types from "include/linux/types.h" and especially including it
> into the uapi headers doesn't make the situation better, but rather worse.
>
> With this step we not only make the headers depend on another header that
> isn't part of the uapi, but also pollute the user space namespace with __sXX
> and __uXX types which aren't defined anywhere else.
These __uXX and __sXX types are defined in
include/uapi/asm-generic/ll64.h and pulled in by
include/uapi/linux/types.h. Including linux/types.h is therefore
valid.
Frans
^ permalink raw reply
* Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h
From: Christian König @ 2015-06-01 9:08 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mikko Rapeli, Krzysztof Kozlowski,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Seung-Woo Kim,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Kyungmin Park,
Kukjin Kim, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20150601085605.GN2067-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
Yeah, completely agree with Linus on the visibility problem and that's
exactly the reason why we don't include <stdint.h> in the kernel header
and expect userspace to define the ISO types somewhere.
But using the types from "include/linux/types.h" and especially
including it into the uapi headers doesn't make the situation better,
but rather worse.
With this step we not only make the headers depend on another header
that isn't part of the uapi, but also pollute the user space namespace
with __sXX and __uXX types which aren't defined anywhere else.
Regards,
Christian.
On 01.06.2015 10:56, Russell King - ARM Linux wrote:
> On Mon, Jun 01, 2015 at 10:20:10AM +0200, Christian König wrote:
>> Using types that differs on 32-bit and 64-bit machines for a kernel
>> interface is indeed a rather bad idea. This not only includes longs, but
>> pointers as well.
> [cut standard stdint.h types argument which we've heard before]
>
> You need to read Linus' rant on this subject:
>
> From: Linus Torvalds <torvalds-3NddpPZAyC0@public.gmane.org>
> Subject: Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
> Date: Mon, 29 Nov 2004 01:30:46 GMT
>
> Ok, this discussion has gone on for too long anyway, but let's make it
> easier for everybody. The kernel uses u8/u16/u32 because:
>
> - the kernel should not depend on, or pollute user-space naming.
> YOU MUST NOT USE "uint32_t" when that may not be defined, and
> user-space rules for when it is defined are arcane and totally
> arbitrary.
>
> - since the kernel cannot use those types for anything that is
> visible to user space anyway, there has to be alternate names.
> The tradition is to prepend two underscores, so the kernel would
> have to use "__uint32_t" etc for its header files.
>
> - at that point, there's no longer any valid argument that it's a
> "standard type" (it ain't), and I personally find it a lot more
> readable to just use the types that the kernel has always used:
> __u8/__u16/__u32. For stuff that is only used for the kernel,
> the shorter "u8/u16/u32" versions may be used.
>
> In short: having the kernel use the same names as user space is ACTIVELY
> BAD, exactly because those names have standards-defined visibility, which
> means that the kernel _cannot_ use them in all places anyway. So don't
> even _try_.
>
^ permalink raw reply
* Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h
From: Russell King - ARM Linux @ 2015-06-01 8:56 UTC (permalink / raw)
To: Christian König
Cc: Mikko Rapeli, Krzysztof Kozlowski,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Seung-Woo Kim,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Kyungmin Park,
Kukjin Kim, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <556C15BA.7000909-5C7GfCeVMHo@public.gmane.org>
On Mon, Jun 01, 2015 at 10:20:10AM +0200, Christian König wrote:
> Using types that differs on 32-bit and 64-bit machines for a kernel
> interface is indeed a rather bad idea. This not only includes longs, but
> pointers as well.
[cut standard stdint.h types argument which we've heard before]
You need to read Linus' rant on this subject:
From: Linus Torvalds <torvalds-3NddpPZAyC0@public.gmane.org>
Subject: Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
Date: Mon, 29 Nov 2004 01:30:46 GMT
Ok, this discussion has gone on for too long anyway, but let's make it
easier for everybody. The kernel uses u8/u16/u32 because:
- the kernel should not depend on, or pollute user-space naming.
YOU MUST NOT USE "uint32_t" when that may not be defined, and
user-space rules for when it is defined are arcane and totally
arbitrary.
- since the kernel cannot use those types for anything that is
visible to user space anyway, there has to be alternate names.
The tradition is to prepend two underscores, so the kernel would
have to use "__uint32_t" etc for its header files.
- at that point, there's no longer any valid argument that it's a
"standard type" (it ain't), and I personally find it a lot more
readable to just use the types that the kernel has always used:
__u8/__u16/__u32. For stuff that is only used for the kernel,
the shorter "u8/u16/u32" versions may be used.
In short: having the kernel use the same names as user space is ACTIVELY
BAD, exactly because those names have standards-defined visibility, which
means that the kernel _cannot_ use them in all places anyway. So don't
even _try_.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h
From: Christian König @ 2015-06-01 8:20 UTC (permalink / raw)
To: Russell King - ARM Linux, Mikko Rapeli
Cc: Krzysztof Kozlowski, linux-samsung-soc, linux-api, Seung-Woo Kim,
linux-kernel, dri-devel, Kyungmin Park, Kukjin Kim,
linux-arm-kernel
In-Reply-To: <20150530164655.GM2067@n2100.arm.linux.org.uk>
On 30.05.2015 18:46, Russell King - ARM Linux wrote:
> On Sat, May 30, 2015 at 05:37:57PM +0200, Mikko Rapeli wrote:
>> Fixes userspace compilation error:
>>
>> drm/exynos_drm.h:30:2: error: unknown type name ‘uint64_t’
>>
>> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> This is another thing which we need to address. We should not be using
> unsigned int/unsigned long/uintXX_t/etc in here, but the __uXX and __sXX
> types.
>
> The lesson learned from other DRM developers is that using these types
> simplifies the API especially when it comes to the differences between
> 32-bit and 64-bit machines, and compat applications.
>
> Note that drm/drm.h is all that should need to be included - drm/drm.h
> takes care of including linux/types.h when building on Linux platforms.
> (note: if your compiler doesn't set __linux__ then you're probably not
> using the proper compiler...)
>
Using types that differs on 32-bit and 64-bit machines for a kernel
interface is indeed a rather bad idea. This not only includes longs, but
pointers as well.
But the int8_t, int16_t int32_t, int64_t and their unsigned counterparts
are defined in stdint.h which is part of the ISO/IEC 9899:1999 standard,
similar is true for size_t.
The __uXX, __sXX and _kernel_size_t types are linux specific as far as I
know.
For best interoperability and standard conformance I think that
definitions from the C standard we use should out-rule linux specific
definitions.
Additional to that "linux/types.h" is not part of the uapi as far as I
know, so including it in a header which is part of the uapi should be
forbidden.
So this is a NAK from my side for the whole series, userspace programs
should include <stdint.h> for the definition of the ISO/IEC 9899:1999
standard types if necessary.
Regards,
Christian.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 4/5] serial: stm32-usart: Add STM32 USART Driver
From: Greg Kroah-Hartman @ 2015-05-31 21:52 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Arnd Bergmann, Daniel Lezcano, Daniel Thompson, Kamil Lulko,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ, afaerber-l3A5Bk7waGM,
geert-Td1EMuHUCqxL1ZNQvxDV9g, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Thomas Gleixner, Jiri Slaby, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1432328616-16964-5-git-send-email-mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, May 22, 2015 at 11:03:35PM +0200, Maxime Coquelin wrote:
> This drivers adds support to the STM32 USART controller, which is a
> standard serial driver.
>
> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
^ permalink raw reply
* Re: [PATCH 67/98] include/uapi/linux/netfilter/ipset/ip_set_bitmap.h: include linux/netfilter/ipset/ip_set.h
From: Jozsef Kadlecsik @ 2015-05-31 18:15 UTC (permalink / raw)
To: Mikko Rapeli
Cc: linux-kernel, Pablo Neira Ayuso, Patrick McHardy, netfilter-devel,
coreteam, linux-api
In-Reply-To: <1433000370-19509-68-git-send-email-mikko.rapeli@iki.fi>
On Sat, 30 May 2015, Mikko Rapeli wrote:
> Fixes userspace compilation error:
>
> error: ?IPSET_ERR_TYPE_SPECIFIC? undeclared here (not in a function)
> IPSET_ERR_BITMAP_RANGE = IPSET_ERR_TYPE_SPECIFIC,
What kind of userspace compilation generates the error message above? How
can one reproduce it?
Best regards,
Jozsef
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> ---
> include/uapi/linux/netfilter/ipset/ip_set_bitmap.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/netfilter/ipset/ip_set_bitmap.h b/include/uapi/linux/netfilter/ipset/ip_set_bitmap.h
> index 6a2c038..fd5024d 100644
> --- a/include/uapi/linux/netfilter/ipset/ip_set_bitmap.h
> +++ b/include/uapi/linux/netfilter/ipset/ip_set_bitmap.h
> @@ -1,6 +1,8 @@
> #ifndef _UAPI__IP_SET_BITMAP_H
> #define _UAPI__IP_SET_BITMAP_H
>
> +#include <linux/netfilter/ipset/ip_set.h>
> +
> /* Bitmap type specific error codes */
> enum {
> /* The element is out of the range of the set */
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH for v4.2 v18 1/3] sys_membarrier(): system-wide memory barrier (generic, x86)
From: Mathieu Desnoyers @ 2015-05-31 12:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Paul E. McKenney, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-api,
KOSAKI Motohiro, rostedt, Nicholas Miell, Linus Torvalds,
Ingo Molnar, One Thousand Gnomes, Lai Jiangshan,
Stephen Hemminger, Thomas Gleixner, Peter Zijlstra, David Howells,
Pranith Kumar, Michael Kerrisk
In-Reply-To: <20150529154036.9695b6c153ed37aed3343f3b-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
----- On May 30, 2015, at 12:40 AM, Andrew Morton akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
> On Sat, 16 May 2015 19:48:18 -0400 Mathieu Desnoyers
> <mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org> wrote:
>
>> Here is an implementation of a new system call, sys_membarrier(), which
>> executes a memory barrier on all threads running on the system. It is
>> implemented by calling synchronize_sched(). It can be used to distribute
>> the cost of user-space memory barriers asymmetrically by transforming
>> pairs of memory barriers into pairs consisting of sys_membarrier() and a
>> compiler barrier. For synchronization primitives that distinguish
>> between read-side and write-side (e.g. userspace RCU [1], rwlocks), the
>> read-side can be accelerated significantly by moving the bulk of the
>> memory barrier overhead to the write-side.
>>
>> ...
>>
>
> It would be nice to hear about the real world value of this syscall to
> our users. I'm seeing test results for a microbenchmark but so what.
> What actual applications or application classes are calling for this and
> what results can they expect to see?
AFAIK, the existing open source applications that would be improved by this
system call are as follows:
* Through Userspace RCU library (http://urcu.so)
- DNS server (Knot DNS) https://www.knot-dns.cz/
- Network sniffer (http://netsniff-ng.org/)
- Distributed object storage (https://sheepdog.github.io/sheepdog/)
- User-space tracing (http://lttng.org)
- Network storage system (https://www.gluster.org/)
Those projects use RCU in userspace to increase read-side speed and
scalability compared to locking. Especially in the case of RCU used
by libraries, sys_membarrier can speed up the read-side by moving the
bulk of the memory barrier cost to synchronize_rcu().
* Direct users of sys_membarrier
- core dotnet garbage collector (https://github.com/dotnet/coreclr/issues/198)
Microsoft core dotnet GC developers are planning to use the mprotect()
side-effect of issuing memory barriers through IPIs as a way to implement Windows
FlushProcessWriteBuffers() on Linux. They are referring to sys_membarrier in their
github thread, specifically stating that sys_membarrier() is what they are looking
for.
>
>>
>> membarrier(2) man page:
>> --------------- snip -------------------
>> MEMBARRIER(2) Linux Programmer's Manual MEMBARRIER(2)
>>
>> NAME
>> membarrier - issue memory barriers on a set of threads
>>
>> SYNOPSIS
>> #include <linux/membarrier.h>
>>
>> int membarrier(int cmd, int flags);
>>
>> DESCRIPTION
>> The cmd argument is one of the following:
>>
>> MEMBARRIER_CMD_QUERY
>> Query the set of supported commands. It returns a bitmask of
>> supported commands.
>>
>> MEMBARRIER_CMD_SHARED
>> Execute a memory barrier on all threads running on the system.
>> Upon return from system call, the caller thread is ensured that
>> all running threads have passed through a state where all memory
>> accesses to user-space addresses match program order between
>> entry to and return from the system call (non-running threads
>> are de facto in such a state). This covers threads from all pro___
>> cesses running on the system. This command returns 0.
>>
>> The flags argument needs to be 0. For future extensions.
>>
>> All memory accesses performed in program order from each targeted
>> thread is guaranteed to be ordered with respect to sys_membarrier(). If
>> we use the semantic "barrier()" to represent a compiler barrier forcing
>> memory accesses to be performed in program order across the barrier,
>> and smp_mb() to represent explicit memory barriers forcing full memory
>> ordering across the barrier, we have the following ordering table for
>> each pair of barrier(), sys_membarrier() and smp_mb():
>>
>> The pair ordering is detailed as (O: ordered, X: not ordered):
>>
>> barrier() smp_mb() sys_membarrier()
>> barrier() X X O
>> smp_mb() X O O
>> sys_membarrier() O O O
>>
>> RETURN VALUE
>> On success, these system calls return zero. On error, -1 is returned,
>> and errno is set appropriately. For a given command, with flags
>> argument set to 0, this system call is guaranteed to always return the
>> same value until reboot.
>
> I suggest "with flags argument set to MEMBARRIER_CMD_QUERY" here.
No, the enum is for the "cmd" argument (see above) not the flags argument. We
really mean flags = 0 (the value) here.
>
>>
>> ERRORS
>> ENOSYS System call is not implemented.
>>
>> EINVAL Invalid arguments.
>>
>> ...
>>
>> +SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
>> +{
>> + if (flags)
>> + return -EINVAL;
>
> I'm not a huge fan of this "add a flags arg to syscalls" rule. Is
> there any realistic expectation that we'll ever *use* this thing? If
> not, why add it?
I can see this system call evolve in a few ways in the future, such as
having an expedited version (using IPIs), targeting the local thread
group, and targeting all threads mapping a specific shared memory mapping.
I guess that the cmd argument should be enough to cover that, but
in doubt, it might be better to keep a flags argument there for future
needs we might be overlooking right now, so we never end up needing a
sys_membarrier2 system call.
>
> You may as well put an unlikely() in there btw.
Will do.
Thanks!
Mathieu
>
>> + switch (cmd) {
>> + case MEMBARRIER_CMD_QUERY:
>> + return MEMBARRIER_CMD_BITMASK;
>> + case MEMBARRIER_CMD_SHARED:
>> + if (num_online_cpus() > 1)
>> + synchronize_sched();
>> + return 0;
>> + default:
>> + return -EINVAL;
>> + }
> > +}
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH 96/98] HACK include/uapi/linux/coda_psdev.h: fix compilation in userspace
From: Jan Harkes @ 2015-05-31 11:19 UTC (permalink / raw)
To: Mikko Rapeli; +Cc: linux-kernel, linux-api
In-Reply-To: <1433000370-19509-97-git-send-email-mikko.rapeli@iki.fi>
On Sat, May 30, 2015 at 05:39:28PM +0200, Mikko Rapeli wrote:
> Include linux/coda.h for caddr_t and use unsigned short type directly.
> Userspace headers do not have list_head and wait_queue_head_t so just
> ifdef them away which is a HACK. Any ideas how to fix this properly?
I grepped the Coda userspace sources and it doesn't look like this
particular struct is used there anyway, it is only used by the kernel
module to track which requests are waiting to be read by the Coda
userspace application and after that which requests are waiting for a
response.
I guess a proper fix would be to move this struct to a non-uapi header,
or maybe even to the (probably) only C file in the kernel where it is
used.
Jan
^ permalink raw reply
* Re: [PATCH 18/98] include/uapi/sound/emu10k1.h: added EMU10K1 version of DECLARE_BITMAP etc macros
From: Takashi Iwai @ 2015-05-31 8:12 UTC (permalink / raw)
To: Mikko Rapeli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jaroslav Kysela,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <s5h8uc58ba6.wl-tiwai-l3A5Bk7waGM@public.gmane.org>
At Sun, 31 May 2015 09:18:57 +0200,
Takashi Iwai wrote:
>
> At Sat, 30 May 2015 17:38:10 +0200,
> Mikko Rapeli wrote:
> >
> > Fixes userspace compilation error:
> >
> > error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’
> > DECLARE_BITMAP(gpr_valid, 0x200); /* bitmask of valid initializers */
> >
> > DECLARE_BITMAP etc macros are not meant for userspace headers and thus
> > added here as private copies for emu10k.h.
> >
> > Fix was suggested by Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> in message
> > <2168807.4Yxh5gl11Q@wuerfel> on lkml.
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> > ---
> > include/uapi/sound/emu10k1.h | 23 ++++++++++++++++++++---
> > 1 file changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/uapi/sound/emu10k1.h b/include/uapi/sound/emu10k1.h
> > index ec1535b..7575f0f 100644
> > --- a/include/uapi/sound/emu10k1.h
> > +++ b/include/uapi/sound/emu10k1.h
> > @@ -34,6 +34,23 @@
> >
> > #define EMU10K1_FX8010_PCM_COUNT 8
> >
> > +/*
> > + * Following definitions are copies from kernel headers to support compiling
> > + * this header file in userspace. The definitions are not generally available
> > + * in uapi headers so the needed things are copied here wtih __EMU10k1 prefix.
> > + */
> > +
> > +/* From include/linux/bitops.h */
> > +#define __EMU10K1_BITS_PER_BYTE 8
> > +/* From include/linux/kernel.h */
> > +#define __EMU10K1_DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
> > +/* From include/linux/bitops.h */
> > +#define __EMU10K1_BITS_TO_LONGS(nr) \
> > + __EMU10K1_DIV_ROUND_UP(nr, __EMU10K1_BITS_PER_BYTE * sizeof(long))
> > +/* From include/linux/types.h */
> > +#define __EMU10K1_DECLARE_BITMAP(name,bits) \
> > + unsigned long name[__EMU10K1_BITS_TO_LONGS(bits)]
>
> This is way too complicated just for a few expansion of the aligned
> size arrays, IMO. Rather simplify it like below with a comment:
>
> /* the array must be aligned to unsigned long (i.e. 4 or 8 bytes) */
> #define __EMU10K1_DECLARE_BITMAP(name) \
> unsigned long name[(bits) / sizeof(unsigned long)]
Crap, of course, it must be multiplied with 8.
/* the array must be aligned to unsigned long (i.e. 32 or 64) */
#define __EMU10K1_DECLARE_BITMAP(name) \
unsigned long name[(bits) / (sizeof(unsigned long) * 8)]
Takashi
^ permalink raw reply
* Re: [PATCH 18/98] include/uapi/sound/emu10k1.h: added EMU10K1 version of DECLARE_BITMAP etc macros
From: Takashi Iwai @ 2015-05-31 7:18 UTC (permalink / raw)
To: Mikko Rapeli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jaroslav Kysela,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1433000370-19509-19-git-send-email-mikko.rapeli-X3B1VOXEql0@public.gmane.org>
At Sat, 30 May 2015 17:38:10 +0200,
Mikko Rapeli wrote:
>
> Fixes userspace compilation error:
>
> error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’
> DECLARE_BITMAP(gpr_valid, 0x200); /* bitmask of valid initializers */
>
> DECLARE_BITMAP etc macros are not meant for userspace headers and thus
> added here as private copies for emu10k.h.
>
> Fix was suggested by Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> in message
> <2168807.4Yxh5gl11Q@wuerfel> on lkml.
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> ---
> include/uapi/sound/emu10k1.h | 23 ++++++++++++++++++++---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/sound/emu10k1.h b/include/uapi/sound/emu10k1.h
> index ec1535b..7575f0f 100644
> --- a/include/uapi/sound/emu10k1.h
> +++ b/include/uapi/sound/emu10k1.h
> @@ -34,6 +34,23 @@
>
> #define EMU10K1_FX8010_PCM_COUNT 8
>
> +/*
> + * Following definitions are copies from kernel headers to support compiling
> + * this header file in userspace. The definitions are not generally available
> + * in uapi headers so the needed things are copied here wtih __EMU10k1 prefix.
> + */
> +
> +/* From include/linux/bitops.h */
> +#define __EMU10K1_BITS_PER_BYTE 8
> +/* From include/linux/kernel.h */
> +#define __EMU10K1_DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
> +/* From include/linux/bitops.h */
> +#define __EMU10K1_BITS_TO_LONGS(nr) \
> + __EMU10K1_DIV_ROUND_UP(nr, __EMU10K1_BITS_PER_BYTE * sizeof(long))
> +/* From include/linux/types.h */
> +#define __EMU10K1_DECLARE_BITMAP(name,bits) \
> + unsigned long name[__EMU10K1_BITS_TO_LONGS(bits)]
This is way too complicated just for a few expansion of the aligned
size arrays, IMO. Rather simplify it like below with a comment:
/* the array must be aligned to unsigned long (i.e. 4 or 8 bytes) */
#define __EMU10K1_DECLARE_BITMAP(name) \
unsigned long name[(bits) / sizeof(unsigned long)]
or expand as is at each place like:
unsigned long gpr_valid[0x200 / sizeof(unsigned long)];
thanks,
Takashi
> /* instruction set */
> #define iMAC0 0x00 /* R = A + (X * Y >> 31) ; saturation */
> #define iMAC1 0x01 /* R = A + (-X * Y >> 31) ; saturation */
> @@ -300,7 +317,7 @@ struct snd_emu10k1_fx8010_control_old_gpr {
> struct snd_emu10k1_fx8010_code {
> char name[128];
>
> - DECLARE_BITMAP(gpr_valid, 0x200); /* bitmask of valid initializers */
> + __EMU10K1_DECLARE_BITMAP(gpr_valid, 0x200); /* bitmask of valid initializers */
> __u32 __user *gpr_map; /* initializers */
>
> unsigned int gpr_add_control_count; /* count of GPR controls to add/replace */
> @@ -313,11 +330,11 @@ struct snd_emu10k1_fx8010_code {
> unsigned int gpr_list_control_total; /* total count of GPR controls */
> struct snd_emu10k1_fx8010_control_gpr __user *gpr_list_controls; /* listed GPR controls */
>
> - DECLARE_BITMAP(tram_valid, 0x100); /* bitmask of valid initializers */
> + __EMU10K1_DECLARE_BITMAP(tram_valid, 0x100); /* bitmask of valid initializers */
> __u32 __user *tram_data_map; /* data initializers */
> __u32 __user *tram_addr_map; /* map initializers */
>
> - DECLARE_BITMAP(code_valid, 1024); /* bitmask of valid instructions */
> + __EMU10K1_DECLARE_BITMAP(code_valid, 1024); /* bitmask of valid instructions */
> __u32 __user *code; /* one instruction - 64 bits */
> };
>
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH 30/98] hdspm.h: use __u8, __u32 and __u64 from linux/types.h
From: Takashi Iwai @ 2015-05-31 7:11 UTC (permalink / raw)
To: Mikko Rapeli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jaroslav Kysela,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1433000370-19509-31-git-send-email-mikko.rapeli-X3B1VOXEql0@public.gmane.org>
At Sat, 30 May 2015 17:38:22 +0200,
Mikko Rapeli wrote:
>
> Fixes userspace compilation errors like:
>
> sound/hdspm.h:43:2: error: unknown type name ‘uint32_t’
Hmm, how do you get this error at all?
The header includes stdint.h for user-space.
thanks,
Takashi
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> ---
> include/uapi/sound/hdspm.h | 40 ++++++++++++++++++----------------------
> 1 file changed, 18 insertions(+), 22 deletions(-)
>
> diff --git a/include/uapi/sound/hdspm.h b/include/uapi/sound/hdspm.h
> index 5737332..c4db6f5 100644
> --- a/include/uapi/sound/hdspm.h
> +++ b/include/uapi/sound/hdspm.h
> @@ -20,11 +20,7 @@
> * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> */
>
> -#ifdef __KERNEL__
> #include <linux/types.h>
> -#else
> -#include <stdint.h>
> -#endif
>
> /* Maximum channels is 64 even on 56Mode you have 64playbacks to matrix */
> #define HDSPM_MAX_CHANNELS 64
> @@ -46,15 +42,15 @@ enum hdspm_speed {
> /* -------------------- IOCTL Peak/RMS Meters -------------------- */
>
> struct hdspm_peak_rms {
> - uint32_t input_peaks[64];
> - uint32_t playback_peaks[64];
> - uint32_t output_peaks[64];
> + __u32 input_peaks[64];
> + __u32 playback_peaks[64];
> + __u32 output_peaks[64];
>
> - uint64_t input_rms[64];
> - uint64_t playback_rms[64];
> - uint64_t output_rms[64];
> + __u64 input_rms[64];
> + __u64 playback_rms[64];
> + __u64 output_rms[64];
>
> - uint8_t speed; /* enum {ss, ds, qs} */
> + __u8 speed; /* enum {ss, ds, qs} */
> int status2;
> };
>
> @@ -155,21 +151,21 @@ enum hdspm_syncsource {
> };
>
> struct hdspm_status {
> - uint8_t card_type; /* enum hdspm_io_type */
> + __u8 card_type; /* enum hdspm_io_type */
> enum hdspm_syncsource autosync_source;
>
> - uint64_t card_clock;
> - uint32_t master_period;
> + __u64 card_clock;
> + __u32 master_period;
>
> union {
> struct {
> - uint8_t sync_wc; /* enum hdspm_sync */
> - uint8_t sync_madi; /* enum hdspm_sync */
> - uint8_t sync_tco; /* enum hdspm_sync */
> - uint8_t sync_in; /* enum hdspm_sync */
> - uint8_t madi_input; /* enum hdspm_madi_input */
> - uint8_t channel_format; /* enum hdspm_madi_channel_format */
> - uint8_t frame_format; /* enum hdspm_madi_frame_format */
> + __u8 sync_wc; /* enum hdspm_sync */
> + __u8 sync_madi; /* enum hdspm_sync */
> + __u8 sync_tco; /* enum hdspm_sync */
> + __u8 sync_in; /* enum hdspm_sync */
> + __u8 madi_input; /* enum hdspm_madi_input */
> + __u8 channel_format; /* enum hdspm_madi_channel_format */
> + __u8 frame_format; /* enum hdspm_madi_frame_format */
> } madi;
> } card_specific;
> };
> @@ -184,7 +180,7 @@ struct hdspm_status {
> #define HDSPM_ADDON_TCO 1
>
> struct hdspm_version {
> - uint8_t card_type; /* enum hdspm_io_type */
> + __u8 card_type; /* enum hdspm_io_type */
> char cardname[20];
> unsigned int serial;
> unsigned short firmware_rev;
> --
> 2.1.4
>
^ permalink raw reply
* [RFC 23/24] m68k/mac: Fix PRAM accessors
From: Finn Thain @ 2015-05-31 1:01 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-m68k-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Geert Uytterhoeven,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150531010132.289674310@telegraphics.com.au>
[-- Attachment #1: fix-mac-pram-accessors --]
[-- Type: text/plain, Size: 2975 bytes --]
Signed-off-by: Finn Thain <fthain-PnMVE5gNl/W9dxLkCovUHLpzq4S04n8Q@public.gmane.org>
---
Tested on a PowerBook 520 and Quadra 650.
---
arch/m68k/mac/misc.c | 35 +++++++++++++++++++++++++++++------
include/uapi/linux/pmu.h | 2 ++
2 files changed, 31 insertions(+), 6 deletions(-)
Index: linux/arch/m68k/mac/misc.c
===================================================================
--- linux.orig/arch/m68k/mac/misc.c 2015-05-31 11:01:26.000000000 +1000
+++ linux/arch/m68k/mac/misc.c 2015-05-31 11:01:28.000000000 +1000
@@ -124,19 +124,22 @@ static void pmu_write_time(long data)
static unsigned char pmu_pram_read_byte(int offset)
{
struct adb_request req;
- if (pmu_request(&req, NULL, 3, PMU_READ_NVRAM,
- (offset >> 8) & 0xFF, offset & 0xFF) < 0)
+
+ if (pmu_request(&req, NULL, 3, PMU_READ_XPRAM,
+ offset & 0xFF, 1) < 0)
return 0;
while (!req.complete)
pmu_poll();
- return req.reply[3];
+
+ return req.reply[1];
}
static void pmu_pram_write_byte(unsigned char data, int offset)
{
struct adb_request req;
- if (pmu_request(&req, NULL, 4, PMU_WRITE_NVRAM,
- (offset >> 8) & 0xFF, offset & 0xFF, data) < 0)
+
+ if (pmu_request(&req, NULL, 4, PMU_WRITE_XPRAM,
+ offset & 0xFF, 1, data) < 0)
return;
while (!req.complete)
pmu_poll();
@@ -295,11 +298,31 @@ static void via_pram_command(int command
#if IS_ENABLED(CONFIG_NVRAM)
static unsigned char via_pram_read_byte(int offset)
{
- return 0;
+ unsigned char temp;
+ int addr = ((offset & 0xE0) << 3) | ((offset & 0x1F) << 2);
+
+ /* Use RTC command 0x38 for XPRAM access, as per MESS source code */
+ via_pram_command(addr | 0x3800 | 0x8001, &temp);
+
+ return temp;
}
static void via_pram_write_byte(unsigned char data, int offset)
{
+ unsigned char temp;
+ int addr = ((offset & 0xE0) << 3) | ((offset & 0x1F) << 2);
+
+ /* Clear the write protect bit */
+ temp = 0x55;
+ via_pram_command(0x34 | 0x01, &temp);
+
+ /* Write the byte to XPRAM */
+ temp = data;
+ via_pram_command(0x3800 | 0x0001 | addr, &temp);
+
+ /* Set the write protect bit */
+ temp = 0xD5;
+ via_pram_command(0x34 | 0x01, &temp);
}
#endif /* CONFIG_NVRAM */
Index: linux/include/uapi/linux/pmu.h
===================================================================
--- linux.orig/include/uapi/linux/pmu.h 2015-05-31 11:00:59.000000000 +1000
+++ linux/include/uapi/linux/pmu.h 2015-05-31 11:01:28.000000000 +1000
@@ -18,7 +18,9 @@
#define PMU_POWER_CTRL 0x11 /* control power of some devices */
#define PMU_ADB_CMD 0x20 /* send ADB packet */
#define PMU_ADB_POLL_OFF 0x21 /* disable ADB auto-poll */
+#define PMU_WRITE_XPRAM 0x32 /* write eXtended Parameter RAM */
#define PMU_WRITE_NVRAM 0x33 /* write non-volatile RAM */
+#define PMU_READ_XPRAM 0x3a /* read eXtended Parameter RAM */
#define PMU_READ_NVRAM 0x3b /* read non-volatile RAM */
#define PMU_SET_RTC 0x30 /* set real-time clock */
#define PMU_READ_RTC 0x38 /* read real-time clock */
^ 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