* Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature
From: Christoph Lameter @ 2016-11-08 23:42 UTC (permalink / raw)
To: Steven Rostedt
Cc: Daniel Bristot de Oliveira, Daniel Bristot de Oliveira,
Ingo Molnar, Peter Zijlstra, linux-rt-users, LKML
In-Reply-To: <20161107151617.486b1b42@gandalf.local.home>
On Mon, 7 Nov 2016, Steven Rostedt wrote:
> On Mon, 7 Nov 2016 21:06:50 +0100
> Daniel Bristot de Oliveira <daniel@bristot.me> wrote:
>
> > The throttling allowed the kworker to run, but once the kworker went to
> > sleep, the RT tasks started to work again. In the previous behavior,
> > the system would either go idle, or the kworker would starve because
> > the runtime become infinity for RR tasks.
>
> I'm confused? Are you saying that RR tasks don't get throttled in the
> current code? That sounds like a bug to me.
Good. Thats what I wanted to hear after all these justifications that the
system is just behaving as designed.
^ permalink raw reply
* Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups
From: Kees Cook @ 2016-11-08 23:41 UTC (permalink / raw)
To: John Stultz
Cc: lkml, Tejun Heo, Li Zefan, Jonathan Corbet, Cgroups,
Android Kernel Team, Rom Lemarchand, Colin Cross, Dmitry Shmidt,
Todd Kjos, Christian Poetzsch, Amit Pundir, Dmitry Torokhov,
Serge E . Hallyn, Linux API
In-Reply-To: <1478647728-30357-1-git-send-email-john.stultz@linaro.org>
On Tue, Nov 8, 2016 at 3:28 PM, John Stultz <john.stultz@linaro.org> wrote:
> This patch adds logic to allows a process to migrate other tasks
> between cgroups if they have CAP_SYS_RESOURCE.
>
> In Android (where this feature originated), the ActivityManager tracks
> various application states (TOP_APP, FOREGROUND, BACKGROUND, SYSTEM,
> etc), and then as applications change states, the SchedPolicy logic
> will migrate the application tasks between different cgroups used
> to control the different application states (for example, there is a
> background cpuset cgroup which can limit background tasks to stay
> on one low-power cpu, and the bg_non_interactive cpuctrl cgroup can
> then further limit those background tasks to a small percentage of
> that one cpu's cpu time).
>
> However, for security reasons, Android doesn't want to make the
> system_server (the process that runs the ActivityManager and
> SchedPolicy logic), run as root. So in the Android common.git
> kernel, they have some logic to allow cgroups to loosen their
> permissions so CAP_SYS_NICE tasks can migrate other tasks between
> cgroups.
>
> I feel the approach taken there overloads CAP_SYS_NICE a bit much
> for non-android environments.
>
> So this patch, as suggested by Michael Kerrisk, simply adds a
> check for CAP_SYS_RESOURCE.
>
> I've tested this with AOSP master, and this seems to work well
> as Zygote and system_server already use CAP_SYS_RESOURCE. I've
> also submitted patches against the android-4.4 kernel to change
> it to use CAP_SYS_RESOURCE, and the Android developers just merged
> it.
>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Li Zefan <lizefan@huawei.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: cgroups@vger.kernel.org
> Cc: Android Kernel Team <kernel-team@android.com>
> Cc: Rom Lemarchand <romlem@android.com>
> Cc: Colin Cross <ccross@android.com>
> Cc: Dmitry Shmidt <dimitrysh@google.com>
> Cc: Todd Kjos <tkjos@google.com>
> Cc: Christian Poetzsch <christian.potzsch@imgtec.com>
> Cc: Amit Pundir <amit.pundir@linaro.org>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> Cc: linux-api@vger.kernel.org
> Acked-by: Serge Hallyn <serge@hallyn.com>
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
> v2: Renamed to just CAP_CGROUP_MIGRATE as recommended by Tejun
> v3: Switched to just using CAP_SYS_RESOURCE as suggested by Michael
> v4: Send out properly folded down version of the patch. :P
> ---
> kernel/cgroup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 85bc9be..866059a 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2856,7 +2856,8 @@ static int cgroup_procs_write_permission(struct task_struct *task,
> */
> if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
> !uid_eq(cred->euid, tcred->uid) &&
> - !uid_eq(cred->euid, tcred->suid))
> + !uid_eq(cred->euid, tcred->suid) &&
> + !ns_capable(tcred->user_ns, CAP_SYS_RESOURCE))
> ret = -EACCES;
>
> if (!ret && cgroup_on_dfl(dst_cgrp)) {
> --
> 2.7.4
>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups
From: Kees Cook @ 2016-11-08 23:41 UTC (permalink / raw)
To: John Stultz
Cc: lkml, Tejun Heo, Li Zefan, Jonathan Corbet, Cgroups,
Android Kernel Team, Rom Lemarchand, Colin Cross, Dmitry Shmidt,
Todd Kjos, Christian Poetzsch, Amit Pundir, Dmitry Torokhov,
Serge E . Hallyn, Linux API
In-Reply-To: <1478647728-30357-1-git-send-email-john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Nov 8, 2016 at 3:28 PM, John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> This patch adds logic to allows a process to migrate other tasks
> between cgroups if they have CAP_SYS_RESOURCE.
>
> In Android (where this feature originated), the ActivityManager tracks
> various application states (TOP_APP, FOREGROUND, BACKGROUND, SYSTEM,
> etc), and then as applications change states, the SchedPolicy logic
> will migrate the application tasks between different cgroups used
> to control the different application states (for example, there is a
> background cpuset cgroup which can limit background tasks to stay
> on one low-power cpu, and the bg_non_interactive cpuctrl cgroup can
> then further limit those background tasks to a small percentage of
> that one cpu's cpu time).
>
> However, for security reasons, Android doesn't want to make the
> system_server (the process that runs the ActivityManager and
> SchedPolicy logic), run as root. So in the Android common.git
> kernel, they have some logic to allow cgroups to loosen their
> permissions so CAP_SYS_NICE tasks can migrate other tasks between
> cgroups.
>
> I feel the approach taken there overloads CAP_SYS_NICE a bit much
> for non-android environments.
>
> So this patch, as suggested by Michael Kerrisk, simply adds a
> check for CAP_SYS_RESOURCE.
>
> I've tested this with AOSP master, and this seems to work well
> as Zygote and system_server already use CAP_SYS_RESOURCE. I've
> also submitted patches against the android-4.4 kernel to change
> it to use CAP_SYS_RESOURCE, and the Android developers just merged
> it.
>
> Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Cc: Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>
> Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Android Kernel Team <kernel-team-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>
> Cc: Rom Lemarchand <romlem-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>
> Cc: Colin Cross <ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>
> Cc: Dmitry Shmidt <dimitrysh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Cc: Todd Kjos <tkjos-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Cc: Christian Poetzsch <christian.potzsch-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
> Cc: Amit Pundir <amit.pundir-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Cc: Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Acked-by: Serge Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> v2: Renamed to just CAP_CGROUP_MIGRATE as recommended by Tejun
> v3: Switched to just using CAP_SYS_RESOURCE as suggested by Michael
> v4: Send out properly folded down version of the patch. :P
> ---
> kernel/cgroup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 85bc9be..866059a 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2856,7 +2856,8 @@ static int cgroup_procs_write_permission(struct task_struct *task,
> */
> if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
> !uid_eq(cred->euid, tcred->uid) &&
> - !uid_eq(cred->euid, tcred->suid))
> + !uid_eq(cred->euid, tcred->suid) &&
> + !ns_capable(tcred->user_ns, CAP_SYS_RESOURCE))
> ret = -EACCES;
>
> if (!ret && cgroup_on_dfl(dst_cgrp)) {
> --
> 2.7.4
>
Reviewed-by: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: [PATCH v4 3/9] selinux lsm IB/core: Implement LSM notification system
From: Daniel Jurgens @ 2016-11-08 23:41 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all@01.org, chrisw@sous-sol.org, paul@paul-moore.com,
sds@tycho.nsa.gov, eparis@parisplace.org, dledford@redhat.com,
sean.hefty@intel.com, hal.rosenstock@gmail.com,
selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org,
linux-rdma@vger.kernel.org, Yevgeny Petrilin, Liran Liss,
Leon Romanovsky
In-Reply-To: <201611090600.BYNmwuAI%fengguang.wu@intel.com>
On 11/8/2016 4:36 PM, kbuild test robot wrote:
> Hi Daniel,
>
> [auto build test ERROR on rdma/master]
> [also build test ERROR on v4.9-rc4]
> [cannot apply to next-20161108]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Dan-Jurgens/SELinux-support-for-Infiniband-RDMA/20161109-053432
> base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
> config: i386-randconfig-s1-201645 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: "unregister_lsm_notifier" [drivers/infiniband/core/ib_core.ko] undefined!
>>> ERROR: "register_lsm_notifier" [drivers/infiniband/core/ib_core.ko] undefined!
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
This link error happens when CONFIG_SECURITY is not set. I will address it in v5 after giving some time for additional comments.
^ permalink raw reply
* Re: [PATCH v4 3/9] selinux lsm IB/core: Implement LSM notification system
From: Daniel Jurgens @ 2016-11-08 23:41 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all-JC7UmRfGjtg@public.gmane.org,
chrisw-69jw2NvuJkxg9hUCZPvPmw@public.gmane.org,
paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org,
sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org,
eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.org,
dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org,
linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Yevgeny Petrilin, Liran Liss, Leon Romanovsky
In-Reply-To: <201611090600.BYNmwuAI%fengguang.wu@intel.com>
On 11/8/2016 4:36 PM, kbuild test robot wrote:
> Hi Daniel,
>
> [auto build test ERROR on rdma/master]
> [also build test ERROR on v4.9-rc4]
> [cannot apply to next-20161108]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Dan-Jurgens/SELinux-support-for-Infiniband-RDMA/20161109-053432
> base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
> config: i386-randconfig-s1-201645 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: "unregister_lsm_notifier" [drivers/infiniband/core/ib_core.ko] undefined!
>>> ERROR: "register_lsm_notifier" [drivers/infiniband/core/ib_core.ko] undefined!
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
This link error happens when CONFIG_SECURITY is not set. I will address it in v5 after giving some time for additional comments.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.
From: Arun Easi @ 2016-11-08 20:04 UTC (permalink / raw)
To: kbuild test robot
Cc: Manish Rangankar, kbuild-all, Martin K. Petersen, James Bottomley,
lduncan, cleech, linux-scsi, netdev, QLogic-Storage-Upstream,
Yuval Mintz
In-Reply-To: <201611081805.KzpHTNxg%fengguang.wu@intel.com>
[ Sending on behalf of Manish to cover for the time difference. ]
Hi Martin, James,
I would like to request your input on this kbuild test error on the
series, where they compile fine together, but is not bisectable.
qedi is the new iSCSI driver, which we are trying to submit, for our 41000
series CNA. This patch series were broken up into logical blocks for
review purpose, but were not made to compile individually. It is our
impression that this is acceptable for SCSI and all the initial "qedi"
patches will be squashed and committed as a single commit. Please let us
know if we are mistaken, and if so, we will post another series
with this taken care of.
FYI, this series accompany additions to the common core module, "qed",
that goes under drivers/net/. The patches for the qed module compiles fine
individually and so is bisectable.
In regards to the additional warnings brought out by kbuild test on
"PATCH v2 6/6" and "PATCH v2 3/6", we will post a v3 with the fixes.
Regards,
-Arun
On Tue, 8 Nov 2016, 2:52am -0000, kbuild test robot wrote:
> Hi Manish,
>
> [auto build test ERROR on net-next/master]
> [also build test ERROR on v4.9-rc4]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Manish-Rangankar/qed-Add-support-for-hardware-offloaded-iSCSI/20161108-180027
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 6.2.0
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=ia64
>
> Note: the linux-review/Manish-Rangankar/qed-Add-support-for-hardware-offloaded-iSCSI/20161108-180027 HEAD dd4d1d0e0785d20cdcfdf9b2c792c564a79b2de2 builds fine.
> It only hurts bisectibility.
>
^ permalink raw reply
* Re: [Linux-ima-devel] [PATCH v6 07/10] ima: store the builtin/custom template definitions in a list
From: Dmitry Kasatkin @ 2016-11-08 23:40 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: kexec, linux-kernel@vger.kernel.org, linux-security-module,
Eric W. Biederman, linux-ima-devel, Andrew Morton, linuxppc-dev
In-Reply-To: <1477017898-10375-8-git-send-email-bauerman@linux.vnet.ibm.com>
On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann
<bauerman@linux.vnet.ibm.com> wrote:
> From: Mimi Zohar <zohar@linux.vnet.ibm.com>
>
> The builtin and single custom templates are currently stored in an
> array. In preparation for being able to restore a measurement list
> containing multiple builtin/custom templates, this patch stores the
> builtin and custom templates as a linked list. This will permit
> defining more than one custom template per boot.
>
> Changelog v4:
> - fix "spinlock bad magic" BUG - reported by Dmitry Vyukov
>
> Changelog v3:
> - initialize template format list in ima_template_desc_current(), as it
> might be called during __setup before normal initialization. (kernel
> test robot)
> - remove __init annotation of ima_init_template_list()
>
> Changelog v2:
> - fix lookup_template_desc() preemption imbalance (kernel test robot)
>
> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
> ---
> security/integrity/ima/ima.h | 2 ++
> security/integrity/ima/ima_main.c | 1 +
> security/integrity/ima/ima_template.c | 52 +++++++++++++++++++++++++++--------
> 3 files changed, 44 insertions(+), 11 deletions(-)
>
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index 139dec67dcbf..6b0540ad189f 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -85,6 +85,7 @@ struct ima_template_field {
>
> /* IMA template descriptor definition */
> struct ima_template_desc {
> + struct list_head list;
> char *name;
> char *fmt;
> int num_fields;
> @@ -146,6 +147,7 @@ int ima_restore_measurement_list(loff_t bufsize, void *buf);
> int ima_measurements_show(struct seq_file *m, void *v);
> unsigned long ima_get_binary_runtime_size(void);
> int ima_init_template(void);
> +void ima_init_template_list(void);
>
> /*
> * used to protect h_table and sha_table
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 423d111b3b94..50818c60538b 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -418,6 +418,7 @@ static int __init init_ima(void)
> {
> int error;
>
> + ima_init_template_list();
> hash_setup(CONFIG_IMA_DEFAULT_HASH);
> error = ima_init();
> if (!error) {
> diff --git a/security/integrity/ima/ima_template.c b/security/integrity/ima/ima_template.c
> index 37f972cb05fe..c0d808c20c40 100644
> --- a/security/integrity/ima/ima_template.c
> +++ b/security/integrity/ima/ima_template.c
> @@ -15,16 +15,20 @@
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#include <linux/rculist.h>
> #include "ima.h"
> #include "ima_template_lib.h"
>
> -static struct ima_template_desc defined_templates[] = {
> +static struct ima_template_desc builtin_templates[] = {
> {.name = IMA_TEMPLATE_IMA_NAME, .fmt = IMA_TEMPLATE_IMA_FMT},
> {.name = "ima-ng", .fmt = "d-ng|n-ng"},
> {.name = "ima-sig", .fmt = "d-ng|n-ng|sig"},
> {.name = "", .fmt = ""}, /* placeholder for a custom format */
> };
>
> +static LIST_HEAD(defined_templates);
> +static DEFINE_SPINLOCK(template_list);
> +
> static struct ima_template_field supported_fields[] = {
> {.field_id = "d", .field_init = ima_eventdigest_init,
> .field_show = ima_show_template_digest},
> @@ -53,6 +57,8 @@ static int __init ima_template_setup(char *str)
> if (ima_template)
> return 1;
>
> + ima_init_template_list();
> +
> /*
> * Verify that a template with the supplied name exists.
> * If not, use CONFIG_IMA_DEFAULT_TEMPLATE.
> @@ -81,7 +87,7 @@ __setup("ima_template=", ima_template_setup);
>
> static int __init ima_template_fmt_setup(char *str)
> {
> - int num_templates = ARRAY_SIZE(defined_templates);
> + int num_templates = ARRAY_SIZE(builtin_templates);
>
> if (ima_template)
> return 1;
> @@ -92,22 +98,28 @@ static int __init ima_template_fmt_setup(char *str)
> return 1;
> }
>
> - defined_templates[num_templates - 1].fmt = str;
> - ima_template = defined_templates + num_templates - 1;
> + builtin_templates[num_templates - 1].fmt = str;
> + ima_template = builtin_templates + num_templates - 1;
> +
> return 1;
> }
> __setup("ima_template_fmt=", ima_template_fmt_setup);
>
> static struct ima_template_desc *lookup_template_desc(const char *name)
> {
> - int i;
> + struct ima_template_desc *template_desc;
> + int found = 0;
>
> - for (i = 0; i < ARRAY_SIZE(defined_templates); i++) {
> - if (strcmp(defined_templates[i].name, name) == 0)
> - return defined_templates + i;
> + rcu_read_lock();
> + list_for_each_entry_rcu(template_desc, &defined_templates, list) {
> + if ((strcmp(template_desc->name, name) == 0) ||
> + (strcmp(template_desc->fmt, name) == 0)) {
> + found = 1;
> + break;
> + }
> }
> -
> - return NULL;
> + rcu_read_unlock();
> + return found ? template_desc : NULL;
> }
>
> static struct ima_template_field *lookup_template_field(const char *field_id)
> @@ -183,11 +195,29 @@ static int template_desc_init_fields(const char *template_fmt,
> return 0;
> }
>
> +void ima_init_template_list(void)
> +{
> + int i;
> +
> + if (!list_empty(&defined_templates))
> + return;
> +
> + spin_lock(&template_list);
> + for (i = 0; i < ARRAY_SIZE(builtin_templates); i++) {
> + list_add_tail_rcu(&builtin_templates[i].list,
> + &defined_templates);
> + }
> + spin_unlock(&template_list);
> + synchronize_rcu();
Btw, what is the purpose of synchronize rcu here?
i think it make sense before deleting the object, like:
--------------------------------
list_del_rcu(&p->list);
spin_unlock(&listmutex);
synchronize_rcu();
kfree(p);
--------------------------------
I think it is never deleted.
There is another similar place in the same file...
> +}
> +
> struct ima_template_desc *ima_template_desc_current(void)
> {
> - if (!ima_template)
> + if (!ima_template) {
> + ima_init_template_list();
> ima_template =
> lookup_template_desc(CONFIG_IMA_DEFAULT_TEMPLATE);
> + }
> return ima_template;
> }
>
> --
> 2.7.4
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-ima-devel mailing list
> Linux-ima-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-ima-devel
--
Thanks,
Dmitry
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [Linux-ima-devel] [PATCH v6 07/10] ima: store the builtin/custom template definitions in a list
From: Dmitry Kasatkin @ 2016-11-08 23:40 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: linux-security-module, linuxppc-dev, kexec,
linux-kernel@vger.kernel.org, Eric W. Biederman, linux-ima-devel,
Andrew Morton
In-Reply-To: <1477017898-10375-8-git-send-email-bauerman@linux.vnet.ibm.com>
On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann
<bauerman@linux.vnet.ibm.com> wrote:
> From: Mimi Zohar <zohar@linux.vnet.ibm.com>
>
> The builtin and single custom templates are currently stored in an
> array. In preparation for being able to restore a measurement list
> containing multiple builtin/custom templates, this patch stores the
> builtin and custom templates as a linked list. This will permit
> defining more than one custom template per boot.
>
> Changelog v4:
> - fix "spinlock bad magic" BUG - reported by Dmitry Vyukov
>
> Changelog v3:
> - initialize template format list in ima_template_desc_current(), as it
> might be called during __setup before normal initialization. (kernel
> test robot)
> - remove __init annotation of ima_init_template_list()
>
> Changelog v2:
> - fix lookup_template_desc() preemption imbalance (kernel test robot)
>
> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
> ---
> security/integrity/ima/ima.h | 2 ++
> security/integrity/ima/ima_main.c | 1 +
> security/integrity/ima/ima_template.c | 52 +++++++++++++++++++++++++++--------
> 3 files changed, 44 insertions(+), 11 deletions(-)
>
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index 139dec67dcbf..6b0540ad189f 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -85,6 +85,7 @@ struct ima_template_field {
>
> /* IMA template descriptor definition */
> struct ima_template_desc {
> + struct list_head list;
> char *name;
> char *fmt;
> int num_fields;
> @@ -146,6 +147,7 @@ int ima_restore_measurement_list(loff_t bufsize, void *buf);
> int ima_measurements_show(struct seq_file *m, void *v);
> unsigned long ima_get_binary_runtime_size(void);
> int ima_init_template(void);
> +void ima_init_template_list(void);
>
> /*
> * used to protect h_table and sha_table
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 423d111b3b94..50818c60538b 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -418,6 +418,7 @@ static int __init init_ima(void)
> {
> int error;
>
> + ima_init_template_list();
> hash_setup(CONFIG_IMA_DEFAULT_HASH);
> error = ima_init();
> if (!error) {
> diff --git a/security/integrity/ima/ima_template.c b/security/integrity/ima/ima_template.c
> index 37f972cb05fe..c0d808c20c40 100644
> --- a/security/integrity/ima/ima_template.c
> +++ b/security/integrity/ima/ima_template.c
> @@ -15,16 +15,20 @@
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#include <linux/rculist.h>
> #include "ima.h"
> #include "ima_template_lib.h"
>
> -static struct ima_template_desc defined_templates[] = {
> +static struct ima_template_desc builtin_templates[] = {
> {.name = IMA_TEMPLATE_IMA_NAME, .fmt = IMA_TEMPLATE_IMA_FMT},
> {.name = "ima-ng", .fmt = "d-ng|n-ng"},
> {.name = "ima-sig", .fmt = "d-ng|n-ng|sig"},
> {.name = "", .fmt = ""}, /* placeholder for a custom format */
> };
>
> +static LIST_HEAD(defined_templates);
> +static DEFINE_SPINLOCK(template_list);
> +
> static struct ima_template_field supported_fields[] = {
> {.field_id = "d", .field_init = ima_eventdigest_init,
> .field_show = ima_show_template_digest},
> @@ -53,6 +57,8 @@ static int __init ima_template_setup(char *str)
> if (ima_template)
> return 1;
>
> + ima_init_template_list();
> +
> /*
> * Verify that a template with the supplied name exists.
> * If not, use CONFIG_IMA_DEFAULT_TEMPLATE.
> @@ -81,7 +87,7 @@ __setup("ima_template=", ima_template_setup);
>
> static int __init ima_template_fmt_setup(char *str)
> {
> - int num_templates = ARRAY_SIZE(defined_templates);
> + int num_templates = ARRAY_SIZE(builtin_templates);
>
> if (ima_template)
> return 1;
> @@ -92,22 +98,28 @@ static int __init ima_template_fmt_setup(char *str)
> return 1;
> }
>
> - defined_templates[num_templates - 1].fmt = str;
> - ima_template = defined_templates + num_templates - 1;
> + builtin_templates[num_templates - 1].fmt = str;
> + ima_template = builtin_templates + num_templates - 1;
> +
> return 1;
> }
> __setup("ima_template_fmt=", ima_template_fmt_setup);
>
> static struct ima_template_desc *lookup_template_desc(const char *name)
> {
> - int i;
> + struct ima_template_desc *template_desc;
> + int found = 0;
>
> - for (i = 0; i < ARRAY_SIZE(defined_templates); i++) {
> - if (strcmp(defined_templates[i].name, name) == 0)
> - return defined_templates + i;
> + rcu_read_lock();
> + list_for_each_entry_rcu(template_desc, &defined_templates, list) {
> + if ((strcmp(template_desc->name, name) == 0) ||
> + (strcmp(template_desc->fmt, name) == 0)) {
> + found = 1;
> + break;
> + }
> }
> -
> - return NULL;
> + rcu_read_unlock();
> + return found ? template_desc : NULL;
> }
>
> static struct ima_template_field *lookup_template_field(const char *field_id)
> @@ -183,11 +195,29 @@ static int template_desc_init_fields(const char *template_fmt,
> return 0;
> }
>
> +void ima_init_template_list(void)
> +{
> + int i;
> +
> + if (!list_empty(&defined_templates))
> + return;
> +
> + spin_lock(&template_list);
> + for (i = 0; i < ARRAY_SIZE(builtin_templates); i++) {
> + list_add_tail_rcu(&builtin_templates[i].list,
> + &defined_templates);
> + }
> + spin_unlock(&template_list);
> + synchronize_rcu();
Btw, what is the purpose of synchronize rcu here?
i think it make sense before deleting the object, like:
--------------------------------
list_del_rcu(&p->list);
spin_unlock(&listmutex);
synchronize_rcu();
kfree(p);
--------------------------------
I think it is never deleted.
There is another similar place in the same file...
> +}
> +
> struct ima_template_desc *ima_template_desc_current(void)
> {
> - if (!ima_template)
> + if (!ima_template) {
> + ima_init_template_list();
> ima_template =
> lookup_template_desc(CONFIG_IMA_DEFAULT_TEMPLATE);
> + }
> return ima_template;
> }
>
> --
> 2.7.4
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-ima-devel mailing list
> Linux-ima-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-ima-devel
--
Thanks,
Dmitry
^ permalink raw reply
* Re: status of spdk
From: Sage Weil @ 2016-11-08 23:40 UTC (permalink / raw)
To: Yehuda Sadeh-Weinraub; +Cc: Wang, Haomai, ceph-devel
In-Reply-To: <CADRKj5R+kwpr+_D+bx48gw_BHzX0jcQG-52C_kiLuTeqeEV+Qw@mail.gmail.com>
On Tue, 8 Nov 2016, Yehuda Sadeh-Weinraub wrote:
> I just started looking at spdk, and have a few comments and questions.
>
> First, it's not clear to me how we should handle build. At the moment
> the spdk code resides as a submodule in the ceph tree, but it depends
> on dpdk, which currently needs to be downloaded separately. We can add
> it as a submodule (upstream is here: git://dpdk.org/dpdk). That been
> said, getting it to build was a bit tricky and I think it might be
> broken with cmake. In order to get it working I resorted to building a
> system library and use that.
Note that this PR is about to merge
https://github.com/ceph/ceph/pull/10748
which adds the DPDK submodule, so hopefully this issue will go away when
that merged or with a follow-on cleanup.
> The way to currently configure an osd to use bluestore with spdk is by
> creating a symbolic link that replaces the bluestore 'block' device to
> point to a file that has a name that is prefixed with 'spdk:'.
> Originally I assumed that the suffix would be the nvme device id, but
> it seems that it's not really needed, however, the file itself needs
> to contain the device id (see
> https://github.com/yehudasa/ceph/tree/wip-yehuda-spdk for a couple of
> minor fixes).
Open a PR for those?
> As I understand it, in order to support multiple osds on the same NVMe
> device we have a few options. We can leverage NVMe namespaces, but
> that's not supported on all devices. We can configure bluestore to
> only use part of the device (device sharding? not sure if it supports
> it). I think it's best if we could keep bluestore out of the loop
> there and have the NVMe driver abstract multiple partitions of the
> NVMe device. The idea is to be able to define multiple partitions on
> the device (e.g., each partition will be defined by the offset, size,
> and namespace), and have the osd set to use a specific partition.
> We'll probably need a special tool to manage it, and potentially keep
> the partition table information on the device itself. The tool could
> also manage the creation of the block link. We should probably rethink
> how the link is structure and what it points at.
I agree that bluestore shouldn't get involved.
Is the NVMe namespaces meant to support multiple processes sharing the
same hardware device?
Also, if you do that, is it possible to give one of the namespaces to the
kernel? That might solve the bootstrapping problem we currently have
where we have nowhere to put the $osd_data filesystem with the device
metadata. (This is admittedly not necessarily a blocking issue. Putting
those dirs on / wouldn't be the end of the world; it just means cards
can't be easily moved between boxes.)
sage
^ permalink raw reply
* Re: [PATCH 0/4] musb fixes for v4.9-rc cycle
From: Ladislav Michl @ 2016-11-08 23:39 UTC (permalink / raw)
To: Tony Lindgren
Cc: Bin Liu, Boris Brezillon, Greg Kroah-Hartman, Andreas Kemnade,
Felipe Balbi, George Cherian, Kishon Vijay Abraham I,
Ivaylo Dimitrov, Johan Hovold, Laurent Pinchart, Sergei Shtylyov,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161108231637.GP2428-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tue, Nov 08, 2016 at 04:16:37PM -0700, Tony Lindgren wrote:
> * Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org> [161108 15:52]:
> > On Tue, Nov 08, 2016 at 03:05:30PM -0700, Tony Lindgren wrote:
> > > OK. The patch below still works for me with musb_core.c
> > > autosuspend_delay set to 100. Also works with it set to 10.
> > >
> > > Note that we had two timeouts without this.. Can you try
> > > playing with the timeout in musb_core.c and see if that
> > > helps?
> >
> >
> > This patch works for me, also with autosuspend_delay set to 10.
>
> Oh so to confirm, the $subject series patches + this one only fixes
> your issue? So no more revert needed?
Right. Revert is no more needed.
> I think the musb_core timeout had to be 500 to idle the 2430 glue
> layer phy also, but I need to recheck that. That should be a
> separate patch and can be done later.
>
> Regards,
>
> Tony
Regards,
ladis
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: How to handle GPIO differences between P8 and P9
From: Xo Wang @ 2016-11-08 23:38 UTC (permalink / raw)
To: Mine; +Cc: Patrick Williams, OpenBMC Maillist
In-Reply-To: <CAARXrt=FA=kTrjJ3KAyB03cuiBP=ka6BHf6YuNYh8x-DtyCcHw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3619 bytes --]
On Tue, Nov 8, 2016 at 1:13 PM, Mine <mine260309@gmail.com> wrote:
> On Mon, Nov 7, 2016 at 3:53 PM, Xo Wang <xow@google.com> wrote:
> > On Mon, Nov 7, 2016 at 9:01 AM, Mine <mine260309@gmail.com> wrote:
> >> On Mon, Nov 7, 2016 at 10:19 AM, Patrick Williams <patrick@stwcx.xyz>
> wrote:
> >>> On Mon, Nov 07, 2016 at 05:10:59PM +0800, Yi TZ Li wrote:
> >>>> I committed a patch: https://gerrit.openbmc-project.xyz/#/c/1019/
> >>>> to add a getSystemName() dbus method in org.obmc.managers.System
> interface.
> >>>> There are several places in skeleton requires fix for a specific
> system.
> >>>>
> >>>> Other way be add a compile flag in yocto when building Skeleton.
> >>>
> >>> We are really trying to avoid "if (machine_type == ...)" type code.
> This
> >>> becomes a gigantic problem when we are talking about supporting 3 dozen
> >>> machines.
> >>>
> >>> --
> >>> Patrick Williams
> >>
> >> Yup, I prefer not to write `if (machine_type == ...)` type code, nor
> >> to have a compile flag (it just becomes `#if xxx` or `#ifdef xxx`).
> >>
> >> The temp fix by not defining `IDBTN` will not only cause error log,
> >> but also prevent the code in `op-hostctl/control_host_obj.c` to work,
> >> because it will get error during opening the GPIO, and jump out,
> >> resulting in error: "GPIO sequence failed".
> >>
> >> If we are targeting for booting P9 up, I would suggest a temp fix by
> >> defining `IDBTN` for both Witherspoon and Romulus.
> >> It will not block power on, but may break a function related to LED.
> >>
> >> --
> >> BRs,
> >> Lei YU
> >> _______________________________________________
> >> openbmc mailing list
> >> openbmc@lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/openbmc
> >
> > We had a similar issue in the op-pwrctl where the source hard-coded
> > the system net names. There I put in a short-term solution of adding a
> > function-specific abstraction over the net names into the System.py
> > config, removing the per-machine patches for name and polarity:
> > https://gerrit.openbmc-project.xyz/#/c/606/
> > https://gerrit.openbmc-project.xyz/#/c/689/
> >
> > It's not difficult to extend POWER_CONFIG for GPIO functions that only
> > exist on one machine, like so:
> > https://gerrit.openbmc-project.xyz/#/c/608/3
> >
> > With the abstraction taking place in the Python machine config, we
> > don't need per-machine dispatch in the user interface (op-pwrctl,
> > op-hostctl, op-pwr-button, etc).
> >
> > Does that work for you in the short term?
> >
> > cheers
> > xo
>
> Yup, that could be a solution. It's just the GPIOs are not for power
> control,
> so following the solution would probably introduce similar code to
> hostctl_gpio.h/c.
>
> Maybe I can combine the power_gpio and hostctl_gpio, so they share the same
> code?
>
> Something like:
>
> GPIO_CONFIG = {
> 'power_gpios': {
> 'latch_out' : 'BMC_UCD_LATCH_LE',
> 'power_good_in' : 'SYS_PWROK_BUFF',
> 'power_up_outs' : [
> ('SOFTWARE_PGOOD', True),
> ('BMC_POWER_UP', True),
> ],
> 'reset_outs' : [
> ],
> },
> 'hostctl_gpios': {
> 'fsi_data' : 'FSI_DATA',
> ...
> 'optionals' : [
> ('BMC_THROTTLE', True),
> ('IDBTN', False),
> ],
> }
> }
>
> What do you think?
>
> --
> BRs,
> Lei YU
>
Yes, that sounds reasonable to me. Maybe change the name of the PowerGpio
stuff to reflect your more general approach.
FYI something that I didn't implement was adding GPIO polarity support
into libopenbmc_intf/gpio. So, all the polarity (active high/low) logic
needs to be handled by the application, which is less than ideal.
cheers
xo
[-- Attachment #2: Type: text/html, Size: 5530 bytes --]
^ permalink raw reply
* Re: [PATCH v7 07/17] ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
From: Jacob Keller @ 2016-11-08 23:37 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <20161108201211.25213-8-Karthik.188@gmail.com>
On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> Borrowing from branch.c's implementation print "[gone]" whenever an
> unknown upstream ref is encountered instead of just ignoring it.
>
This makes sense.
> This makes sure that when branch.c is ported over to using ref-filter
> APIs for printing, this feature is not lost.
>
Right.
> Make changes to t/t6300-for-each-ref.sh and
> Documentation/git-for-each-ref.txt to reflect this change.
>
This will change behavior if people were expecting it to remain
silent, but I think this could be considered a bug.
> Mentored-by: Christian Couder <christian.couder@gmail.com>
> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
> Helped-by : Jacob Keller <jacob.keller@gmail.com>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
> Documentation/git-for-each-ref.txt | 3 ++-
> ref-filter.c | 4 +++-
> t/t6300-for-each-ref.sh | 2 +-
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
> index 92184c4..fd365eb 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -119,7 +119,8 @@ upstream::
> "[ahead N, behind M]" and `:trackshort` to show the terse
> version: ">" (ahead), "<" (behind), "<>" (ahead and behind),
> or "=" (in sync). Has no effect if the ref does not have
> - tracking information associated with it.
> + tracking information associated with it. `:track` also prints
> + "[gone]" whenever unknown upstream ref is encountered.
>
I think this is poorly worded. If I understand, "has no effect if the
ref does not have tracking information" so in that case we still print
nothing, right? but otherwise we print [gone] only when the upstream
ref no longer actually exists locally? I wonder if there is a better
wording for this? I don't have one. Any suggestions to avoid confusing
these two cases?
> push::
> The name of a local ref which represents the `@{push}` location
> diff --git a/ref-filter.c b/ref-filter.c
> index b8b8a95..6d51b80 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -1049,8 +1049,10 @@ static void fill_remote_ref_details(struct used_atom *atom, const char *refname,
> *s = shorten_unambiguous_ref(refname, warn_ambiguous_refs);
> else if (atom->u.remote_ref == RR_TRACK) {
> if (stat_tracking_info(branch, &num_ours,
> - &num_theirs, NULL))
> + &num_theirs, NULL)) {
> + *s = "[gone]";
> return;
> + }
>
> if (!num_ours && !num_theirs)
> *s = "";
> diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
> index 2be0a3f..a92b36f 100755
> --- a/t/t6300-for-each-ref.sh
> +++ b/t/t6300-for-each-ref.sh
> @@ -382,7 +382,7 @@ test_expect_success 'Check that :track[short] cannot be used with other atoms' '
>
> test_expect_success 'Check that :track[short] works when upstream is invalid' '
> cat >expected <<-\EOF &&
> -
> + [gone]
>
> EOF
> test_when_finished "git config branch.master.merge refs/heads/master" &&
> --
> 2.10.2
>
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Initialise nest mmu
From: Balbir Singh @ 2016-11-08 23:36 UTC (permalink / raw)
To: Alistair Popple, linuxppc-dev, Michael Ellerman
Cc: stewart, linuxppc-dev, linux-kernel
In-Reply-To: <35949087.yEIrgECls7@new-mexico>
On 14/09/16 15:02, Alistair Popple wrote:
> On Mon, 15 Aug 2016 04:51:59 PM Alistair Popple wrote:
>> POWER9 contains an off core mmu called the nest mmu (NMMU). This is
>> used by other hardware units on the chip to translate virtual
>> addresses into real addresses. The unit attempting an address
>> translation provides the majority of the context required for the
>> translation request except for the base address of the partition table
>> (ie. the PTCR) which needs to be programmed into the NMMU.
>>
>> This patch adds a call to OPAL to set the PTCR for the nest mmu in
>> opal_init().
>>
>> Signed-off-by: Alistair Popple <alistair@popple.id.au>
>> ---
>>
>> This patch depends on a new OPAL call which has yet to be added to
>> skiboot, although the patch to do so has been posted to
>> http://patchwork.ozlabs.org/patch/659106/
>
> This has now gone into skiboot with the same OPAL call number :-
> https://github.com/open-power/skiboot/commit/84e63a8d4fd9eb3efc872099d579c49fef6a5810
>
>> arch/powerpc/include/asm/opal-api.h | 3 ++-
>> arch/powerpc/include/asm/opal.h | 1 +
>> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
>> arch/powerpc/platforms/powernv/opal.c | 3 +++
>> 4 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
>> index 0e2e57b..a0aa285 100644
>> --- a/arch/powerpc/include/asm/opal-api.h
>> +++ b/arch/powerpc/include/asm/opal-api.h
>> @@ -167,7 +167,8 @@
>> #define OPAL_INT_EOI 124
>> #define OPAL_INT_SET_MFRR 125
>> #define OPAL_PCI_TCE_KILL 126
>> -#define OPAL_LAST 126
>> +#define OPAL_NMMU_SET_PTCR 127
>> +#define OPAL_LAST 127
>>
>> /* Device tree flags */
>>
>> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
>> index ee05bd2..433df5e 100644
>> --- a/arch/powerpc/include/asm/opal.h
>> +++ b/arch/powerpc/include/asm/opal.h
>> @@ -228,6 +228,7 @@ int64_t opal_pci_tce_kill(uint64_t phb_id, uint32_t kill_type,
>> int64_t opal_rm_pci_tce_kill(uint64_t phb_id, uint32_t kill_type,
>> uint32_t pe_num, uint32_t tce_size,
>> uint64_t dma_addr, uint32_t npages);
>> +int64_t opal_nmmu_set_ptcr(uint64_t chip_id, uint64_t ptcr);
>>
>> /* Internal functions */
>> extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
>> diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
>> index 3d29d40..a955649 100644
>> --- a/arch/powerpc/platforms/powernv/opal-wrappers.S
>> +++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
>> @@ -308,3 +308,4 @@ OPAL_CALL(opal_int_eoi, OPAL_INT_EOI);
>> OPAL_CALL(opal_int_set_mfrr, OPAL_INT_SET_MFRR);
>> OPAL_CALL(opal_pci_tce_kill, OPAL_PCI_TCE_KILL);
>> OPAL_CALL_REAL(opal_rm_pci_tce_kill, OPAL_PCI_TCE_KILL);
>> +OPAL_CALL(opal_nmmu_set_ptcr, OPAL_NMMU_SET_PTCR);
>> diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
>> index 8b4fc68..b533245 100644
>> --- a/arch/powerpc/platforms/powernv/opal.c
>> +++ b/arch/powerpc/platforms/powernv/opal.c
>> @@ -762,6 +762,9 @@ static int __init opal_init(void)
>> /* Initialise OPAL kmsg dumper for flushing console on panic */
>> opal_kmsg_init();
>>
>> + /* Update partition table control register on all Nest MMUs */
>> + opal_nmmu_set_ptcr(-1UL, __pa(partition_tb) | (PATB_SIZE_SHIFT - 12));
>> +
>> return 0;
>> }
>> machine_subsys_initcall(powernv, opal_init);
>> --
>> 2.1.4
>
We might need some kexec changes as well, but for this patch
Reviewed-by: Balbir Singh <bsingharora@gmail.com>
^ permalink raw reply
* Re: [PATCH v3 1/8] exec: introduce cred_guard_light
From: Eric W. Biederman @ 2016-11-08 23:33 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: Kees Cook, Oleg Nesterov, Jann Horn, Alexander Viro,
Roland McGrath, John Johansen, James Morris, Serge E. Hallyn,
Paul Moore, Stephen Smalley, Eric Paris, Casey Schaufler,
Andrew Morton, Janis Danisevskis, Seth Forshee, Thomas Gleixner,
Ben Hutchings, Andy Lutomirski, Linus Torvalds, Krister Johansen,
linux-fsdevel@vger.kernel.org, linux-security-module,
security@kernel.org
In-Reply-To: <20161108225651.GJ16345@kvack.org>
Benjamin LaHaise <bcrl@kvack.org> writes:
> On Tue, Nov 08, 2016 at 04:46:44PM -0600, Eric W. Biederman wrote:
>> Kees Cook <keescook@chromium.org> writes:
> ...
>> > This is a problem for Google folks too sometimes. This is saying that
>> > xmission.com is checking redhat.com's SPF records and refusing to let
>> > kernel.org deliver email as if it were redhat.com (due to
>> > security@kernel.org being an alias not a mailing list). There aren't
>> > good solutions for this, but best I've found is to have my
>> > security@kernel.org alias be a @kernel.org address instead of an
>> > @google.com address...
>>
>> Ugh. Is even redhat configuring the redhat email to do that?
>> I will have to look.
>>
>> Last I looked xmission.com was just enforcing the policy that the other
>> mail domains were asking to be enforced on themselves. But those are
>> policies that are incompatible with mailing lists in general. Although
>> I do get confused about which part SPF and DKIM play in this mess.
>>
>> I just remember that the last several ``enhancements'' to email were
>> busily breaking mailing lists and I thought they were completely insane.
>> I can even find evidence that it is (or at least was) so bad that email
>> standards comittee member's can't comminicate with each other via email
>> lists.
>>
>> vger.kernel.org appears to rewrite the envelope sender to avoid
>> problems.
>
> Envelope sender rewriting is insufficient, the From: lines need to be
> rewritten to be compliant. This is a pain in the ass for the @kvack.org
> mailing lists as well -- people with @google.com addresses don't see the
> mailing list postings of users from @google.com and other domains using
> "enhanced" email header "validation" techniques.
That definitely happens in the worst case. At least for Oleg something
less serious is happening because the from header does not get changed
and the email gets to me through the vger.kernel.org lists.
Eric
^ permalink raw reply
* Re: [PATCH RFC 0/4] xfs: basic cow fork speculative preallocation
From: Dave Chinner @ 2016-11-08 23:34 UTC (permalink / raw)
To: Brian Foster; +Cc: Darrick J. Wong, linux-xfs
In-Reply-To: <20161108223930.GA8167@bfoster.bfoster>
On Tue, Nov 08, 2016 at 05:39:31PM -0500, Brian Foster wrote:
> On Tue, Nov 08, 2016 at 12:48:00PM -0800, Darrick J. Wong wrote:
> > On Tue, Nov 08, 2016 at 03:27:32PM -0500, Brian Foster wrote:
> > > Hi all,
> > >
> > > This is an experiment based on an idea for COW fork speculative
> > > preallocation. This is experimental, lightly/barely tested and sent in
> > > RFC form to solicit thoughts, ideas or flames before I spend time taking
> > > it further.
> > >
> > > Patch 1 probably stands on its own. Patches 2 and 3 are some refactoring
> > > and patch 4 implements the basic idea, which is described in the commit
> > > log description. The testing I've done so far is basically similar to
> > > how one would test the effects of traditional speculative preallocation:
> > > write to multiple reflinked files in parallel and examine the resulting
> > > fragmentation. Specifically, I wrote sequentially to 16 different
> > > reflinked files of the same 8GB original (which has two data extents,
> > > completely shared). Without preallocation, the test results in ~248
> > > extents across the 16 files. With preallocation, the test results in 32
> > > extents across the 16 files (i.e., 2 extents per file, same as the
> > > source file).
> > >
> > > An obvious tradeoff is the unnecessarily aggressive allocation that
> > > might occur in the event of random writes to a large file (such as in
> > > the cloned VM disk image use case), but my thinking is that the
> > > cowblocks tagging and reclaim infrastructure should manage that
> > > sufficiently (lack of testing notwithstanding). In any event, I'm
> > > interested in any thoughts along the lines of whether this is useful at
> > > all, alternative algorithm ideas, etc.
> >
> > Was about to step out to lunch when this came in, but...
> >
> > Is there an xfstest for this, so I can play too? :)
> >
>
> Not yet.. I've only xfstests tested insofar as it hasn't blown anything
> up yet. :) Otherwise, I've just run manual write tests to observe
> whether it is doing what I expect it to in simple cases. It clearly
> needs more work, as noted in the patch, but if this is something worth
> pursuing further I can certainly come up with some tests as well.
I think it definitely has value for preventing COW overwrite
fragmentation - this will be an issue if people start reflinking
files widely (e.g. container roots) and then occasionally
overwriting files completely.
> FWIW, that COW fork fiemap hack I sent a bit ago came in handy for
> playing with this as well. :)
It might be worth keeping these two patchsets together for the
purposes of development and review. The fiemap hack by itself is
neat, but having a demonstrated use for development of new features
makes it more than just a "neat hack". :P
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II))
From: Alex Williamson @ 2016-11-08 23:35 UTC (permalink / raw)
To: Christoffer Dall
Cc: Will Deacon, Eric Auger, eric.auger.pro, marc.zyngier,
robin.murphy, joro, tglx, jason, linux-arm-kernel, kvm, drjones,
linux-kernel, pranav.sawargaonkar, iommu, punit.agrawal,
diana.craciun, ddutile, benh, arnd, jcm, dwmw
In-Reply-To: <20161108202922.GC15676@cbox>
On Tue, 8 Nov 2016 21:29:22 +0100
Christoffer Dall <christoffer.dall@linaro.org> wrote:
> Hi Will,
>
> On Tue, Nov 08, 2016 at 02:45:59AM +0000, Will Deacon wrote:
> > Hi all,
> >
> > I figured this was a reasonable post to piggy-back on for the LPC minutes
> > relating to guest MSIs on arm64.
> >
> > On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
> > > We can always have QEMU reject hot-adding the device if the reserved
> > > region overlaps existing guest RAM, but I don't even really see how we
> > > advise users to give them a reasonable chance of avoiding that
> > > possibility. Apparently there are also ARM platforms where MSI pages
> > > cannot be remapped to support the previous programmable user/VM
> > > address, is it even worthwhile to support those platforms? Does that
> > > decision influence whether user programmable MSI reserved regions are
> > > really a second class citizen to fixed reserved regions? I expect
> > > we'll be talking about this tomorrow morning, but I certainly haven't
> > > come up with any viable solutions to this. Thanks,
> >
> > At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
> > microconference. I presented some slides to illustrate some of the issues
> > we're trying to solve:
> >
> > http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
> >
> > Punit took some notes (thanks!) on the etherpad here:
> >
> > https://etherpad.openstack.org/p/LPC2016_PCI
> >
> > although the discussion was pretty lively and jumped about, so I've had
> > to go from memory where the notes didn't capture everything that was
> > said.
> >
> > To summarise, arm64 platforms differ in their handling of MSIs when compared
> > to x86:
> >
> > 1. The physical memory map is not standardised (Jon pointed out that
> > this is something that was realised late on)
> > 2. MSIs are usually treated the same as DMA writes, in that they must be
> > mapped by the SMMU page tables so that they target a physical MSI
> > doorbell
> > 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
> > doorbell built into the PCI RC)
> > 4. Platforms typically have some set of addresses that abort before
> > reaching the SMMU (e.g. because the PCI identifies them as P2P).
> >
> > All of this means that userspace (QEMU) needs to identify the memory
> > regions corresponding to points (3) and (4) and ensure that they are
> > not allocated in the guest physical (IPA) space. For platforms that can
> > remap the MSI doorbell as in (2), then some space also needs to be
> > allocated for that.
> >
> > Rather than treat these as separate problems, a better interface is to
> > tell userspace about a set of reserved regions, and have this include
> > the MSI doorbell, irrespective of whether or not it can be remapped.
>
> Is my understanding correct, that you need to tell userspace about the
> location of the doorbell (in the IOVA space) in case (2), because even
> though the configuration of the device is handled by the (host) kernel
> through trapping of the BARs, we have to avoid the VFIO user programming
> the device to create other DMA transactions to this particular address,
> since that will obviously conflict and either not produce the desired
> DMA transactions or result in unintended weird interrupts?
Correct, if the MSI doorbell IOVA range overlaps RAM in the VM, then
it's potentially a DMA target and we'll get bogus data on DMA read from
the device, and lose data and potentially trigger spurious interrupts on
DMA write from the device. Thanks,
Alex
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II))
From: Alex Williamson @ 2016-11-08 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108202922.GC15676@cbox>
On Tue, 8 Nov 2016 21:29:22 +0100
Christoffer Dall <christoffer.dall@linaro.org> wrote:
> Hi Will,
>
> On Tue, Nov 08, 2016 at 02:45:59AM +0000, Will Deacon wrote:
> > Hi all,
> >
> > I figured this was a reasonable post to piggy-back on for the LPC minutes
> > relating to guest MSIs on arm64.
> >
> > On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
> > > We can always have QEMU reject hot-adding the device if the reserved
> > > region overlaps existing guest RAM, but I don't even really see how we
> > > advise users to give them a reasonable chance of avoiding that
> > > possibility. Apparently there are also ARM platforms where MSI pages
> > > cannot be remapped to support the previous programmable user/VM
> > > address, is it even worthwhile to support those platforms? Does that
> > > decision influence whether user programmable MSI reserved regions are
> > > really a second class citizen to fixed reserved regions? I expect
> > > we'll be talking about this tomorrow morning, but I certainly haven't
> > > come up with any viable solutions to this. Thanks,
> >
> > At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
> > microconference. I presented some slides to illustrate some of the issues
> > we're trying to solve:
> >
> > http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
> >
> > Punit took some notes (thanks!) on the etherpad here:
> >
> > https://etherpad.openstack.org/p/LPC2016_PCI
> >
> > although the discussion was pretty lively and jumped about, so I've had
> > to go from memory where the notes didn't capture everything that was
> > said.
> >
> > To summarise, arm64 platforms differ in their handling of MSIs when compared
> > to x86:
> >
> > 1. The physical memory map is not standardised (Jon pointed out that
> > this is something that was realised late on)
> > 2. MSIs are usually treated the same as DMA writes, in that they must be
> > mapped by the SMMU page tables so that they target a physical MSI
> > doorbell
> > 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
> > doorbell built into the PCI RC)
> > 4. Platforms typically have some set of addresses that abort before
> > reaching the SMMU (e.g. because the PCI identifies them as P2P).
> >
> > All of this means that userspace (QEMU) needs to identify the memory
> > regions corresponding to points (3) and (4) and ensure that they are
> > not allocated in the guest physical (IPA) space. For platforms that can
> > remap the MSI doorbell as in (2), then some space also needs to be
> > allocated for that.
> >
> > Rather than treat these as separate problems, a better interface is to
> > tell userspace about a set of reserved regions, and have this include
> > the MSI doorbell, irrespective of whether or not it can be remapped.
>
> Is my understanding correct, that you need to tell userspace about the
> location of the doorbell (in the IOVA space) in case (2), because even
> though the configuration of the device is handled by the (host) kernel
> through trapping of the BARs, we have to avoid the VFIO user programming
> the device to create other DMA transactions to this particular address,
> since that will obviously conflict and either not produce the desired
> DMA transactions or result in unintended weird interrupts?
Correct, if the MSI doorbell IOVA range overlaps RAM in the VM, then
it's potentially a DMA target and we'll get bogus data on DMA read from
the device, and lose data and potentially trigger spurious interrupts on
DMA write from the device. Thanks,
Alex
^ permalink raw reply
* Re: Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II))
From: Alex Williamson @ 2016-11-08 23:35 UTC (permalink / raw)
To: Christoffer Dall
Cc: drjones-H+wXaHxf7aLQT0dZR+AlfA, jason-NLaQJdtUoK4Be96aLqz0jA,
kvm-u79uwXL29TY76Z2rM5mHXA, marc.zyngier-5wv7dgnIgG8,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, punit.agrawal-5wv7dgnIgG8,
Will Deacon, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
arnd-r2nGTMty4D4,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w,
dwmw-vV1OtcyAfmbQXOPxS62xeg, jcm-H+wXaHxf7aLQT0dZR+AlfA,
tglx-hfZtesqFncYOwBW4kG4KsQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20161108202922.GC15676@cbox>
On Tue, 8 Nov 2016 21:29:22 +0100
Christoffer Dall <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Will,
>
> On Tue, Nov 08, 2016 at 02:45:59AM +0000, Will Deacon wrote:
> > Hi all,
> >
> > I figured this was a reasonable post to piggy-back on for the LPC minutes
> > relating to guest MSIs on arm64.
> >
> > On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
> > > We can always have QEMU reject hot-adding the device if the reserved
> > > region overlaps existing guest RAM, but I don't even really see how we
> > > advise users to give them a reasonable chance of avoiding that
> > > possibility. Apparently there are also ARM platforms where MSI pages
> > > cannot be remapped to support the previous programmable user/VM
> > > address, is it even worthwhile to support those platforms? Does that
> > > decision influence whether user programmable MSI reserved regions are
> > > really a second class citizen to fixed reserved regions? I expect
> > > we'll be talking about this tomorrow morning, but I certainly haven't
> > > come up with any viable solutions to this. Thanks,
> >
> > At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
> > microconference. I presented some slides to illustrate some of the issues
> > we're trying to solve:
> >
> > http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
> >
> > Punit took some notes (thanks!) on the etherpad here:
> >
> > https://etherpad.openstack.org/p/LPC2016_PCI
> >
> > although the discussion was pretty lively and jumped about, so I've had
> > to go from memory where the notes didn't capture everything that was
> > said.
> >
> > To summarise, arm64 platforms differ in their handling of MSIs when compared
> > to x86:
> >
> > 1. The physical memory map is not standardised (Jon pointed out that
> > this is something that was realised late on)
> > 2. MSIs are usually treated the same as DMA writes, in that they must be
> > mapped by the SMMU page tables so that they target a physical MSI
> > doorbell
> > 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
> > doorbell built into the PCI RC)
> > 4. Platforms typically have some set of addresses that abort before
> > reaching the SMMU (e.g. because the PCI identifies them as P2P).
> >
> > All of this means that userspace (QEMU) needs to identify the memory
> > regions corresponding to points (3) and (4) and ensure that they are
> > not allocated in the guest physical (IPA) space. For platforms that can
> > remap the MSI doorbell as in (2), then some space also needs to be
> > allocated for that.
> >
> > Rather than treat these as separate problems, a better interface is to
> > tell userspace about a set of reserved regions, and have this include
> > the MSI doorbell, irrespective of whether or not it can be remapped.
>
> Is my understanding correct, that you need to tell userspace about the
> location of the doorbell (in the IOVA space) in case (2), because even
> though the configuration of the device is handled by the (host) kernel
> through trapping of the BARs, we have to avoid the VFIO user programming
> the device to create other DMA transactions to this particular address,
> since that will obviously conflict and either not produce the desired
> DMA transactions or result in unintended weird interrupts?
Correct, if the MSI doorbell IOVA range overlaps RAM in the VM, then
it's potentially a DMA target and we'll get bogus data on DMA read from
the device, and lose data and potentially trigger spurious interrupts on
DMA write from the device. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH -tip v2 0/6] ftrace: selftests: Add full glob matching and update ftracetest
From: Masami Hiramatsu @ 2016-11-08 23:34 UTC (permalink / raw)
To: Steven Rostedt, Shuah Khan, Shuah Khan
Cc: linux-kernel, Ingo Molnar, Namhyung Kim, Tom Zanussi,
linux-kselftest, Masami Hiramatsu
In-Reply-To: <147781042852.11952.2843145560116738189.stgit@devbox>
Ping?
On Sun, 30 Oct 2016 15:53:49 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Hi,
>
> Here is the 2nd version of the series of patches to
> add full glob matching support in ftrace and update
> ftracetest to test the glob matching and hexadecimal
> types.
>
> Previous version is here:
> https://lkml.org/lkml/2016/10/19/7
>
> I've update ftracetest to initialize ftrace before
> each testcase accordning to Steve's comment.
> In this series I've added a patch which makes git
> to ignore the directory for test results.
>
> [1/6] Add full glob matching support on ftrace's
> function filter and event filter expression.
> [2/6] Initialize ftrace before running each testcase.
> [3/6] Hide logs direcotry from git.
> [4/6] Introduce temporary directory for test cases,
> which is used for storing temporary test data.
> [5/6] Add a testcase for function-name glob matching
> [6/6] Add a testcase for types of event arguments
>
> Thanks,
> ---
>
> Masami Hiramatsu (6):
> ftrace: Support full glob matching
> selftests: ftrace: Initialize ftrace before each test
> selftests: ftrace: Hide ftracetest logs from git
> selftests: ftrace: Introduce TMPDIR for temporary files
> selftests: ftrace: Add a testcase for function filter glob match
> selftests: ftrace: Add a testcase for types of kprobe event
>
>
> Documentation/trace/events.txt | 9 +---
> Documentation/trace/ftrace.txt | 9 +---
> kernel/trace/Kconfig | 2 +
> kernel/trace/ftrace.c | 4 ++
> kernel/trace/trace.c | 2 -
> kernel/trace/trace.h | 2 +
> kernel/trace/trace_events_filter.c | 17 +++++++
> tools/testing/selftests/ftrace/.gitignore | 1
> tools/testing/selftests/ftrace/ftracetest | 4 +-
> .../ftrace/test.d/ftrace/func-filter-glob.tc | 49 ++++++++++++++++++++
> tools/testing/selftests/ftrace/test.d/functions | 25 ++++++++++
> .../ftrace/test.d/kprobe/kprobe_args_type.tc | 37 +++++++++++++++
> 12 files changed, 146 insertions(+), 15 deletions(-)
> create mode 100644 tools/testing/selftests/ftrace/.gitignore
> create mode 100644 tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc
>
> --
> Masami Hiramatsu (Linaro Ltd.) <mhiramat@kernel.org>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: Finding EPT entries for nested guest in L0
From: Paolo Bonzini @ 2016-11-08 23:34 UTC (permalink / raw)
To: Rohith Kugve Raghavendra, kvm
In-Reply-To: <CAEqNykA_=RV50YO=MvM98MbzTHBCkVtcvGGEyZXe4ktQesX=ag@mail.gmail.com>
On 08/11/2016 21:27, Rohith Kugve Raghavendra wrote:
> I have 2 questions.
>
> 1. In nested VMs that use multi-dimensional page tables( EPT on EPT)
> where exactly in the code are EPT ( 0 -> 2) entries constructed? I can
> know from the Turtles paper that these entries are created by
> combining EPT 1->2 and EPT 0->1. But I can find that in KVM code.
It's in mmu.c, same as for shadow pages.
vcpu->arch.nested_mmu contains the MMU for L0->L2, while vcpu->arch.mmu
contains the MMU for L0->L1.
vcpu->arch.walk_mmu points to one of the two, depending on who was
running at the time of the last vmexit. In particular, prepare_vmcs02
(through nested_ept_init_mmu_context) sets vcpu->arch.walk_mmu to
&vcpu->arch.nested_mmu.
> 2. Are there rmap entries for EPT 0->2 pages maintained? I am trying
> to write protect nested guest GFN's directly in L0 ( without letting
> L1 do it) but I don't know how to find the EPT 0->2 entry for a given
> L2 guest GFN.
Yes, they are. There is only one rmap for both vcpu->arch.mmu and
vcpu->arch.nested_mmu, but for EPT02 pages of course vcpu->arch.mmu
should be direct mapped and not have any rmap.
Thanks,
Paolo
^ permalink raw reply
* Re: master branch merges must pass unit tests
From: Sage Weil @ 2016-11-08 23:34 UTC (permalink / raw)
To: ceph-devel
In-Reply-To: <alpine.DEB.2.11.1611082147590.29278@piezo.us.to>
On Tue, 8 Nov 2016, Sage Weil wrote:
> I enabled the github check that the unit tests pass in order to merge to
> master. These tests still aren't completely reliable, but they're close,
> and we'll make better progress if we start enforcing it now.
I went a bit further and also checked the box requiring a review and
preventing pushes directly to master branch. These are already uneforced
requirements so this shouldn't slow people down *except* that we need to
start using the new github 'review' feature that lets you explicitly
approve changes.
Again, the core developers can override these restrictions if necessary.
I haven't done anything to the stable branches, but we might want to do
the same thing there...
sage
^ permalink raw reply
* Re: [PATCH] Avoid that SCSI device removal through sysfs triggers a deadlock
From: Bart Van Assche @ 2016-11-08 23:33 UTC (permalink / raw)
To: Eric W. Biederman, James Bottomley
Cc: Martin K. Petersen, Greg Kroah-Hartman, Hannes Reinecke,
Johannes Thumshirn, Sagi Grimberg, linux-scsi@vger.kernel.org
In-Reply-To: <87oa1pvl8f.fsf@xmission.com>
On 11/08/2016 11:15 AM, Eric W. Biederman wrote:
> James Bottomley <jejb@linux.vnet.ibm.com> writes:
>
>> On Tue, 2016-11-08 at 08:52 -0800, Bart Van Assche wrote:
>>> On 11/08/2016 07:28 AM, James Bottomley wrote:
>>>> On Mon, 2016-11-07 at 16:32 -0800, Bart Van Assche wrote:
>>>>> diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
>>>>> index cf4c636..44ec536 100644
>>>>> --- a/fs/kernfs/dir.c
>>>>> +++ b/fs/kernfs/dir.c
>>>>> @@ -1410,7 +1410,7 @@ int kernfs_remove_by_name_ns(struct
>>>>> kernfs_node
>>>>> *parent, const char *name,
>>>>> mutex_lock(&kernfs_mutex);
>>>>>
>>>>> kn = kernfs_find_ns(parent, name, ns);
>>>>> - if (kn)
>>>>> + if (kn && !(kn->flags & KERNFS_SUICIDED))
>>>>
>>>> Actually, wrong flag, you need KERNFS_SUICIDAL. The reason is that
>>>> kernfs_mutex is actually dropped half way through __kernfs_remove,
>>>> so KERNFS_SUICIDED is not set atomically with this mutex.
>>>
>>> Hello James,
>>>
>>> Sorry but what you wrote is not correct.
>>
>> I think you agree it is dropped. I don't need to add the bit about the
>> reacquisition because the race is mediated by the first acquisition not
>> the second one, if you mediate on KERNFS_SUICIDAL, you only need to
>> worry about this because the mediation is in the first acquisition. If
>> you mediate on KERNFS_SUICIDED, you need to explain that the final
>> thing that means the race can't happen is the unbreak in the sysfs
>> delete path re-acquiring s_active ... the explanation of what's going
>> on and why gets about 2x more complex.
>
> Is it really the dropping of the lock that is causing this?
> I don't see that when I read those traces.
>
> I am going to put my vote in for doing all of the self removal
> sem-asynchronously by using task_work_add, and killing
> device_remove_self, sysfs_remove_self, kernfs_remove_self. Using
> task_work_add remains synchronous with userspace so userspace should not
> care, and we get the benefit of not having two different variants of the
> same code racing with each other.
>
> It might take a little more work but will leave code that is much more
> maintainable in the long run.
Hello Eric,
I'm completely in favor of keeping code maintainable. But what's not
clear to me is whether asynchronous I/O can be submitted to a sysfs
attribute? If so, on what context will task work queued through
task_work_add() be executed if an aio write is used to write into a
sysfs attribute?
Additionally, can a process enter the exiting state after writing into
the sysfs delete attribute started and before task_work_add() has been
called? I'm asking this because in that case task_work_add() will fail.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH v7 06/17] ref-filter: introduce format_ref_array_item()
From: Jacob Keller @ 2016-11-08 23:32 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <20161108201211.25213-7-Karthik.188@gmail.com>
On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> To allow column display, we will need to first render the output in a
> string list to allow print_columns() to compute the proper size of
> each column before starting the actual output. Introduce the function
> format_ref_array_item() that does the formatting of a ref_array_item
> to an strbuf.
>
Makes sense.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v7 05/17] ref-filter: move get_head_description() from branch.c
From: Jacob Keller @ 2016-11-08 23:31 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <20161108201211.25213-6-Karthik.188@gmail.com>
On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> Move the implementation of get_head_description() from branch.c to
> ref-filter. This gives a description of the HEAD ref if called. This
> is used as the refname for the HEAD ref whenever the
> FILTER_REFS_DETACHED_HEAD option is used. Make it public because we
> need it to calculate the length of the HEAD refs description in
> branch.c:calc_maxwidth() when we port branch.c to use ref-filter
> APIs.
>
Makes sense.
>
> - if (starts_with(name, "refname"))
> + if (starts_with(name, "refname")) {
> refname = ref->refname;
> - else if (starts_with(name, "symref"))
> + if (ref->kind & FILTER_REFS_DETACHED_HEAD)
> + refname = get_head_description();
Since this (I think?) changes behavior of refname would it make sense
to add a test for this?
Thanks,
Jake
> + } else if (starts_with(name, "symref"))
> refname = ref->symref ? ref->symref : "";
> else if (starts_with(name, "upstream")) {
> const char *branch_name;
> diff --git a/ref-filter.h b/ref-filter.h
> index 14d435e..4aea594 100644
> --- a/ref-filter.h
> +++ b/ref-filter.h
> @@ -106,5 +106,7 @@ int parse_opt_ref_sorting(const struct option *opt, const char *arg, int unset);
> struct ref_sorting *ref_default_sorting(void);
> /* Function to parse --merged and --no-merged options */
> int parse_opt_merge_filter(const struct option *opt, const char *arg, int unset);
> +/* Get the current HEAD's description */
> +char *get_head_description(void);
>
> #endif /* REF_FILTER_H */
> --
> 2.10.2
>
^ permalink raw reply
* status of spdk
From: Yehuda Sadeh-Weinraub @ 2016-11-08 23:31 UTC (permalink / raw)
To: Wang, Haomai, Weil, Sage; +Cc: ceph-devel
I just started looking at spdk, and have a few comments and questions.
First, it's not clear to me how we should handle build. At the moment
the spdk code resides as a submodule in the ceph tree, but it depends
on dpdk, which currently needs to be downloaded separately. We can add
it as a submodule (upstream is here: git://dpdk.org/dpdk). That been
said, getting it to build was a bit tricky and I think it might be
broken with cmake. In order to get it working I resorted to building a
system library and use that.
The way to currently configure an osd to use bluestore with spdk is by
creating a symbolic link that replaces the bluestore 'block' device to
point to a file that has a name that is prefixed with 'spdk:'.
Originally I assumed that the suffix would be the nvme device id, but
it seems that it's not really needed, however, the file itself needs
to contain the device id (see
https://github.com/yehudasa/ceph/tree/wip-yehuda-spdk for a couple of
minor fixes).
As I understand it, in order to support multiple osds on the same NVMe
device we have a few options. We can leverage NVMe namespaces, but
that's not supported on all devices. We can configure bluestore to
only use part of the device (device sharding? not sure if it supports
it). I think it's best if we could keep bluestore out of the loop
there and have the NVMe driver abstract multiple partitions of the
NVMe device. The idea is to be able to define multiple partitions on
the device (e.g., each partition will be defined by the offset, size,
and namespace), and have the osd set to use a specific partition.
We'll probably need a special tool to manage it, and potentially keep
the partition table information on the device itself. The tool could
also manage the creation of the block link. We should probably rethink
how the link is structure and what it points at.
Any thoughts?
Yehuda
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.