* [PATCH v3 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400
From: Stefano Stabellini @ 2016-11-08 19:42 UTC (permalink / raw)
To: xen-devel; +Cc: julien.grall, sstabellini, wei.liu2
In-Reply-To: <1478634163-27368-1-git-send-email-sstabellini@kernel.org>
Commit 21550029f709072aacf3b90edd574e7d3021b400 removed the
PLATFORM_QUIRK_GIC_64K_STRIDE quirk and introduced a way to
automatically detect that the two GICC pages have a 64K stride.
However the heuristic requires that the device tree for the platform
reports a GICC size == 128K, which is not the case for some versions of
XGene.
Fix the issue by partially reverting
21550029f709072aacf3b90edd574e7d3021b400:
- reintroduce PLATFORM_QUIRK_GIC_64K_STRIDE for XGene
- force csize and vsize to SZ_128K if csize is initially 4K and if
PLATFORM_QUIRK_GIC_64K_STRIDE
Also add a warning in case GICC is SZ_128K but not aliased.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
---
Changes in v3:
- add a warning when enabling the quirk
- update comment to match the new behavior of the quirk
Changes in v2:
- only set csize to SZ_128K if it is initially SZ_4K
- set vsize to match
- add warning if gicc is SZ_128K and not aliased
---
xen/arch/arm/gic-v2.c | 12 ++++++++++--
xen/arch/arm/platforms/xgene-storm.c | 6 ++++++
xen/include/asm-arm/platform.h | 7 +++++++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9bd9d0b..bca6d27 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -965,7 +965,12 @@ static void __init gicv2_dt_init(void)
printk(XENLOG_WARNING "GICv2: WARNING: "
"The GICC size is too small: %#"PRIx64" expected %#x\n",
csize, SZ_8K);
- csize = SZ_8K;
+ if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
+ {
+ printk(XENLOG_WARNING "GICv2: enable platform quirk: 64K stride\n");
+ vsize = csize = SZ_128K;
+ } else
+ csize = SZ_8K;
}
/*
@@ -1189,7 +1194,10 @@ static int __init gicv2_init(void)
printk(XENLOG_WARNING
"GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
cbase + aliased_offset);
- }
+ } else if ( csize == SZ_128K )
+ printk(XENLOG_WARNING
+ "GICv2: GICC size=%lu but not aliased\n",
+ csize);
gicv2.map_hbase = ioremap_nocache(hbase, PAGE_SIZE);
if ( !gicv2.map_hbase )
diff --git a/xen/arch/arm/platforms/xgene-storm.c b/xen/arch/arm/platforms/xgene-storm.c
index 686b19b..c795a95 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -67,6 +67,11 @@ static void __init xgene_check_pirq_eoi(void)
"Please upgrade your firmware to the latest version");
}
+static uint32_t xgene_storm_quirks(void)
+{
+ return PLATFORM_QUIRK_GIC_64K_STRIDE;
+}
+
static void xgene_storm_reset(void)
{
void __iomem *addr;
@@ -116,6 +121,7 @@ PLATFORM_START(xgene_storm, "APM X-GENE STORM")
.compatible = xgene_storm_dt_compat,
.init = xgene_storm_init,
.reset = xgene_storm_reset,
+ .quirks = xgene_storm_quirks,
PLATFORM_END
/*
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index c6e5010..08010ba 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -39,6 +39,13 @@ struct platform_desc {
const struct dt_device_match *blacklist_dev;
};
+/*
+ * Quirk for platforms where device tree incorrectly reports 4K GICC
+ * size, but actually the two GICC register ranges are placed at 64K
+ * stride.
+ */
+#define PLATFORM_QUIRK_GIC_64K_STRIDE (1 << 0)
+
void __init platform_init(void);
int __init platform_init_time(void);
int __init platform_specific_mapping(struct domain *d);
--
1.9.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support
From: Greg Kroah-Hartman @ 2016-11-08 19:43 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Lukas Wunner, Rafael J. Wysocki, Linux PM list, Alan Stern,
Linux Kernel Mailing List, Tomeu Vizoso, Mark Brown,
Marek Szyprowski, Kevin Hilman, Ulf Hansson, Laurent Pinchart,
Lars-Peter Clausen, Grant Likely, Mauro Carvalho Chehab,
Andrzej Hajda
In-Reply-To: <20161108192103.GN1764@wotan.suse.de>
On Tue, Nov 08, 2016 at 08:21:04PM +0100, Luis R. Rodriguez wrote:
> On Tue, Nov 08, 2016 at 07:45:41AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Nov 07, 2016 at 10:22:50PM +0100, Luis R. Rodriguez wrote:
> > > We have no explicit semantics to check if a driver / subsystem
> > > supports deferred probe.
> >
> > Why would we need such a thing?
>
> It depends on the impact of a driver/subsystem not properly supporting
> deffered probe, if this is no-op then such a need is not critical but
> would be good to proactively inform developers / users so they avoid
> its use, if this will cause issues its perhaps best to make this a
> no-op through a check. AFAICT reviewing implications of not supporting
> deferred probe on drivers/subsytsems for this framework is not clearly
> spelled out, if we start considering re-using this framework for probe
> ordering I'd hate to see issues come up without this corner case being
> concretely considered.
It should not matter to the driver core if a subsystem, or a driver,
supports or does not support deferred probe. It's a quick and simple
solution to a complex problem that works well. Yes, you can iterate a
lot of times, but that's fine, we have time at boot to do that (and
really, it is fast.)
> Furthermore -- how does this framework compare to Andrzej's resource tracking
> solution? I confess I have not had a chance yet to review yet but in light of
> this question it would be good to know if Andrzej's framework also requires
> deferred probe as similar concerns would exist there as well.
I have no idea what "framework" you are talking about here, do you have
a pointer to patches?
thanks,
greg k-h
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/3] target-i386: Add Intel HAX files
From: Vincent Palatin @ 2016-11-08 19:43 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <40c9ae8c-629c-b75a-8213-71e0332d02da@redhat.com>
On Tue, Nov 8, 2016 at 6:46 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 08/11/2016 16:39, Vincent Palatin wrote:
>> + /* need tcg for non-UG platform in real mode */
>> + if (!hax_ug_platform())
>> + tcg_exec_init(tcg_tb_size * 1024 * 1024);
>> +
>
> Oh, it does support unrestricted guest, and in fact without unrestricted
> guest you don't even have SMP!
>
> Would you post a v2 that removes (after this patch 2) as much code as
> possible related to non-UG platforms?
Yes I can do this.
--
Vincent
^ permalink raw reply
* Re: net/l2tp: use-after-free write in l2tp_ip6_close
From: Andrey Konovalov @ 2016-11-08 19:45 UTC (permalink / raw)
To: syzkaller
Cc: David S. Miller, Eric Dumazet, Willem de Bruijn,
Hannes Frederic Sowa, Soheil Hassas Yeganeh, Shmulik Ladkani,
Wei Wang, Haishuang Yan, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, Alexander Potapenko
In-Reply-To: <CAM_iQpVkKyEsPDse5wnM=WGbbXwSWE5fBSHwonhS3a3i4A-Twg@mail.gmail.com>
Hi Cong,
Tried with your patch, still seeing the reports.
Thanks!
On Tue, Nov 8, 2016 at 12:02 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Nov 7, 2016 at 2:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> Hi,
>>
>> I've got the following error report while running the syzkaller fuzzer:
>>
>> ==================================================================
>> BUG: KASAN: use-after-free in l2tp_ip6_close+0x239/0x2a0 at addr
>> ffff8800677276d8
>> Write of size 8 by task a.out/8668
>> CPU: 0 PID: 8668 Comm: a.out Not tainted 4.9.0-rc4+ #354
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff8800694d7b00 ffffffff81b46a64 ffff88006adb5780 ffff8800677276c0
>> ffff880067727c68 ffff8800677276c0 ffff8800694d7b28 ffffffff8150a86c
>> ffff8800694d7bb8 ffff88006adb5780 ffff8800e77276d8 ffff8800694d7ba8
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff81b46a64>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
>> [<ffffffff8150a86c>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
>> [< inline >] print_address_description mm/kasan/report.c:194
>> [<ffffffff8150ab07>] kasan_report_error+0x1f7/0x4d0 mm/kasan/report.c:283
>> [< inline >] kasan_report mm/kasan/report.c:303
>> [<ffffffff8150b01e>] __asan_report_store8_noabort+0x3e/0x40
>> mm/kasan/report.c:329
>> [< inline >] __write_once_size ./include/linux/compiler.h:272
>> [< inline >] __hlist_del ./include/linux/list.h:622
>> [< inline >] hlist_del_init ./include/linux/list.h:637
>> [<ffffffff83825f49>] l2tp_ip6_close+0x239/0x2a0 net/l2tp/l2tp_ip6.c:239
>> [<ffffffff8316b31f>] inet_release+0xef/0x1c0 net/ipv4/af_inet.c:415
>> [<ffffffff832cd4d0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
>> [<ffffffff82b6d89e>] sock_release+0x8e/0x1d0 net/socket.c:570
>> [<ffffffff82b6d9f6>] sock_close+0x16/0x20 net/socket.c:1017
>> [<ffffffff81524bdd>] __fput+0x29d/0x720 fs/file_table.c:208
>> [<ffffffff815250e5>] ____fput+0x15/0x20 fs/file_table.c:244
>> [<ffffffff81172928>] task_work_run+0xf8/0x170 kernel/task_work.c:116
>> [< inline >] exit_task_work ./include/linux/task_work.h:21
>> [<ffffffff8111bda3>] do_exit+0x883/0x2ac0 kernel/exit.c:828
>> [<ffffffff8112234e>] do_group_exit+0x10e/0x340 kernel/exit.c:931
>> [< inline >] SYSC_exit_group kernel/exit.c:942
>> [<ffffffff8112259d>] SyS_exit_group+0x1d/0x20 kernel/exit.c:940
>> [<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>
> I guess we need to lock the sock for l2tp_ip6_disconnect() too.
>
> diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
> index ad3468c..ea2ae66 100644
> --- a/net/l2tp/l2tp_ip6.c
> +++ b/net/l2tp/l2tp_ip6.c
> @@ -410,7 +410,7 @@ static int l2tp_ip6_disconnect(struct sock *sk, int flags)
> if (sock_flag(sk, SOCK_ZAPPED))
> return 0;
>
> - return __udp_disconnect(sk, flags);
> + return udp_disconnect(sk, flags);
> }
>
> static int l2tp_ip6_getname(struct socket *sock, struct sockaddr *uaddr,
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [Linux-ima-devel] [PATCH v6 02/10] ima: on soft reboot, restore the measurement list
From: Dmitry Kasatkin @ 2016-11-08 19:46 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-3-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 TPM PCRs are only reset on a hard reboot. In order to validate a
> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> of the running kernel must be saved and restored on boot. This patch
> restores the measurement list.
>
> Changelog v5:
> - replace CONFIG_KEXEC_FILE with architecture CONFIG_HAVE_IMA_KEXEC (Thiago)
> - replace kexec_get_handover_buffer() with ima_get_kexec_buffer() (Thiago)
> - replace kexec_free_handover_buffer() with ima_free_kexec_buffer() (Thiago)
> - remove unnecessary includes from ima_kexec.c (Thiago)
> - fix off-by-one error when checking hdr_v1->template_name_len (Colin King)
>
> Changelog v2:
> - redefined ima_kexec_hdr to use types with well defined sizes (M. Ellerman)
> - defined missing ima_load_kexec_buffer() stub function
>
> Changelog v1:
> - call ima_load_kexec_buffer() (Thiago)
>
> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
> ---
> security/integrity/ima/Makefile | 1 +
> security/integrity/ima/ima.h | 21 +++++
> security/integrity/ima/ima_init.c | 2 +
> security/integrity/ima/ima_kexec.c | 44 +++++++++
> security/integrity/ima/ima_queue.c | 10 ++
> security/integrity/ima/ima_template.c | 170 ++++++++++++++++++++++++++++++++++
> 6 files changed, 248 insertions(+)
>
> diff --git a/security/integrity/ima/Makefile b/security/integrity/ima/Makefile
> index 9aeaedad1e2b..29f198bde02b 100644
> --- a/security/integrity/ima/Makefile
> +++ b/security/integrity/ima/Makefile
> @@ -8,4 +8,5 @@ obj-$(CONFIG_IMA) += ima.o
> ima-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o \
> ima_policy.o ima_template.o ima_template_lib.o
> ima-$(CONFIG_IMA_APPRAISE) += ima_appraise.o
> +ima-$(CONFIG_HAVE_IMA_KEXEC) += ima_kexec.o
> obj-$(CONFIG_IMA_BLACKLIST_KEYRING) += ima_mok.o
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index db25f54a04fe..51dc8d57d64d 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -28,6 +28,10 @@
>
> #include "../integrity.h"
>
> +#ifdef CONFIG_HAVE_IMA_KEXEC
> +#include <asm/ima.h>
> +#endif
> +
> enum ima_show_type { IMA_SHOW_BINARY, IMA_SHOW_BINARY_NO_FIELD_LEN,
> IMA_SHOW_BINARY_OLD_STRING_FMT, IMA_SHOW_ASCII };
> enum tpm_pcrs { TPM_PCR0 = 0, TPM_PCR8 = 8 };
> @@ -102,6 +106,21 @@ struct ima_queue_entry {
> };
> extern struct list_head ima_measurements; /* list of all measurements */
>
> +/* Some details preceding the binary serialized measurement list */
> +struct ima_kexec_hdr {
> + u16 version;
> + u16 _reserved0;
> + u32 _reserved1;
> + u64 buffer_size;
> + u64 count;
> +};
> +
> +#ifdef CONFIG_HAVE_IMA_KEXEC
> +void ima_load_kexec_buffer(void);
> +#else
> +static inline void ima_load_kexec_buffer(void) {}
> +#endif /* CONFIG_HAVE_IMA_KEXEC */
> +
> /* Internal IMA function definitions */
> int ima_init(void);
> int ima_fs_init(void);
> @@ -122,6 +141,8 @@ int ima_init_crypto(void);
> void ima_putc(struct seq_file *m, void *data, int datalen);
> void ima_print_digest(struct seq_file *m, u8 *digest, u32 size);
> struct ima_template_desc *ima_template_desc_current(void);
> +int ima_restore_measurement_entry(struct ima_template_entry *entry);
> +int ima_restore_measurement_list(loff_t bufsize, void *buf);
> int ima_init_template(void);
>
> /*
> diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> index 32912bd54ead..3ba0ca49cba6 100644
> --- a/security/integrity/ima/ima_init.c
> +++ b/security/integrity/ima/ima_init.c
> @@ -128,6 +128,8 @@ int __init ima_init(void)
> if (rc != 0)
> return rc;
>
> + ima_load_kexec_buffer();
> +
> rc = ima_add_boot_aggregate(); /* boot aggregate must be first entry */
> if (rc != 0)
> return rc;
> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> new file mode 100644
> index 000000000000..36afd0fe9747
> --- /dev/null
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright (C) 2016 IBM Corporation
> + *
> + * Authors:
> + * Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
> + * Mimi Zohar <zohar@linux.vnet.ibm.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include "ima.h"
> +
> +/*
> + * Restore the measurement list from the previous kernel.
> + */
> +void ima_load_kexec_buffer(void)
> +{
> + void *kexec_buffer = NULL;
> + size_t kexec_buffer_size = 0;
> + int rc;
> +
> + rc = ima_get_kexec_buffer(&kexec_buffer, &kexec_buffer_size);
> + switch (rc) {
> + case 0:
> + rc = ima_restore_measurement_list(kexec_buffer_size,
> + kexec_buffer);
> + if (rc != 0)
> + pr_err("Failed to restore the measurement list: %d\n",
> + rc);
> +
> + ima_free_kexec_buffer();
> + break;
> + case -ENOTSUPP:
> + pr_debug("Restoring the measurement list not supported\n");
> + break;
> + case -ENOENT:
> + pr_debug("No measurement list to restore\n");
> + break;
> + default:
> + pr_debug("Error restoring the measurement list: %d\n", rc);
> + }
> +}
> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
> index 32f6ac0f96df..4b1bb7787839 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -149,3 +149,13 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
> op, audit_cause, result, audit_info);
> return result;
> }
> +
> +int ima_restore_measurement_entry(struct ima_template_entry *entry)
> +{
> + int result = 0;
> +
> + mutex_lock(&ima_extend_list_mutex);
> + result = ima_add_digest_entry(entry);
> + mutex_unlock(&ima_extend_list_mutex);
> + return result;
> +}
> diff --git a/security/integrity/ima/ima_template.c b/security/integrity/ima/ima_template.c
> index febd12ed9b55..37f972cb05fe 100644
> --- a/security/integrity/ima/ima_template.c
> +++ b/security/integrity/ima/ima_template.c
> @@ -37,6 +37,7 @@ static struct ima_template_field supported_fields[] = {
> {.field_id = "sig", .field_init = ima_eventsig_init,
> .field_show = ima_show_template_sig},
> };
> +#define MAX_TEMPLATE_NAME_LEN 15
>
> static struct ima_template_desc *ima_template;
> static struct ima_template_desc *lookup_template_desc(const char *name);
> @@ -205,3 +206,172 @@ int __init ima_init_template(void)
>
> return result;
> }
> +
> +static int ima_restore_template_data(struct ima_template_desc *template_desc,
> + void *template_data,
> + int template_data_size,
> + struct ima_template_entry **entry)
> +{
> + struct binary_field_data {
> + u32 len;
> + u8 data[0];
> + } __packed;
> +
> + struct binary_field_data *field_data;
> + int offset = 0;
> + int ret = 0;
> + int i;
> +
> + *entry = kzalloc(sizeof(**entry) +
> + template_desc->num_fields * sizeof(struct ima_field_data),
> + GFP_NOFS);
> + if (!*entry)
> + return -ENOMEM;
> +
> + (*entry)->template_desc = template_desc;
> + for (i = 0; i < template_desc->num_fields; i++) {
> + field_data = template_data + offset;
> +
> + /* Each field of the template data is prefixed with a length. */
> + if (offset > (template_data_size - sizeof(field_data->len))) {
> + pr_err("Restoring the template field failed\n");
> + ret = -EINVAL;
> + break;
> + }
> + offset += sizeof(field_data->len);
> +
> + if (offset > (template_data_size - field_data->len)) {
> + pr_err("Restoring the template field data failed\n");
> + ret = -EINVAL;
> + break;
> + }
> + offset += field_data->len;
> +
> + (*entry)->template_data[i].len = field_data->len;
> + (*entry)->template_data_len += sizeof(field_data->len);
> +
> + (*entry)->template_data[i].data =
> + kzalloc(field_data->len + 1, GFP_KERNEL);
> + if (!(*entry)->template_data[i].data) {
> + ret = -ENOMEM;
> + break;
> + }
> + memcpy((*entry)->template_data[i].data, field_data->data,
> + field_data->len);
> + (*entry)->template_data_len += field_data->len;
> + }
> +
> + if (ret < 0) {
> + ima_free_template_entry(*entry);
> + *entry = NULL;
> + }
> +
> + return ret;
> +}
> +
> +/* Restore the serialized binary measurement list without extending PCRs. */
> +int ima_restore_measurement_list(loff_t size, void *buf)
> +{
> + struct binary_hdr_v1 {
> + u32 pcr;
> + u8 digest[TPM_DIGEST_SIZE];
> + u32 template_name_len;
> + char template_name[0];
> + } __packed;
> + char template_name[MAX_TEMPLATE_NAME_LEN];
> +
> + struct binary_data_v1 {
> + u32 template_data_size;
> + char template_data[0];
> + } __packed;
> +
> + struct ima_kexec_hdr *khdr = buf;
> + struct binary_hdr_v1 *hdr_v1;
> + struct binary_data_v1 *data_v1;
> +
> + void *bufp = buf + sizeof(*khdr);
> + void *bufendp = buf + khdr->buffer_size;
> + struct ima_template_entry *entry;
> + struct ima_template_desc *template_desc;
> + unsigned long count = 0;
> + int ret = 0;
> +
> + if (!buf || size < sizeof(*khdr))
> + return 0;
> +
> + if (khdr->version != 1) {
> + pr_err("attempting to restore a incompatible measurement list");
> + return 0;
> + }
> +
> + /*
> + * ima kexec buffer prefix: version, buffer size, count
> + * v1 format: pcr, digest, template-name-len, template-name,
> + * template-data-size, template-data
> + */
> + while ((bufp < bufendp) && (count++ < khdr->count)) {
> + if (count > ULONG_MAX - 1) {
> + pr_err("attempting to restore too many measurements");
> + ret = -EINVAL;
> + }
> +
> + hdr_v1 = bufp;
> + if ((hdr_v1->template_name_len >= MAX_TEMPLATE_NAME_LEN) ||
> + ((bufp + hdr_v1->template_name_len) > bufendp)) {
based on following code template_name_len does not include header
(sizeof(*hdr_v1))?
If so the check is wrong???
> + pr_err("attempting to restore a template name \
> + that is too long\n");
> + ret = -EINVAL;
> + break;
> + }
> + bufp += sizeof(*hdr_v1);
> +
> + /* template name is not null terminated */
> + memcpy(template_name, bufp, hdr_v1->template_name_len);
> + template_name[hdr_v1->template_name_len] = 0;
> +
> + if (strcmp(template_name, "ima") == 0) {
> + pr_err("attempting to restore an unsupported \
> + template \"%s\" failed\n", template_name);
> + ret = -EINVAL;
> + break;
> + }
> + data_v1 = bufp += (u_int8_t)hdr_v1->template_name_len;
> +
> + /* get template format */
> + template_desc = lookup_template_desc(template_name);
> + if (!template_desc) {
> + pr_err("template \"%s\" not found\n", template_name);
> + ret = -EINVAL;
> + break;
> + }
> +
> + if (bufp > (bufendp - sizeof(data_v1->template_data_size))) {
> + pr_err("restoring the template data size failed\n");
> + ret = -EINVAL;
> + break;
> + }
> + bufp += (u_int8_t) sizeof(data_v1->template_data_size);
> +
> + if (bufp > (bufendp - data_v1->template_data_size)) {
> + pr_err("restoring the template data failed\n");
> + ret = -EINVAL;
> + break;
> + }
> +
It looks like a similar problem... sizeof(struct binary_data_v1) is
missing in the check...
> + ret = ima_restore_template_data(template_desc,
> + data_v1->template_data,
> + data_v1->template_data_size,
> + &entry);
> + if (ret < 0)
> + break;
> +
> + memcpy(entry->digest, hdr_v1->digest, TPM_DIGEST_SIZE);
> + entry->pcr = hdr_v1->pcr;
> + ret = ima_restore_measurement_entry(entry);
> + if (ret < 0)
> + break;
> +
> + bufp += data_v1->template_data_size;
> + }
> + return ret;
> +}
> --
> 2.7.4
>
In overall it is a bit hard to read this function somehow..
Dmitry
>
> ------------------------------------------------------------------------------
> 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: [Linux-ima-devel] [PATCH v6 02/10] ima: on soft reboot, restore the measurement list
From: Dmitry Kasatkin @ 2016-11-08 19:46 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-3-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 TPM PCRs are only reset on a hard reboot. In order to validate a
> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> of the running kernel must be saved and restored on boot. This patch
> restores the measurement list.
>
> Changelog v5:
> - replace CONFIG_KEXEC_FILE with architecture CONFIG_HAVE_IMA_KEXEC (Thiago)
> - replace kexec_get_handover_buffer() with ima_get_kexec_buffer() (Thiago)
> - replace kexec_free_handover_buffer() with ima_free_kexec_buffer() (Thiago)
> - remove unnecessary includes from ima_kexec.c (Thiago)
> - fix off-by-one error when checking hdr_v1->template_name_len (Colin King)
>
> Changelog v2:
> - redefined ima_kexec_hdr to use types with well defined sizes (M. Ellerman)
> - defined missing ima_load_kexec_buffer() stub function
>
> Changelog v1:
> - call ima_load_kexec_buffer() (Thiago)
>
> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
> ---
> security/integrity/ima/Makefile | 1 +
> security/integrity/ima/ima.h | 21 +++++
> security/integrity/ima/ima_init.c | 2 +
> security/integrity/ima/ima_kexec.c | 44 +++++++++
> security/integrity/ima/ima_queue.c | 10 ++
> security/integrity/ima/ima_template.c | 170 ++++++++++++++++++++++++++++++++++
> 6 files changed, 248 insertions(+)
>
> diff --git a/security/integrity/ima/Makefile b/security/integrity/ima/Makefile
> index 9aeaedad1e2b..29f198bde02b 100644
> --- a/security/integrity/ima/Makefile
> +++ b/security/integrity/ima/Makefile
> @@ -8,4 +8,5 @@ obj-$(CONFIG_IMA) += ima.o
> ima-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o \
> ima_policy.o ima_template.o ima_template_lib.o
> ima-$(CONFIG_IMA_APPRAISE) += ima_appraise.o
> +ima-$(CONFIG_HAVE_IMA_KEXEC) += ima_kexec.o
> obj-$(CONFIG_IMA_BLACKLIST_KEYRING) += ima_mok.o
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index db25f54a04fe..51dc8d57d64d 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -28,6 +28,10 @@
>
> #include "../integrity.h"
>
> +#ifdef CONFIG_HAVE_IMA_KEXEC
> +#include <asm/ima.h>
> +#endif
> +
> enum ima_show_type { IMA_SHOW_BINARY, IMA_SHOW_BINARY_NO_FIELD_LEN,
> IMA_SHOW_BINARY_OLD_STRING_FMT, IMA_SHOW_ASCII };
> enum tpm_pcrs { TPM_PCR0 = 0, TPM_PCR8 = 8 };
> @@ -102,6 +106,21 @@ struct ima_queue_entry {
> };
> extern struct list_head ima_measurements; /* list of all measurements */
>
> +/* Some details preceding the binary serialized measurement list */
> +struct ima_kexec_hdr {
> + u16 version;
> + u16 _reserved0;
> + u32 _reserved1;
> + u64 buffer_size;
> + u64 count;
> +};
> +
> +#ifdef CONFIG_HAVE_IMA_KEXEC
> +void ima_load_kexec_buffer(void);
> +#else
> +static inline void ima_load_kexec_buffer(void) {}
> +#endif /* CONFIG_HAVE_IMA_KEXEC */
> +
> /* Internal IMA function definitions */
> int ima_init(void);
> int ima_fs_init(void);
> @@ -122,6 +141,8 @@ int ima_init_crypto(void);
> void ima_putc(struct seq_file *m, void *data, int datalen);
> void ima_print_digest(struct seq_file *m, u8 *digest, u32 size);
> struct ima_template_desc *ima_template_desc_current(void);
> +int ima_restore_measurement_entry(struct ima_template_entry *entry);
> +int ima_restore_measurement_list(loff_t bufsize, void *buf);
> int ima_init_template(void);
>
> /*
> diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> index 32912bd54ead..3ba0ca49cba6 100644
> --- a/security/integrity/ima/ima_init.c
> +++ b/security/integrity/ima/ima_init.c
> @@ -128,6 +128,8 @@ int __init ima_init(void)
> if (rc != 0)
> return rc;
>
> + ima_load_kexec_buffer();
> +
> rc = ima_add_boot_aggregate(); /* boot aggregate must be first entry */
> if (rc != 0)
> return rc;
> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> new file mode 100644
> index 000000000000..36afd0fe9747
> --- /dev/null
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright (C) 2016 IBM Corporation
> + *
> + * Authors:
> + * Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
> + * Mimi Zohar <zohar@linux.vnet.ibm.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include "ima.h"
> +
> +/*
> + * Restore the measurement list from the previous kernel.
> + */
> +void ima_load_kexec_buffer(void)
> +{
> + void *kexec_buffer = NULL;
> + size_t kexec_buffer_size = 0;
> + int rc;
> +
> + rc = ima_get_kexec_buffer(&kexec_buffer, &kexec_buffer_size);
> + switch (rc) {
> + case 0:
> + rc = ima_restore_measurement_list(kexec_buffer_size,
> + kexec_buffer);
> + if (rc != 0)
> + pr_err("Failed to restore the measurement list: %d\n",
> + rc);
> +
> + ima_free_kexec_buffer();
> + break;
> + case -ENOTSUPP:
> + pr_debug("Restoring the measurement list not supported\n");
> + break;
> + case -ENOENT:
> + pr_debug("No measurement list to restore\n");
> + break;
> + default:
> + pr_debug("Error restoring the measurement list: %d\n", rc);
> + }
> +}
> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
> index 32f6ac0f96df..4b1bb7787839 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -149,3 +149,13 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
> op, audit_cause, result, audit_info);
> return result;
> }
> +
> +int ima_restore_measurement_entry(struct ima_template_entry *entry)
> +{
> + int result = 0;
> +
> + mutex_lock(&ima_extend_list_mutex);
> + result = ima_add_digest_entry(entry);
> + mutex_unlock(&ima_extend_list_mutex);
> + return result;
> +}
> diff --git a/security/integrity/ima/ima_template.c b/security/integrity/ima/ima_template.c
> index febd12ed9b55..37f972cb05fe 100644
> --- a/security/integrity/ima/ima_template.c
> +++ b/security/integrity/ima/ima_template.c
> @@ -37,6 +37,7 @@ static struct ima_template_field supported_fields[] = {
> {.field_id = "sig", .field_init = ima_eventsig_init,
> .field_show = ima_show_template_sig},
> };
> +#define MAX_TEMPLATE_NAME_LEN 15
>
> static struct ima_template_desc *ima_template;
> static struct ima_template_desc *lookup_template_desc(const char *name);
> @@ -205,3 +206,172 @@ int __init ima_init_template(void)
>
> return result;
> }
> +
> +static int ima_restore_template_data(struct ima_template_desc *template_desc,
> + void *template_data,
> + int template_data_size,
> + struct ima_template_entry **entry)
> +{
> + struct binary_field_data {
> + u32 len;
> + u8 data[0];
> + } __packed;
> +
> + struct binary_field_data *field_data;
> + int offset = 0;
> + int ret = 0;
> + int i;
> +
> + *entry = kzalloc(sizeof(**entry) +
> + template_desc->num_fields * sizeof(struct ima_field_data),
> + GFP_NOFS);
> + if (!*entry)
> + return -ENOMEM;
> +
> + (*entry)->template_desc = template_desc;
> + for (i = 0; i < template_desc->num_fields; i++) {
> + field_data = template_data + offset;
> +
> + /* Each field of the template data is prefixed with a length. */
> + if (offset > (template_data_size - sizeof(field_data->len))) {
> + pr_err("Restoring the template field failed\n");
> + ret = -EINVAL;
> + break;
> + }
> + offset += sizeof(field_data->len);
> +
> + if (offset > (template_data_size - field_data->len)) {
> + pr_err("Restoring the template field data failed\n");
> + ret = -EINVAL;
> + break;
> + }
> + offset += field_data->len;
> +
> + (*entry)->template_data[i].len = field_data->len;
> + (*entry)->template_data_len += sizeof(field_data->len);
> +
> + (*entry)->template_data[i].data =
> + kzalloc(field_data->len + 1, GFP_KERNEL);
> + if (!(*entry)->template_data[i].data) {
> + ret = -ENOMEM;
> + break;
> + }
> + memcpy((*entry)->template_data[i].data, field_data->data,
> + field_data->len);
> + (*entry)->template_data_len += field_data->len;
> + }
> +
> + if (ret < 0) {
> + ima_free_template_entry(*entry);
> + *entry = NULL;
> + }
> +
> + return ret;
> +}
> +
> +/* Restore the serialized binary measurement list without extending PCRs. */
> +int ima_restore_measurement_list(loff_t size, void *buf)
> +{
> + struct binary_hdr_v1 {
> + u32 pcr;
> + u8 digest[TPM_DIGEST_SIZE];
> + u32 template_name_len;
> + char template_name[0];
> + } __packed;
> + char template_name[MAX_TEMPLATE_NAME_LEN];
> +
> + struct binary_data_v1 {
> + u32 template_data_size;
> + char template_data[0];
> + } __packed;
> +
> + struct ima_kexec_hdr *khdr = buf;
> + struct binary_hdr_v1 *hdr_v1;
> + struct binary_data_v1 *data_v1;
> +
> + void *bufp = buf + sizeof(*khdr);
> + void *bufendp = buf + khdr->buffer_size;
> + struct ima_template_entry *entry;
> + struct ima_template_desc *template_desc;
> + unsigned long count = 0;
> + int ret = 0;
> +
> + if (!buf || size < sizeof(*khdr))
> + return 0;
> +
> + if (khdr->version != 1) {
> + pr_err("attempting to restore a incompatible measurement list");
> + return 0;
> + }
> +
> + /*
> + * ima kexec buffer prefix: version, buffer size, count
> + * v1 format: pcr, digest, template-name-len, template-name,
> + * template-data-size, template-data
> + */
> + while ((bufp < bufendp) && (count++ < khdr->count)) {
> + if (count > ULONG_MAX - 1) {
> + pr_err("attempting to restore too many measurements");
> + ret = -EINVAL;
> + }
> +
> + hdr_v1 = bufp;
> + if ((hdr_v1->template_name_len >= MAX_TEMPLATE_NAME_LEN) ||
> + ((bufp + hdr_v1->template_name_len) > bufendp)) {
based on following code template_name_len does not include header
(sizeof(*hdr_v1))?
If so the check is wrong???
> + pr_err("attempting to restore a template name \
> + that is too long\n");
> + ret = -EINVAL;
> + break;
> + }
> + bufp += sizeof(*hdr_v1);
> +
> + /* template name is not null terminated */
> + memcpy(template_name, bufp, hdr_v1->template_name_len);
> + template_name[hdr_v1->template_name_len] = 0;
> +
> + if (strcmp(template_name, "ima") == 0) {
> + pr_err("attempting to restore an unsupported \
> + template \"%s\" failed\n", template_name);
> + ret = -EINVAL;
> + break;
> + }
> + data_v1 = bufp += (u_int8_t)hdr_v1->template_name_len;
> +
> + /* get template format */
> + template_desc = lookup_template_desc(template_name);
> + if (!template_desc) {
> + pr_err("template \"%s\" not found\n", template_name);
> + ret = -EINVAL;
> + break;
> + }
> +
> + if (bufp > (bufendp - sizeof(data_v1->template_data_size))) {
> + pr_err("restoring the template data size failed\n");
> + ret = -EINVAL;
> + break;
> + }
> + bufp += (u_int8_t) sizeof(data_v1->template_data_size);
> +
> + if (bufp > (bufendp - data_v1->template_data_size)) {
> + pr_err("restoring the template data failed\n");
> + ret = -EINVAL;
> + break;
> + }
> +
It looks like a similar problem... sizeof(struct binary_data_v1) is
missing in the check...
> + ret = ima_restore_template_data(template_desc,
> + data_v1->template_data,
> + data_v1->template_data_size,
> + &entry);
> + if (ret < 0)
> + break;
> +
> + memcpy(entry->digest, hdr_v1->digest, TPM_DIGEST_SIZE);
> + entry->pcr = hdr_v1->pcr;
> + ret = ima_restore_measurement_entry(entry);
> + if (ret < 0)
> + break;
> +
> + bufp += data_v1->template_data_size;
> + }
> + return ret;
> +}
> --
> 2.7.4
>
In overall it is a bit hard to read this function somehow..
Dmitry
>
> ------------------------------------------------------------------------------
> 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: BUG: Hung task timeouts in for-4.10/dio
From: Logan Gunthorpe @ 2016-11-08 19:47 UTC (permalink / raw)
To: Jens Axboe, Christoph Hellwig; +Cc: linux-block, Stephen Bates
In-Reply-To: <6997fb64-aaac-208f-fa89-b8b4567f7321@fb.com>
Hey,
On 08/11/16 12:19 PM, Jens Axboe wrote:
> Can you try and boot for-4.10/block instead?
Yup. I'm seeing the same issue with that branch too. (b57d74a)
Thanks,
Logan
^ permalink raw reply
* [U-Boot] U-Boot overlaps BSS and initrd on arm64
From: Tom Rini @ 2016-11-08 19:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161108193434.GB17771@arm.com>
On Tue, Nov 08, 2016 at 07:34:34PM +0000, Will Deacon wrote:
> On Tue, Nov 08, 2016 at 01:04:40PM -0500, Tom Rini wrote:
> > On Tue, Nov 08, 2016 at 06:01:42PM +0000, Will Deacon wrote:
> > > On Tue, Nov 08, 2016 at 12:51:44PM -0500, Tom Rini wrote:
> > > > On Tue, Nov 08, 2016 at 09:41:13AM -0800, Dmitry Vyukov wrote:
> > > > > Hello,
> > > > >
> > > > > We've got a boot problem on arm64 devices. Here is boot log:
> > > > > https://storage.kernelci.org/mainline/v4.9-rc4/arm64-defconfig+CONFIG_KASAN=y/lab-baylibre-seattle/boot-juno-r2.txt
> > > > > https://kernelci.org/boot/id/581ece5a59b514e448f03bd7/
> > > > >
> > > > > Here is some debugging that Andrey and Mark did:
> > > > >
> > > > > On Tue, Nov 8, 2016 at 2:00 AM, Andrey Ryabinin wrote:
> > > > > > I've looked at juno-r2: https://kernelci.org/boot/id/581ece5a59b514e448f03bd7/
> > > > > > So we have
> > > > > > Dtb address 0x81f00000
> > > > > > Load address 0x80000000
> > > > > > Which gives us 31Mb for kernel.
> > > > > >
> > > > > > It says that Kernel image is 24.62 MiB, but that's without BSS.
> > > > > > If bss is big enough it might overwrite dtb.
> > > > > > And indeed, build details -
> > > > > > https://kernelci.org/build/id/581e850959b514e564f03bdc/
> > > > > > shows that bss is 8.5 Mb which is enough to overlap with dtb.
> > > > >
> > > > > On Tue, Nov 8, 2016 at 3:21 AM, Mark Rutland wrote:
> > > > > > FWIW, since v3.17 we've had an image_size field in the arm64 Image
> > > > > > header which describes the "real" size of the Image, BSS included. See
> > > > > > [1,2].
> > > > > > It should be possible to modify U-Boot to use that to automatically
> > > > > > place the DTB and initrd at non-clashing locations (or at least to
> > > > > > expose the value somehow).
> > > > > > I had assumed U-Boot already did that, but it doesn't seem to be the
> > > > > > case.
> > > >
> > > > Yes, we've supported the image_size field since v2016.07 and that board
> > > > is running v2016.01. Unfortunately the booting.txt changes that added
> > > > the image_size field weren't publicized widely so we didn't see it until
> > > > someone else ran into the problem you're describing.
> > >
> > > Hmm, that's a good point. If you like, I could add something to that file
> > > asking for all changes to CC the u-boot list? We should probably do the
> > > same for edk2.
> >
> > That would be nice, sure. I was even thinking that something like the
> > cross-distro or boot-architecture lists that linaro runs would have had
> > this info go by as well. Thanks!
>
> D'oh, the u-boot list seems to be subscriber-only, so I'm not going to make
> a whole lot of friends if I ask kernel devs to add it to cc.
Ah yes. So boot-architecture is probably best.
> Also, you apparently Acked the image_size change:
>
> http://git.kernel.org/linus/a2c1d73b94ed
>
> so it was at least partially publicized ;)
Ah yes, now I recall :) In my defense, I ack'd them when it was going
around, but I never saw when it went in.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161108/ec6a2d22/attachment.sig>
^ permalink raw reply
* [Intel-wired-lan] [PATCH v2] ixgbe: handle close/suspend race with netif_device_detach/present
From: Emil Tantilov @ 2016-11-08 19:47 UTC (permalink / raw)
To: intel-wired-lan
When an interface is part of a namespace it is possible that
ixgbe_close() may be called while __ixgbe_shutdown() is running
which ends up in a double free WARN and/or a BUG in free_msi_irqs().
To handle this situation we extend the rtnl_lock() to protect the
call to netif_device_detach() and ixgbe_clear_interrupt_scheme()
in __ixgbe_shutdown() and check for netif_device_present()
to avoid clearing the interrupts second time in ixgbe_close() and
ixgbe_remove().
Also extend the rtnl lock in ixgbe_resume() to netif_device_attach().
v2 - add rtnl locks and a check in ixgbe_remove()
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 51cdac9..0b1fa5d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6200,7 +6200,8 @@ int ixgbe_close(struct net_device *netdev)
ixgbe_ptp_stop(adapter);
- ixgbe_close_suspend(adapter);
+ if (netif_device_present(netdev))
+ ixgbe_close_suspend(adapter);
ixgbe_fdir_filter_exit(adapter);
@@ -6245,14 +6246,12 @@ static int ixgbe_resume(struct pci_dev *pdev)
if (!err && netif_running(netdev))
err = ixgbe_open(netdev);
- rtnl_unlock();
-
- if (err)
- return err;
- netif_device_attach(netdev);
+ if (!err)
+ netif_device_attach(netdev);
+ rtnl_unlock();
- return 0;
+ return err;
}
#endif /* CONFIG_PM */
@@ -6267,14 +6266,14 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake)
int retval = 0;
#endif
+ rtnl_lock();
netif_device_detach(netdev);
- rtnl_lock();
if (netif_running(netdev))
ixgbe_close_suspend(adapter);
- rtnl_unlock();
ixgbe_clear_interrupt_scheme(adapter);
+ rtnl_unlock();
#ifdef CONFIG_PM
retval = pci_save_state(pdev);
@@ -9923,7 +9922,10 @@ static void ixgbe_remove(struct pci_dev *pdev)
if (netdev->reg_state == NETREG_REGISTERED)
unregister_netdev(netdev);
- ixgbe_clear_interrupt_scheme(adapter);
+ rtnl_lock();
+ if (netif_device_present(netdev))
+ ixgbe_clear_interrupt_scheme(adapter);
+ rtnl_unlock();
ixgbe_release_hw_control(adapter);
^ permalink raw reply related
* Re: [Linux-ima-devel] [PATCH v6 03/10] ima: permit duplicate measurement list entries
From: Dmitry Kasatkin @ 2016-11-08 19:47 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-4-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>
>
> Measurements carried across kexec need to be added to the IMA
> measurement list, but should not prevent measurements of the newly
> booted kernel from being added to the measurement list. This patch
> adds support for allowing duplicate measurements.
>
> The "boot_aggregate" measurement entry is the delimiter between soft
> boots.
>
> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
> ---
> security/integrity/ima/ima_queue.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
> index 4b1bb7787839..12d1b040bca9 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -65,11 +65,12 @@ static struct ima_queue_entry *ima_lookup_digest_entry(u8 *digest_value,
> }
>
> /* ima_add_template_entry helper function:
> - * - Add template entry to measurement list and hash table.
> + * - Add template entry to the measurement list and hash table, for
> + * all entries except those carried across kexec.
> *
> * (Called with ima_extend_list_mutex held.)
> */
> -static int ima_add_digest_entry(struct ima_template_entry *entry)
> +static int ima_add_digest_entry(struct ima_template_entry *entry, int flags)
> {
> struct ima_queue_entry *qe;
> unsigned int key;
> @@ -85,8 +86,10 @@ static int ima_add_digest_entry(struct ima_template_entry *entry)
> list_add_tail_rcu(&qe->later, &ima_measurements);
>
> atomic_long_inc(&ima_htable.len);
> - key = ima_hash_key(entry->digest);
> - hlist_add_head_rcu(&qe->hnext, &ima_htable.queue[key]);
> + if (flags) {
It looks lile "bool", not flags in fact.
> + key = ima_hash_key(entry->digest);
> + hlist_add_head_rcu(&qe->hnext, &ima_htable.queue[key]);
> + }
> return 0;
> }
>
> @@ -126,7 +129,7 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
> }
> }
>
> - result = ima_add_digest_entry(entry);
> + result = ima_add_digest_entry(entry, 1);
> if (result < 0) {
> audit_cause = "ENOMEM";
> audit_info = 0;
> @@ -155,7 +158,7 @@ int ima_restore_measurement_entry(struct ima_template_entry *entry)
> int result = 0;
>
> mutex_lock(&ima_extend_list_mutex);
> - result = ima_add_digest_entry(entry);
> + result = ima_add_digest_entry(entry, 0);
> mutex_unlock(&ima_extend_list_mutex);
> return result;
> }
> --
> 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
* [Ocfs2-devel] Announcing btrfs-dedupe
From: Darrick J. Wong @ 2016-11-08 19:47 UTC (permalink / raw)
To: Mark Fasheh
Cc: Adam Borowski, dsterba, James Pharaoh, linux-btrfs, ocfs2-devel
In-Reply-To: <CAGe7X7m-rPmGxk3DXuo6Vo5qAQwRhNFEKyRZzYxP2iyy1mGrSw@mail.gmail.com>
On Tue, Nov 08, 2016 at 10:59:56AM -0800, Mark Fasheh wrote:
> On Mon, Nov 7, 2016 at 6:17 PM, Darrick J. Wong <darrick.wong@oracle.com> wrote:
> > On Mon, Nov 07, 2016 at 09:54:09PM +0100, Adam Borowski wrote:
> >> Mark has already included XFS in documentation of duperemove, all that looks
> >> amiss is btrfs-extent-same having an obsolete name. But then, I never did
> >> any non-superficial tests on XFS, beyond "seems to work".
>
> I'd actually be ok dropping btrfs-extent-same completely at this point
> but I'm concerned that it would leave some users behind.
>
>
> > /me wonders if ocfs2 will ever catch up to the reflink/dedupe party. ;)
>
> Hey, Ocfs2 started the reflink party! But yeah it's fallen behind
> since then with respect to cow and dedupe. More importantly though I'd
> like to see some extra extent tracking in there like XFS did with the
> reflink b+tree.
Perhaps this should move to the ocfs2 list, but...
...as I understand ocfs2, each inode can point to the head of a refcount
tree that maintains refcounts for all the physical blocks that are
mapped by any of the files that share that refcount tree. It wouldn't
be difficult to hook up this existing refcount structure to the reflink
and dedupe vfs ioctls, with the huge caveat that both inodes will end up
belonging to the same refcount tree (or the call fails). This might not
be such a huge issue for reflink since we're generally only using it
during a file copy anyway, but for dedupe this could have disastrous
consequences if someone does an fs-wide dedupe and every file in the fs
ends up with the same refcount tree.
So I guess you could give each block group its own refcount tree or
something so that all the writes in the fs don't end up contending for a
single data structure.
--D
> --Mark
>
> --
> "When the going gets weird, the weird turn pro."
> Hunter S. Thompson
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Darrick J. Wong @ 2016-11-08 19:47 UTC (permalink / raw)
To: Mark Fasheh
Cc: Adam Borowski, dsterba, James Pharaoh, linux-btrfs, ocfs2-devel
In-Reply-To: <CAGe7X7m-rPmGxk3DXuo6Vo5qAQwRhNFEKyRZzYxP2iyy1mGrSw@mail.gmail.com>
On Tue, Nov 08, 2016 at 10:59:56AM -0800, Mark Fasheh wrote:
> On Mon, Nov 7, 2016 at 6:17 PM, Darrick J. Wong <darrick.wong@oracle.com> wrote:
> > On Mon, Nov 07, 2016 at 09:54:09PM +0100, Adam Borowski wrote:
> >> Mark has already included XFS in documentation of duperemove, all that looks
> >> amiss is btrfs-extent-same having an obsolete name. But then, I never did
> >> any non-superficial tests on XFS, beyond "seems to work".
>
> I'd actually be ok dropping btrfs-extent-same completely at this point
> but I'm concerned that it would leave some users behind.
>
>
> > /me wonders if ocfs2 will ever catch up to the reflink/dedupe party. ;)
>
> Hey, Ocfs2 started the reflink party! But yeah it's fallen behind
> since then with respect to cow and dedupe. More importantly though I'd
> like to see some extra extent tracking in there like XFS did with the
> reflink b+tree.
Perhaps this should move to the ocfs2 list, but...
...as I understand ocfs2, each inode can point to the head of a refcount
tree that maintains refcounts for all the physical blocks that are
mapped by any of the files that share that refcount tree. It wouldn't
be difficult to hook up this existing refcount structure to the reflink
and dedupe vfs ioctls, with the huge caveat that both inodes will end up
belonging to the same refcount tree (or the call fails). This might not
be such a huge issue for reflink since we're generally only using it
during a file copy anyway, but for dedupe this could have disastrous
consequences if someone does an fs-wide dedupe and every file in the fs
ends up with the same refcount tree.
So I guess you could give each block group its own refcount tree or
something so that all the writes in the fs don't end up contending for a
single data structure.
--D
> --Mark
>
> --
> "When the going gets weird, the weird turn pro."
> Hunter S. Thompson
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Linux-ima-devel] [PATCH v6 03/10] ima: permit duplicate measurement list entries
From: Dmitry Kasatkin @ 2016-11-08 19:47 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-4-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>
>
> Measurements carried across kexec need to be added to the IMA
> measurement list, but should not prevent measurements of the newly
> booted kernel from being added to the measurement list. This patch
> adds support for allowing duplicate measurements.
>
> The "boot_aggregate" measurement entry is the delimiter between soft
> boots.
>
> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
> ---
> security/integrity/ima/ima_queue.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
> index 4b1bb7787839..12d1b040bca9 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -65,11 +65,12 @@ static struct ima_queue_entry *ima_lookup_digest_entry(u8 *digest_value,
> }
>
> /* ima_add_template_entry helper function:
> - * - Add template entry to measurement list and hash table.
> + * - Add template entry to the measurement list and hash table, for
> + * all entries except those carried across kexec.
> *
> * (Called with ima_extend_list_mutex held.)
> */
> -static int ima_add_digest_entry(struct ima_template_entry *entry)
> +static int ima_add_digest_entry(struct ima_template_entry *entry, int flags)
> {
> struct ima_queue_entry *qe;
> unsigned int key;
> @@ -85,8 +86,10 @@ static int ima_add_digest_entry(struct ima_template_entry *entry)
> list_add_tail_rcu(&qe->later, &ima_measurements);
>
> atomic_long_inc(&ima_htable.len);
> - key = ima_hash_key(entry->digest);
> - hlist_add_head_rcu(&qe->hnext, &ima_htable.queue[key]);
> + if (flags) {
It looks lile "bool", not flags in fact.
> + key = ima_hash_key(entry->digest);
> + hlist_add_head_rcu(&qe->hnext, &ima_htable.queue[key]);
> + }
> return 0;
> }
>
> @@ -126,7 +129,7 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
> }
> }
>
> - result = ima_add_digest_entry(entry);
> + result = ima_add_digest_entry(entry, 1);
> if (result < 0) {
> audit_cause = "ENOMEM";
> audit_info = 0;
> @@ -155,7 +158,7 @@ int ima_restore_measurement_entry(struct ima_template_entry *entry)
> int result = 0;
>
> mutex_lock(&ima_extend_list_mutex);
> - result = ima_add_digest_entry(entry);
> + result = ima_add_digest_entry(entry, 0);
> mutex_unlock(&ima_extend_list_mutex);
> return result;
> }
> --
> 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: [RFC][ATCH 1/3] ptrace: Remove maxargs from task_current_syscall()
From: Steven Rostedt @ 2016-11-08 19:48 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Linus Torvalds, Linux Kernel Mailing List, Ingo Molnar,
Andrew Morton, Roland McGrath, Oleg Nesterov,
linux-arch@vger.kernel.org, Peter Zijlstra
In-Reply-To: <CALCETrUBLL+2bU+A03sEns=ESjTXModxwuxiH1EHj__SDp2hgA@mail.gmail.com>
On Tue, 8 Nov 2016 08:20:48 -0800
Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Nov 8, 2016 at 8:16 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > So I definitely approve of the change, but I wonder if we should go
> > one step further:
> >
> > On Mon, Nov 7, 2016 at 1:26 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >>
> >> extern int task_current_syscall(struct task_struct *target, long *callno,
> >> - unsigned long args[6], unsigned int maxargs,
> >> - unsigned long *sp, unsigned long *pc);
> >> + unsigned long args[6], unsigned long *sp,
> >> + unsigned long *pc);
> >
> > The thing is, in C, having an array in a function declaration is
> > pretty much exactly the same as just having a pointer, so from a type
> > checking standpoint it doesn't really help all that much (but from a
> > "human documentation" side the "args[6]" is much better than "*args").
> >
> > However, what would really help type checking is making it a
> > structure. And maybe that structure could just contain "callno", "sp"
> > and "pc" too? That would not only fix the type checking, it would make
> > the calling convention even cleaner. Just have one single structure
> > that contains all the relevant data.
>
> I would propose calling this 'struct seccomp_data'.
I'm assuming you mean to use the existing seccomp_data? But isn't that
already defined as a user structure? Thus, we can't add sp and pc to it.
I can change syscall_get_arguments() to take the seccomp_data as an
input, and just fill in the arguments directly.
-- Steve
^ permalink raw reply
* [Buildroot] [PATCH 1/1] php-fpm: remove config comments to fix startup
From: Frank Hunleth @ 2016-11-08 19:49 UTC (permalink / raw)
To: buildroot
The comments in the Buildroot-provided php-fpm.conf would produce the
following error when starting php-fpm:
ERROR: [/etc/php-fpm.conf:2] value is NULL for a ZEND_INI_PARSER_ENTRY
Removing the comments fixes the problem.
Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
---
package/php/php-fpm.conf | 3 ---
1 file changed, 3 deletions(-)
diff --git a/package/php/php-fpm.conf b/package/php/php-fpm.conf
index b75a58f..88014b8 100644
--- a/package/php/php-fpm.conf
+++ b/package/php/php-fpm.conf
@@ -1,9 +1,6 @@
[www]
-# Only start children when there are requests to be processed
pm = ondemand
-# Terminate them again after there haven't been any for 2 minutes
pm.process_idle_timeout = 120s
-# Maximum number of children processing PHP requests concurrently
pm.max_children = 5
listen = /var/run/php-fpm.sock
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v1] ufs: introduce UFSHCD_QUIRK_USE_OF_HCE quirk
From: Subhash Jadavani @ 2016-11-08 19:50 UTC (permalink / raw)
To: Kiwoong Kim
Cc: James E.J. Bottomley, linux-scsi, Martin K. Petersen,
vinholikatti, 추헌광, linux-scsi-owner
In-Reply-To: <002301d23995$c3be88c0$4b3b9a40$@samsung.com>
On 2016-11-07 23:57, Kiwoong Kim wrote:
> Some host controller might not initialize itself
> by setting "Host Controller Enable" to 1.
> They should do this to reset UIC.
I am not sure if i understood this statment. can you give more details?
> In such cases, 'DME reset' and 'DME enable' are required
> for normal subsequent operations.
This means HCE implementation is broken, you should name the quirk as
UFSHCD_QUIRK_BROKEN_HCE .
>
> Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
> ---
> drivers/scsi/ufs/ufshcd.c | 44
> +++++++++++++++++++++++++++++++++++++++++++-
> drivers/scsi/ufs/ufshcd.h | 1 +
> 2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 24d6ea7..c904854 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -2496,6 +2496,37 @@ static inline void
> ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba)
> usleep_range(min_sleep_time_us, min_sleep_time_us + 50);
> }
>
> +static int ufshcd_dme_reset(struct ufs_hba *hba)
> +{
> + struct uic_command uic_cmd = {0};
> + int ret;
> +
> + uic_cmd.command = UIC_CMD_DME_RESET;
> + uic_cmd.argument1 = 0x1;
> +
> + ret = ufshcd_send_uic_cmd(hba, &uic_cmd);
> + if (ret)
> + dev_err(hba->dev,
> + "dme-reset: error code %d\n", ret);
This error message doesn't say which DME command failed, do you want to
add that?
> +
> + return ret;
> +}
> +
> +static int ufshcd_dme_enable(struct ufs_hba *hba)
> +{
> + struct uic_command uic_cmd = {0};
> + int ret;
> +
> + uic_cmd.command = UIC_CMD_DME_ENABLE;
> +
> + ret = ufshcd_send_uic_cmd(hba, &uic_cmd);
> + if (ret)
> + dev_err(hba->dev,
> + "dme-enable: error code %d\n", ret);
This error message doesn't say which DME command failed, do you want to
add that?
> +
> + return ret;
> +}
> +
> /**
> * ufshcd_dme_set_attr - UIC command for DME_SET, DME_PEER_SET
> * @hba: per adapter instance
> @@ -3101,6 +3132,7 @@ static inline void ufshcd_hba_stop(struct
> ufs_hba *hba, bool can_sleep)
> static int ufshcd_hba_enable(struct ufs_hba *hba)
> {
> int retry;
> + int ret = 0;
>
> /*
> * msleep of 1 and 5 used in this function might result in
> msleep(20),
> @@ -3117,6 +3149,9 @@ static int ufshcd_hba_enable(struct ufs_hba *hba)
>
> ufshcd_vops_hce_enable_notify(hba, PRE_CHANGE);
>
> + if (hba->quirks & UFSHCD_QUIRK_USE_OF_HCE)
> + goto use_dme;
> +
> /* start controller initialization sequence */
> ufshcd_hba_start(hba);
>
> @@ -3145,12 +3180,19 @@ static int ufshcd_hba_enable(struct ufs_hba
> *hba)
> msleep(5);
> }
>
> +use_dme:
> /* enable UIC related interrupts */
> ufshcd_enable_intr(hba, UFSHCD_UIC_MASK);
>
> + if (hba->quirks & UFSHCD_QUIRK_USE_OF_HCE) {
> + ret = ufshcd_dme_reset(hba);
> + if (!ret)
> + ret = ufshcd_dme_enable(hba);
> + }
> +
> ufshcd_vops_hce_enable_notify(hba, POST_CHANGE);
>
> - return 0;
> + return ret;
> }
>
> static int ufshcd_disable_tx_lcc(struct ufs_hba *hba, bool peer)
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index c4abd76..6a96f24 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -496,6 +496,7 @@ struct ufs_hba {
> #define UFSHCD_QUIRK_GET_VS_RESULT UFS_BIT(6)
> #define UFSHCD_QUIRK_BROKEN_DWORD_UTRD UFS_BIT(7)
> #define UFSHCD_QUIRK_BROKEN_REQ_LIST_CLR UFS_BIT(8)
> + #define UFSHCD_QUIRK_USE_OF_HCE UFS_BIT(9)
>
>
> unsigned int quirks; /* Deviations from standard UFSHCI spec. */
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature
From: Peter Zijlstra @ 2016-11-08 19:50 UTC (permalink / raw)
To: Daniel Bristot de Oliveira
Cc: Steven Rostedt, Ingo Molnar, Christoph Lameter, linux-rt-users,
LKML, Tommaso Cucinotta
In-Reply-To: <f4095990-3fa0-ac2f-7277-3b8f0cdbc333@redhat.com>
On Tue, Nov 08, 2016 at 08:29:49PM +0100, Daniel Bristot de Oliveira wrote:
>
>
> On 11/08/2016 07:05 PM, Peter Zijlstra wrote:
> >> >
> >> > I know what we want to do, but there's some momentous problems that
> >> > need to be solved first.
> > Like what?
>
> The problem is that using RT_RUNTIME_SHARE a CPU will almost always
> borrow enough runtime to make a CPU intensive rt task to run forever...
> well not forever, but until the system crash because a kworker starved
> in this CPU. Kworkers are sched fair by design and users do not always
> have a way to avoid them in an isolated CPU, for example.
>
> The user then can disable RT_RUNTIME_SHARE, but then the user will have
> the CPU going idle for (period - runtime) at each period... throwing CPU
> time in the trash.
So why is this a problem? You really should not be running that much
FIFO tasks to begin with.
So I'm willing to take out (or at least default disable
RT_RUNTIME_SHARE). But other than this, this never really worked to
begin with. So it cannot be a regression. And we've lived this long with
the 'problem'.
And that means this is a 'feature' and that means I say no.
We really should be doing the right thing here, not make a bigger mess.
^ permalink raw reply
* Re: BUG: Hung task timeouts in for-4.10/dio
From: Jens Axboe @ 2016-11-08 19:50 UTC (permalink / raw)
To: Logan Gunthorpe, Christoph Hellwig; +Cc: linux-block, Stephen Bates
In-Reply-To: <a74de948-3026-d9b3-6b2e-b9cc1f3c05d4@deltatee.com>
On 11/08/2016 12:47 PM, Logan Gunthorpe wrote:
> Hey,
>
> On 08/11/16 12:19 PM, Jens Axboe wrote:
>> Can you try and boot for-4.10/block instead?
>
> Yup. I'm seeing the same issue with that branch too. (b57d74a)
OK, let's get some more info on this setup then, so we can get to the
bottom of that. Can you send a dmesg from a working boot? What file
systems are you using? Etc.
--
Jens Axboe
^ permalink raw reply
* [PATCH lttng-tools v2] Fix: test cases now rely on explicit workloads
From: Francis Deslauriers @ 2016-11-08 19:49 UTC (permalink / raw)
To: lttng-dev; +Cc: jgalar
In-Reply-To: <1478630947-29321-1-git-send-email-francis.deslauriers@efficios.com>
Run a process explicitly in the tracing session to generate the enabled events
rather than relying on the events generated by the lttng CLI.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
---
tests/regression/kernel/test_all_events | 6 ++++++
tests/regression/kernel/test_event_basic | 14 ++++++++++++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/tests/regression/kernel/test_all_events b/tests/regression/kernel/test_all_events
index 50002f4..80a8020 100755
--- a/tests/regression/kernel/test_all_events
+++ b/tests/regression/kernel/test_all_events
@@ -21,6 +21,8 @@ CURDIR=$(dirname $0)/
TESTDIR=$CURDIR/../..
NUM_TESTS=8
+TESTCMD="grep -V -q > /dev/null"
+
source $TESTDIR/utils/utils.sh
function test_all_event()
@@ -33,6 +35,10 @@ function test_all_event()
lttng_enable_kernel_event $SESSION_NAME
start_lttng_tracing_ok
+
+ # Running a process and waiting for its completion forces the triggering of a
+ # sched_switch event
+ eval ${TESTCMD}
stop_lttng_tracing_ok
validate_trace "sched_switch" $TRACE_PATH
diff --git a/tests/regression/kernel/test_event_basic b/tests/regression/kernel/test_event_basic
index aeca02b..43c4fda 100755
--- a/tests/regression/kernel/test_event_basic
+++ b/tests/regression/kernel/test_event_basic
@@ -21,6 +21,8 @@ CURDIR=$(dirname $0)/
TESTDIR=$CURDIR/../..
NUM_TESTS=20
+TESTCMD="grep -V -q > /dev/null"
+
source $TESTDIR/utils/utils.sh
function test_event_basic()
@@ -32,14 +34,18 @@ function test_event_basic()
lttng_enable_kernel_event $SESSION_NAME "sched_switch"
lttng_enable_kernel_event $SESSION_NAME "sched_process_exit"
- lttng_enable_kernel_event $SESSION_NAME "sched_process_free"
+ lttng_enable_kernel_event $SESSION_NAME "sched_process_fork"
start_lttng_tracing_ok
+
+ # Running a process and waiting for its completion forces the triggering of
+ # fork, sched_switch and exit events
+ eval ${TESTCMD}
stop_lttng_tracing_ok
validate_trace "sched_switch" $TRACE_PATH
validate_trace "sched_process_exit" $TRACE_PATH
- validate_trace "sched_process_free" $TRACE_PATH
+ validate_trace "sched_process_fork" $TRACE_PATH
destroy_lttng_session_ok $SESSION_NAME
@@ -57,6 +63,10 @@ function test_enable_after_start()
start_lttng_tracing_ok
lttng_enable_kernel_event $SESSION_NAME "sched_process_exit"
+
+ # Running a process and waiting for its completion forces the triggering of
+ # sched_switch and exit events
+ eval ${TESTCMD}
stop_lttng_tracing_ok
validate_trace "sched_switch" $TRACE_PATH
--
2.7.4
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply related
* Re: [PATCH v2] irqchip/renesas-irqc: Postpone driver initialization
From: Geert Uytterhoeven @ 2016-11-08 19:50 UTC (permalink / raw)
To: Florian Fainelli
Cc: Geert Uytterhoeven, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Simon Horman, Magnus Damm, Linux-Renesas,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <216fe100-556b-7f83-39b0-4cf54c1fa35c@gmail.com>
Hi Florian,
On Tue, Nov 8, 2016 at 8:42 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 11/08/2016 11:35 AM, Geert Uytterhoeven wrote:
>> Currently the renesas-irqc driver uses postcore_initcall().
>>
>> However, the new CPG/MSSR driver uses subsys_initcall(). Hence the
>> IRQC's probe will be deferred, which causes the Micrel Ethernet PHY to
>> not find its interrupt on R-Car Gen2 and RZ/G, as the of_mdio subsystem
>> does not support deferred probe yet.
>
> Is not that the more correct fix to implement though?
Sure it is. But nothing has happened since this was reported ca. 1 year ago.
Cfr. "of_mdiobus_register_phy() and deferred probe"
https://lkml.org/lkml/2015/10/22/377
My MDIO foo is not that strong...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: WARNING: mismatch_cnt is not 0 on <array device>
From: Benjammin2068 @ 2016-11-08 19:52 UTC (permalink / raw)
To: Linux-RAID
In-Reply-To: <0f6bd6f6-20ee-1720-23fc-27d206063bfc@gmail.com>
Hey all,
I'm still trying to work through this..
I've replaced the cables on the new AOC-SAS2LP-MV8 and the card itself (supermicro sent replacements)
but I still occasionally have the mismatch_cnt error.. (like a week will go by and a weekend raid-check will happen with nothing.)
So -- my question now (as recommended by someone else) is how to see if it's a drive issue somehow. (not that it's a "real" drive issue, but a card firmware issue that's aggravated by a drive's firmware somehow.)
I've looked through the logs -- but how do I trace down a mismatch_cnt? I don't see anything in dmesg or messages....
There are a couple 3Gb/s drives attached to this card.. maybe that's it? Who knows? But I don't have debug info to help me chase it down now that I'm trying to work it out with Supermicro tech support.
Where do I look for more info about source or the event of the mismatch?
Thanks,
-Ben
^ permalink raw reply
* Re: WARNING: mismatch_cnt is not 0 on <array device>
From: Benjammin2068 @ 2016-11-08 19:53 UTC (permalink / raw)
To: Linux-RAID
In-Reply-To: <0f6bd6f6-20ee-1720-23fc-27d206063bfc@gmail.com>
On 11/08/2016 12:47 PM, Benjammin2068 wrote:
> Hey all,
>
> I'm still trying to work through this..
>
> I've replaced the cables on the new AOC-SAS2LP-MV8 and the card itself (supermicro sent replacements)
>
>
> but I still occasionally have the mismatch_cnt error.. (like a week will go by and a weekend raid-check will happen with nothing.)
>
> So -- my question now (as recommended by someone else) is how to see if it's a drive issue somehow. (not that it's a "real" drive issue, but a card firmware issue that's aggravated by a drive's firmware somehow.)
>
> I've looked through the logs -- but how do I trace down a mismatch_cnt? I don't see anything in dmesg or messages....
>
> There are a couple 3Gb/s drives attached to this card.. maybe that's it? Who knows? But I don't have debug info to help me chase it down now that I'm trying to work it out with Supermicro tech support.
>
> Where do I look for more info about source or the event of the mismatch?
>
>
Now that I think about it -- and have been talking out loud to myself (I don't think I'm crazy)...
A parallel to all this is:
I don't think the mismatch_cnt started showing up until I moved from RAID5 to RAID6.
:O
How painful is it to switch back to RAID5 to test that theory?
-Ben
^ permalink raw reply
* [PATCH v3 2/4] KVM: x86: save one bit in ctxt->d
From: Radim Krčmář @ 2016-11-08 19:54 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: Paolo Bonzini, Bandan Das, Nadav Amit
In-Reply-To: <20161108195419.4607-1-rkrcmar@redhat.com>
Alignments are exclusive, so 5 modes can be expressed in 3 bits.
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
---
arch/x86/kvm/emulate.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index eb74d3b56e1c..14624d6bf112 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -158,9 +158,11 @@
#define Src2GS (OpGS << Src2Shift)
#define Src2Mask (OpMask << Src2Shift)
#define Mmx ((u64)1 << 40) /* MMX Vector instruction */
+#define AlignMask ((u64)7 << 41)
#define Aligned ((u64)1 << 41) /* Explicitly aligned (e.g. MOVDQA) */
-#define Unaligned ((u64)1 << 42) /* Explicitly unaligned (e.g. MOVDQU) */
-#define Avx ((u64)1 << 43) /* Advanced Vector Extensions */
+#define Unaligned ((u64)2 << 41) /* Explicitly unaligned (e.g. MOVDQU) */
+#define Avx ((u64)3 << 41) /* Advanced Vector Extensions */
+#define Aligned16 ((u64)4 << 41) /* Aligned to 16 byte boundary (e.g. FXSAVE) */
#define Fastop ((u64)1 << 44) /* Use opcode::u.fastop */
#define NoWrite ((u64)1 << 45) /* No writeback */
#define SrcWrite ((u64)1 << 46) /* Write back src operand */
@@ -171,7 +173,6 @@
#define NearBranch ((u64)1 << 52) /* Near branches */
#define No16 ((u64)1 << 53) /* No 16 bit operand */
#define IncSP ((u64)1 << 54) /* SP is incremented before ModRM calc */
-#define Aligned16 ((u64)1 << 55) /* Aligned to 16 byte boundary (e.g. FXSAVE) */
#define DstXacc (DstAccLo | SrcAccHi | SrcWrite)
@@ -638,19 +639,21 @@ static void set_segment_selector(struct x86_emulate_ctxt *ctxt, u16 selector,
*/
static unsigned insn_alignment(struct x86_emulate_ctxt *ctxt, unsigned size)
{
+ u64 alignment = ctxt->d & AlignMask;
+
if (likely(size < 16))
return 1;
- if (ctxt->d & Aligned)
- return size;
- else if (ctxt->d & Unaligned)
+ switch (alignment) {
+ case Unaligned:
+ case Avx:
return 1;
- else if (ctxt->d & Avx)
- return 1;
- else if (ctxt->d & Aligned16)
+ case Aligned16:
return 16;
- else
+ case Aligned:
+ default:
return size;
+ }
}
static __always_inline int __linearize(struct x86_emulate_ctxt *ctxt,
--
2.10.2
^ permalink raw reply related
* [PATCH v3 0/4] KVM: x86: emulate FXSAVE and FXRSTOR
From: Radim Krčmář @ 2016-11-08 19:54 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: Paolo Bonzini, Bandan Das, Nadav Amit
v2: http://www.spinics.net/lists/kvm/msg139681.html
v3 brings compatibility with old compilers and has been compile-tested
with GCC-4.4 on Debian Wheezy, GCC-4.4 on RHEL 6, and GCC-4.1 on RHEL 5.
[4/4] still has the hidden assumption that guest and host CPUID match.
Emulating a guest that does not deprecaste FCS and FDS on a host that
does (a modern host) will not necessarily cause a problem, which is why
patches don't handle the case.
Enforcing the equality in CPUID update would be best, but another series
could do that as Linux doesn't even have the CPUID bit defined yet.
Radim Krčmář (4):
KVM: x86: add Align16 instruction flag
KVM: x86: save one bit in ctxt->d
KVM: x86: add asm_safe wrapper
KVM: x86: emulate FXSAVE and FXRSTOR
arch/x86/kvm/emulate.c | 184 +++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 157 insertions(+), 27 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH v3 1/4] KVM: x86: add Align16 instruction flag
From: Radim Krčmář @ 2016-11-08 19:54 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: Paolo Bonzini, Bandan Das, Nadav Amit
In-Reply-To: <20161108195419.4607-1-rkrcmar@redhat.com>
Needed for FXSAVE and FXRSTOR.
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
---
v2: split into a separate patch
---
arch/x86/kvm/emulate.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index cbd7b92585bb..eb74d3b56e1c 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -171,6 +171,7 @@
#define NearBranch ((u64)1 << 52) /* Near branches */
#define No16 ((u64)1 << 53) /* No 16 bit operand */
#define IncSP ((u64)1 << 54) /* SP is incremented before ModRM calc */
+#define Aligned16 ((u64)1 << 55) /* Aligned to 16 byte boundary (e.g. FXSAVE) */
#define DstXacc (DstAccLo | SrcAccHi | SrcWrite)
@@ -632,21 +633,24 @@ static void set_segment_selector(struct x86_emulate_ctxt *ctxt, u16 selector,
* depending on whether they're AVX encoded or not.
*
* Also included is CMPXCHG16B which is not a vector instruction, yet it is
- * subject to the same check.
+ * subject to the same check. FXSAVE and FXRSTOR are checked here too as their
+ * 512 bytes of data must be aligned to a 16 byte boundary.
*/
-static bool insn_aligned(struct x86_emulate_ctxt *ctxt, unsigned size)
+static unsigned insn_alignment(struct x86_emulate_ctxt *ctxt, unsigned size)
{
if (likely(size < 16))
- return false;
+ return 1;
if (ctxt->d & Aligned)
- return true;
+ return size;
else if (ctxt->d & Unaligned)
- return false;
+ return 1;
else if (ctxt->d & Avx)
- return false;
+ return 1;
+ else if (ctxt->d & Aligned16)
+ return 16;
else
- return true;
+ return size;
}
static __always_inline int __linearize(struct x86_emulate_ctxt *ctxt,
@@ -704,7 +708,7 @@ static __always_inline int __linearize(struct x86_emulate_ctxt *ctxt,
}
break;
}
- if (insn_aligned(ctxt, size) && ((la & (size - 1)) != 0))
+ if (la & (insn_alignment(ctxt, size) - 1))
return emulate_gp(ctxt, 0);
return X86EMUL_CONTINUE;
bad:
--
2.10.2
^ permalink raw reply related
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.