* [PATCH 0/9] tcmu: configuration fixes and cleanups
From: Mike Christie @ 2018-07-23 19:07 UTC (permalink / raw)
To: target-devel
The following patches were made over Martin's for-next branch.
The first patch fixes a locking bug in the command setup path. The rest
of the patches fix several bugs and cleanup the setup and configuration
code paths.
^ permalink raw reply
* Re: [PATCH v2 bpf 2/3] bpf: Replace [u]int32_t and [u]int64_t in libbpf
From: Yonghong Song @ 2018-07-23 18:04 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180721182043.1401089-3-kafai@fb.com>
On 7/21/18 11:20 AM, Martin KaFai Lau wrote:
> This patch replaces [u]int32_t and [u]int64_t usage with
> __[su]32 and __[su]64. The same change goes for [u]int16_t
> and [u]int8_t.
>
> Fixes: 8a138aed4a80 ("bpf: btf: Add BTF support to libbpf")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> ---
> tools/lib/bpf/btf.c | 28 +++++++++++++---------------
> tools/lib/bpf/btf.h | 8 ++++----
> tools/lib/bpf/libbpf.c | 12 ++++++------
> tools/lib/bpf/libbpf.h | 4 ++--
> 4 files changed, 25 insertions(+), 27 deletions(-)
>
> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index 8c54a4b6f187..ce77b5b57912 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -2,7 +2,6 @@
> /* Copyright (c) 2018 Facebook */
>
> #include <stdlib.h>
> -#include <stdint.h>
> #include <string.h>
> #include <unistd.h>
> #include <errno.h>
> @@ -27,13 +26,13 @@ struct btf {
> struct btf_type **types;
> const char *strings;
> void *nohdr_data;
> - uint32_t nr_types;
> - uint32_t types_size;
> - uint32_t data_size;
> + __u32 nr_types;
> + __u32 types_size;
> + __u32 data_size;
> int fd;
> };
>
> -static const char *btf_name_by_offset(const struct btf *btf, uint32_t offset)
> +static const char *btf_name_by_offset(const struct btf *btf, __u32 offset)
> {
> if (offset < btf->hdr->str_len)
> return &btf->strings[offset];
> @@ -151,7 +150,7 @@ static int btf_parse_type_sec(struct btf *btf, btf_print_fn_t err_log)
>
> while (next_type < end_type) {
> struct btf_type *t = next_type;
> - uint16_t vlen = BTF_INFO_VLEN(t->info);
> + __u16 vlen = BTF_INFO_VLEN(t->info);
> int err;
>
> next_type += sizeof(*t);
> @@ -191,7 +190,7 @@ static int btf_parse_type_sec(struct btf *btf, btf_print_fn_t err_log)
> }
>
> static const struct btf_type *btf_type_by_id(const struct btf *btf,
> - uint32_t type_id)
> + __u32 type_id)
> {
> if (type_id > btf->nr_types)
> return NULL;
> @@ -226,12 +225,12 @@ static int64_t btf_type_size(const struct btf_type *t)
Missing this one:
static int64_t btf_type_size(const struct btf_type *t)
There are a couple of instances of using u32 instead of __u32, better to
use __u32 everywhere in the same file:
u32 expand_by, new_size;
u32 meta_left;
>
> #define MAX_RESOLVE_DEPTH 32
>
> -int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id)
> +__s64 btf__resolve_size(const struct btf *btf, __u32 type_id)
> {
> const struct btf_array *array;
> const struct btf_type *t;
> - uint32_t nelems = 1;
> - int64_t size = -1;
> + __u32 nelems = 1;
> + __s64 size = -1;
> int i;
>
> t = btf_type_by_id(btf, type_id);
> @@ -271,9 +270,9 @@ int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id)
> return nelems * size;
> }
>
> -int32_t btf__find_by_name(const struct btf *btf, const char *type_name)
> +__s32 btf__find_by_name(const struct btf *btf, const char *type_name)
> {
> - uint32_t i;
> + __u32 i;
>
> if (!strcmp(type_name, "void"))
> return 0;
> @@ -302,10 +301,9 @@ void btf__free(struct btf *btf)
> free(btf);
> }
>
> -struct btf *btf__new(uint8_t *data, uint32_t size,
> - btf_print_fn_t err_log)
> +struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log)
> {
> - uint32_t log_buf_size = 0;
> + __u32 log_buf_size = 0;
> char *log_buf = NULL;
> struct btf *btf;
> int err;
> diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> index 74bb344035bb..ed3a84370ccc 100644
> --- a/tools/lib/bpf/btf.h
> +++ b/tools/lib/bpf/btf.h
> @@ -4,7 +4,7 @@
> #ifndef __BPF_BTF_H
> #define __BPF_BTF_H
>
> -#include <stdint.h>
> +#include <linux/types.h>
>
> #define BTF_ELF_SEC ".BTF"
>
> @@ -14,9 +14,9 @@ typedef int (*btf_print_fn_t)(const char *, ...)
> __attribute__((format(printf, 1, 2)));
>
> void btf__free(struct btf *btf);
> -struct btf *btf__new(uint8_t *data, uint32_t size, btf_print_fn_t err_log);
> -int32_t btf__find_by_name(const struct btf *btf, const char *type_name);
> -int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id);
> +struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log);
> +__s32 btf__find_by_name(const struct btf *btf, const char *type_name);
> +__s64 btf__resolve_size(const struct btf *btf, __u32 type_id);
> int btf__fd(const struct btf *btf);
>
> #endif
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index a1e96b5de5ff..6deb4fe4fffe 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -216,8 +216,8 @@ struct bpf_map {
> size_t offset;
> int map_ifindex;
> struct bpf_map_def def;
> - uint32_t btf_key_type_id;
> - uint32_t btf_value_type_id;
> + __u32 btf_key_type_id;
> + __u32 btf_value_type_id;
> void *priv;
> bpf_map_clear_priv_t clear_priv;
> };
> @@ -1016,8 +1016,8 @@ static int bpf_map_find_btf_info(struct bpf_map *map, const struct btf *btf)
> {
> struct bpf_map_def *def = &map->def;
> const size_t max_name = 256;
> - int64_t key_size, value_size;
> - int32_t key_id, value_id;
> + __s64 key_size, value_size;
> + __s32 key_id, value_id;
> char name[max_name];
>
> /* Find key type by name from BTF */
> @@ -2089,12 +2089,12 @@ const char *bpf_map__name(struct bpf_map *map)
> return map ? map->name : NULL;
> }
>
> -uint32_t bpf_map__btf_key_type_id(const struct bpf_map *map)
> +__u32 bpf_map__btf_key_type_id(const struct bpf_map *map)
> {
> return map ? map->btf_key_type_id : 0;
> }
>
> -uint32_t bpf_map__btf_value_type_id(const struct bpf_map *map)
> +__u32 bpf_map__btf_value_type_id(const struct bpf_map *map)
> {
> return map ? map->btf_value_type_id : 0;
> }
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 09976531aa74..b33ae02f7d0e 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -244,8 +244,8 @@ bpf_map__next(struct bpf_map *map, struct bpf_object *obj);
> int bpf_map__fd(struct bpf_map *map);
> const struct bpf_map_def *bpf_map__def(struct bpf_map *map);
> const char *bpf_map__name(struct bpf_map *map);
> -uint32_t bpf_map__btf_key_type_id(const struct bpf_map *map);
> -uint32_t bpf_map__btf_value_type_id(const struct bpf_map *map);
> +__u32 bpf_map__btf_key_type_id(const struct bpf_map *map);
> +__u32 bpf_map__btf_value_type_id(const struct bpf_map *map);
>
> typedef void (*bpf_map_clear_priv_t)(struct bpf_map *, void *);
> int bpf_map__set_priv(struct bpf_map *map, void *priv,
>
^ permalink raw reply
* Re: [EXTERNAL] [meta-processor-sdk][PATCH] tidl-utils: Add tidl-utils to devkit
From: Jacob Stiffler @ 2018-07-23 19:07 UTC (permalink / raw)
To: Djordje Senicic, meta-arago; +Cc: d-senicic1
In-Reply-To: <1532371124-500-1-git-send-email-x0157990@ti.com>
nativesdk-tidl-utils does not build.
ERROR: Nothing RPROVIDES 'nativesdk-tidl-api' (but
virtual:nativesdk:/media/hdd1/jake/oe/tisdk-rocko/sources/meta-arago/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'nativesdk-tidl-api' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-tidl-api']
ERROR: Required build target 'nativesdk-tidl-utils' has no buildable
providers.
Missing or unbuildable dependency chain was: ['nativesdk-tidl-utils',
'nativesdk-tidl-api']
ERROR: Nothing RPROVIDES 'nativesdk-tidl-api' (but
virtual:nativesdk:/media/hdd1/jake/oe/tisdk-rocko/sources/meta-arago/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'nativesdk-tidl-api' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-tidl-api']
ERROR: Required build target 'nativesdk-tidl-utils' has no buildable
providers.
Missing or unbuildable dependency chain was: ['nativesdk-tidl-utils',
'nativesdk-tidl-api']
On 7/23/2018 2:38 PM, Djordje Senicic wrote:
> * Include tidl-utils package along with tidl-viewer into devkit
>
> Signed-off-by: Djordje Senicic <x0157990@ti.com>
> ---
> .../packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend b/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend
> index 514d125..b0fafee 100644
> --- a/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend
> +++ b/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bbappend
> @@ -1,3 +1,3 @@
> -PR_append = ".tisdk0"
> +PR_append = ".tisdk1"
>
> -EXTRA_TI_TOOLS_append = " nativesdk-tidl-viewer"
> +EXTRA_TI_TOOLS_append = " nativesdk-tidl-viewer nativesdk-tidl-utils "
^ permalink raw reply
* Re: [PATCH v2] rfkill: fix spelling mistake contidion to condition
From: David Miller @ 2018-07-23 19:06 UTC (permalink / raw)
To: rgb; +Cc: netdev, linux-audit
In-Reply-To: <d20eb29b5ab96608af9e68ba219f15c3bdc080b4.1532369437.git.rgb@redhat.com>
From: Richard Guy Briggs <rgb@redhat.com>
Date: Mon, 23 Jul 2018 14:47:30 -0400
> This came about while trying to determine if there would be any pattern
> match on contid, a new audit container identifier internal variable.
> This was the only one.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
As per MAINTAINERS, rfkill patches should be sent to the linux-wireless
list and the maintainer, Johannes Berg.
Thank you.
^ permalink raw reply
* Re: [PATCH 03/11] ASoC: SOF: Add driver debug support.
From: Mark Brown @ 2018-07-23 19:03 UTC (permalink / raw)
To: Liam Girdwood; +Cc: alsa-devel
In-Reply-To: <20180719185335.30912-3-liam.r.girdwood@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 243 bytes --]
On Thu, Jul 19, 2018 at 07:53:27PM +0100, Liam Girdwood wrote:
> + /* copy from DSP MMIO */
> + pm_runtime_get(sdev->dev);
> + memcpy_fromio(buf, dfse->buf + pos, size);
> + pm_runtime_put(sdev->dev);
Doesn't this need to be a _get_sync()?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-3.0] tests/libqtest: Improve kill_qemu() assert
From: Peter Maydell @ 2018-07-23 19:02 UTC (permalink / raw)
To: Eric Blake
Cc: QEMU Developers, Michael S . Tsirkin, Richard Henderson,
Alex Bennée, Philippe Mathieu-Daudé, patches@linaro.org
In-Reply-To: <763fe1d3-e2ac-a3e6-69e7-edee07f3c578@redhat.com>
On 23 July 2018 at 19:59, Eric Blake <eblake@redhat.com> wrote:
> In other words, why are we special-casing death-by-coredump, when ALL
> non-zero exit status (whether or not a core dump was involved) is contrary
> to the assumptions of the testsuite?
Because we're trying to get as much actual information
as we have out into the logs, not merely "die so the test
fails"...
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH v3 2/3] perf arm64: Generate system call table from asm/unistd.h
From: Arnaldo Carvalho de Melo @ 2018-07-23 19:01 UTC (permalink / raw)
To: Kim Phillips
Cc: Arnaldo Carvalho de Melo, Ravi Bangoria, Alexander Shishkin,
Hendrik Brueckner, Jiri Olsa, Michael Ellerman, Namhyung Kim,
Thomas Richter, Peter Zijlstra, Ingo Molnar, linux-kernel
In-Reply-To: <20180723185905.GA13220@kernel.org>
Em Mon, Jul 23, 2018 at 03:59:05PM -0300, Arnaldo Carvalho de Melo escreveu:
> A quick hack is to do this instead:
I'm going with this quick hack applied so that I can pass all tests,
feel free to provide an alternative patch that makes
tools/include/uapi/asm-generic/unistd.h be used when included by
tools/arch/arm64/include/uapi/asm/unistd.h, that I haven't tried to do
and looks the right fix.
- Arnaldo
> diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
> index 85fdf4949db3..f013b115dc86 100644
> --- a/tools/perf/arch/arm64/Makefile
> +++ b/tools/perf/arch/arm64/Makefile
> @@ -11,7 +11,7 @@ PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
>
> out := $(OUTPUT)arch/arm64/include/generated/asm
> header := $(out)/syscalls.c
> -sysdef := $(srctree)/tools/arch/arm64/include/uapi/asm/unistd.h
> +sysdef := $(srctree)/tools/include/uapi/asm-generic/unistd.h
> sysprf := $(srctree)/tools/perf/arch/arm64/entry/syscalls/
> systbl := $(sysprf)/mksyscalltbl
>
> diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
> index c21023509960..52e197317d3e 100755
> --- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
> +++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
> @@ -28,6 +28,7 @@ create_table_from_c()
>
> cat <<-_EoHEADER
> #include <stdio.h>
> + #define __ARCH_WANT_RENAMEAT
> #include "$input"
> int main(int argc, char *argv[])
> {
^ permalink raw reply
* Re: [PATCH v2 bpf 1/3] bpf: btf: Sync uapi btf.h to tools
From: Yonghong Song @ 2018-07-23 17:58 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180721182043.1401089-2-kafai@fb.com>
On 7/21/18 11:20 AM, Martin KaFai Lau wrote:
> This patch sync the uapi btf.h to tools/
>
> Fixes: 36fc3c8c282c bpf: btf: Clean up BTF_INT_BITS() in uapi btf.h
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> tools/include/uapi/linux/btf.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/include/uapi/linux/btf.h b/tools/include/uapi/linux/btf.h
> index 0b5ddbe135a4..972265f32871 100644
> --- a/tools/include/uapi/linux/btf.h
> +++ b/tools/include/uapi/linux/btf.h
> @@ -76,7 +76,7 @@ struct btf_type {
> */
> #define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f000000) >> 24)
> #define BTF_INT_OFFSET(VAL) (((VAL & 0x00ff0000)) >> 16)
> -#define BTF_INT_BITS(VAL) ((VAL) & 0x0000ffff)
> +#define BTF_INT_BITS(VAL) ((VAL) & 0x000000ff)
>
> /* Attributes stored in the BTF_INT_ENCODING */
> #define BTF_INT_SIGNED (1 << 0)
^ permalink raw reply
* Re: [PATCH 0/3] PTI for x86-32 Fixes and Updates
From: Linus Torvalds @ 2018-07-23 19:00 UTC (permalink / raw)
To: Pavel Machek
Cc: Joerg Roedel, Thomas Gleixner, Ingo Molnar, Peter Anvin,
the arch/x86 maintainers, Linux Kernel Mailing List, linux-mm,
Andrew Lutomirski, Dave Hansen, Josh Poimboeuf,
Jürgen Groß, Peter Zijlstra, Borislav Petkov,
Jiri Kosina, Boris Ostrovsky, Brian Gerst, David Laight,
Denys Vlasenko, Eduardo Valentin, Greg Kroah-Hartman, Will Deacon,
Liguori, Anthony, Daniel Gruss, Hugh Dickins, Kees Cook,
Andrea Arcangeli, Waiman Long, David H . Gutteridge, Joerg Roedel,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim
In-Reply-To: <20180723140925.GA4285@amd>
On Mon, Jul 23, 2018 at 7:09 AM Pavel Machek <pavel@ucw.cz> wrote:
>
> Meanwhile... it looks like gcc is not slowed down significantly, but
> other stuff sees 30% .. 40% slowdowns... which is rather
> significant.
That is more or less expected.
Gcc spends about 90+% of its time in user space, and the system calls
it *does* do tend to be "real work" (open/read/etc). And modern gcc's
no longer have the pipe between cpp and cc1, so they don't have that
issue either (which would have sjhown the PTI slowdown a lot more)
Some other loads will do a lot more time traversing the user/kernel
boundary, and in 32-bit mode you won't be able to take advantage of
the address space ID's, so you really get the full effect.
> Would it be possible to have per-process control of kpti? I have
> some processes where trading of speed for security would make sense.
That was pretty extensively discussed, and no sane model for it was
ever agreed upon. Some people wanted it per-thread, others per-mm,
and it wasn't clear how to set it either and how it should inherit
across fork/exec, and what the namespace rules etc should be.
You absolutely need to inherit it (so that you can say "I trust this
session" or whatever), but at the same time you *don't* want to
inherit if you have a server you trust that then spawns user processes
(think "I want systemd to not have the overhead, but the user
processes it spawns obviously do need protection").
It was just a morass. Nothing came out of it. I guess people can
discuss it again, but it's not simple.
Linus
^ permalink raw reply
* Re: rte_mbuf library likely()/unlikely()
From: Morten Brørup @ 2018-07-23 18:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Olivier Matz, dev
In-Reply-To: <20180723103757.47e4c26b@xeon-e3>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, July 23, 2018 7:38 PM
> To: Morten Brørup
> Cc: Olivier Matz; dev@dpdk.org
> Subject: Re: [dpdk-dev] rte_mbuf library likely()/unlikely()
>
> On Mon, 23 Jul 2018 15:53:42 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > Hi Olivier,
> >
> >
> >
> > I noticed that __rte_pktmbuf_read() could do with an unlikely(), so I
> went through the entire library. Here are my suggested modifications.
> >
> >
> >
> >
> >
> > diff -bu rte_mbuf.c.orig rte_mbuf.c
> >
> > --- rte_mbuf.c.orig 2018-07-23 15:13:22.000000000 +0200
> >
> > +++ rte_mbuf.c 2018-07-23 15:32:53.000000000 +0200
> >
> > @@ -173,19 +173,19 @@
> >
> > {
> >
> > unsigned int nb_segs, pkt_len;
> >
> >
> >
> > - if (m == NULL)
> >
> > + if (unlikely(m == NULL))
> >
> > rte_panic("mbuf is NULL\n");
> >
> >
>
> Adding is unlikely is not necessary since rte_panic is marked with cold
> attribute
> which has the same effect.
I was not aware of this. Although it is not visible from the source code files using rte_panic(), it probably means we shouldn't as so much as I thought. Here's an updated patch for rte_mbuf.c, where it is relevant. The other two suggested patches are unaffected.
diff -bu rte_mbuf.c.orig rte_mbuf.c
--- rte_mbuf.c.orig 2018-07-23 15:13:22.000000000 +0200
+++ rte_mbuf.c 2018-07-23 20:52:35.000000000 +0200
@@ -249,7 +249,7 @@
const struct rte_mbuf *seg = m;
uint32_t buf_off = 0, copy_len;
- if (off + len > rte_pktmbuf_pkt_len(m))
+ if (unlikely(off + len > rte_pktmbuf_pkt_len(m)))
return NULL;
while (off >= rte_pktmbuf_data_len(seg)) {
@@ -257,7 +257,7 @@
seg = seg->next;
}
- if (off + len <= rte_pktmbuf_data_len(seg))
+ if (likely(off + len <= rte_pktmbuf_data_len(seg)))
return rte_pktmbuf_mtod_offset(seg, char *, off);
/* rare case: header is split among several segments */
@@ -344,7 +344,7 @@
unsigned int i;
int ret;
- if (buflen == 0)
+ if (unlikely(buflen == 0))
return -1;
buf[0] = '\0';
@@ -355,9 +355,9 @@
if (name == NULL)
name = rx_flags[i].default_name;
ret = snprintf(buf, buflen, "%s ", name);
- if (ret < 0)
+ if (unlikely(ret < 0))
return -1;
- if ((size_t)ret >= buflen)
+ if (unlikely((size_t)ret >= buflen))
return -1;
buf += ret;
buflen -= ret;
@@ -440,7 +440,7 @@
unsigned int i;
int ret;
- if (buflen == 0)
+ if (unlikely(buflen == 0))
return -1;
buf[0] = '\0';
@@ -451,9 +451,9 @@
if (name == NULL)
name = tx_flags[i].default_name;
ret = snprintf(buf, buflen, "%s ", name);
- if (ret < 0)
+ if (unlikely(ret < 0))
return -1;
- if ((size_t)ret >= buflen)
+ if (unlikely((size_t)ret >= buflen))
return -1;
buf += ret;
buflen -= ret;
Med venlig hilsen / kind regards
- Morten Brørup
^ permalink raw reply
* [ANNOUNCEMENT] Yocto Project 2.3.4 (pyro 17.0.4) Released
From: Tracy Graydon @ 2018-07-23 18:59 UTC (permalink / raw)
To: yocto-announce, yocto
Hello,
The latest release of the Yocto Project 2.3.4 (pyro-17.0.4) is now available for download at:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.4/poky-pyro-17.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.4/poky-pyro-17.0.4.tar.bz2
A gpg signed version of these release notes is available at:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.4/RELEASENOTES
Full pass test report is available at:
https://wiki.yoctoproject.org/wiki/WW25_-_2018-06-22-_Full_Test_Cycle_-_2.3.4_rc1
Thank you to everyone for your contributions to this release!
Tracy Graydon
Yocto Project Build and Release
tracy.graydon@intel.com
-------------------
yocto-2.3.4 Errata
---------------------
Release Name: eclipse-poky-neon-pyro-17.0.4
Branch: neon/pyro
Tag: neon/pyro-17.0.4
Hash: a5dbc01b96be55c4ec2f774af9996a8086e402ab
md5: db1ce34974dd42b1b65ccfe844bf4f8c
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.4/eclipse-poky-neon-pyro-17.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.4/eclipse-poky-neon-pyro-17.0.4.tar.bz2
Release Name: eclipse-poky-oxygen-pyro-17.0.4
Branch: oxygen/pyro
Tag: oxygen/pyro-17.0.4
Hash: 020fc5814d2028654879356296b647002caf30b6
md5: 7753cfd309b8d9113a9106b5b5f380ff
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.4/eclipse-poky-oxygen-pyro-17.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.4/eclipse-poky-oxygen-pyro-17.0.4.tar.bz2
Release Name: meta-qt3-pyro-17.0.4
Branch: pyro
Tag: pyro-17.0.4
Hash: f33b73a9563f2dfdfd0ee37b61d65d90197a456f
md5: 1e00f9b5cdcfecddc9387632485afb9b
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.4/meta-qt3-pyro-17.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.4/meta-qt3-pyro-17.0.4.tar.bz2
Release Name: meta-qt4-pyro-17.0.4
Branch: pyro
Tag: pyro-17.0.4
Hash: 88989ae3abe98b30089e7518d3adabe990c40a10
md5: ae741cba79b1166b54b96757e90785cb
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.4/meta-qt4-pyro-17.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.4/meta-qt4-pyro-17.0.4.tar.bz2
Release Name: poky-pyro-17.0.4
Branch: pyro
Tag: pyro-17.0.4
Hash: ebb42af2829edfca1a23c7a51a431c656ffc2090
md5: cc8378a3f0dc763bbc6f154e64d9d602
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.3.4/poky-pyro-17.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.3.4/poky-pyro-17.0.4.tar.bz2
----------------
Known Issues
----------------
N/A
----------------
Security Fixes
----------------
libvorbis: CVE-2018-5146
libvorbis: CVE-2017-14632
libvorbis: CVE-2017-14633
libtirpc: Fix CVE-2017-8779
bluez5: fix out-of-bounds access in SDP server (CVE-2017-1000250)
----------------
Fixes
----------------
poky.ent: Updated release month variable to "June 2018"
documentation: Updated release date scheme to use variable.
documentation: Updated Manual Notes
build-appliance-image: Update to pyro head revision
poky: Update version to 2.3.4
ruby: Update to 2.4.4
ruby: fix typo in gmp PACKAGECONFIG option
ruby: remove spurious db build dependency
ruby: upgrade to 2.4.2
ruby: upgrade to 2.4.1
scripts/test-dependencies.sh: remove
sstate-diff-machines.sh: Replace MACHINE_ARCH only at the beginning and separated with dash
sstate-sysroot-cruft.sh: Extend the whitelist
libpng: update SRC_URI to use osl
mpfr: Update SRC_URI to use gnu
byacc: Fic SRC_URI to use yocto sources loc.
libpng: fix MIRRORS usage
neon: update SRC_URI
libpng: use SourceForge mirror
gdb: fix header ordering for TRAP_HWBKPT
glibc: add missing TRAP_BRANCH/TRAP_HWBKPT definitions
libmpc: fix SRC_URI
distcc: Change SRC_URI
e2fsprogs: fix compatibility with glibc 2.27
qemu: fix memfd_create with glibc 2.27
package_manager.py: Explicit complementary fail
sdk: streamline locale removal
cross-localedef-native: add way to specify which locale archive to write
package-manager: add install_glob()
package_manager: improve install_complementary
sdk: generate locale archive and remove packages
populate_sdk_base: depend on nativesdk-glibc-locale
populate_sdk: install UTF-8 locales in SDKs
sdk: only install locales if we're using glibc
sdk: install specified locales into SDK
glibc: relocate locale paths in nativesdk
glibc: don't use host locales in nativesdk
default-distrovars: don't rename locales for nativesdk
bitbake.conf: Add comm to HOSTTOOLS
world-broken.inc: blacklist portmap on musl
uninative: Add compatiblity version check
yocto-uninative: Upgrade to 1.8 version with glibc 2.27
unfs3: Fix libtirpc usage for unfs3-native version
unfs3: Fix build with musl
libtirpc: Extend to native and nativesdk recipes
libtirpc: stop dropping in NIS headers
libtirpc: upgrade to 1.0.2
libtirpc: Fix build error due to missing stdint.h> include
libtirpc: Enable des APIs for musl
libtirpc: Expose key_secretkey_is_set API
libtirpc: Backport fixes from 1.0.2rc3
gcc: Remove patch causing ICE on x86_64 valgrind compile
gcc6: Backport few more patches
gcc6: enable FL_LPAE flag for armv7ve cores
gcc7/gcc6: Fix unaligned STRD issue on ARM
gcc6: Upgrade to 6.4
gcc-6.3: Backport patch to fix ICE on ARM
gcc-runtime: Disable libitm on riscv
bitbake: providers: Fix determinism issue
openssh: Atomically generate host keys
linux-yocto-rt/4.1: update to include spectre fixes
linux-yocto/4.1: updated to include spectre fixes
linux-yocto-tiny/4.1: update with spectre fixes
linux-yocto-tiny/4.1: update to 4.1.49 plus meltdown
linux-yocto-rt/4.1: update to 4.1.49 plus meltdown
linux-yocto/4.1: update to 4.1.49 plus meltdown
bitbake.conf: add tools required by testimage to HOSTTOOLS conditionally
bitbake.conf: add ssh to HOSTTOOLS_NONFATAL
oeqa/runtime/buildcpio: Use our own mirror for source
qemurunner: Simplify binary data handling
oeqa: Clean up logger handling
oeqa/targetcontrol: Drop unused get_target_controller function
testimage: Pass the logger into OERuntimeTestContextExecutor.getTarget()
oeqa/qemurunner: Use logger.debug, not logger.info
qemurunner: Ensure logging handler is removed
sshcontrol.py: in copy_to() always use scp
qemurunner: fix bad indentation in serial login
qemurunner: print tail qemu log in case bootlog is empty
qemurunner.py: wait for PID to appear in procfs
qemurunner.py: refactor searching for QEMU PID
oeqa/qemurunner: Improve logging
qemurunner: Tweak qemu pid starting timeout code
ovmf-native: fix compile issue on new OS like FC27 and Ubuntu 17
openssl: Upgrade from 1.0.2k to 1.0.2n
p11-kit: take source code from official git
package_rpm.bbclass: Fix matching of architecture independent packages
image_types_wic.bbclass: Ensure '-c image_wic' works
kernel-yocto/4.9: update to v4.9.82
distutils-base.bbclass: Do not use -pie with hardening
python3-nose: rename ${bindir}/nosetests into ${bindir}/nosetests3
grub: Fix device mapper dependency
linux-firmware: Add reference to iwlwifi-8000C firmware
python3-setuptools: extend to nativesdk
tzdata: update to 2018c
tzcode: update to 2018c
tzdata: update 2017c
tzcode-native: update to 2017c
linux-yocto/4.9: update to v4.9.78
linux-yocto/4.4: update to v4.4.113
linux-yocto/4.4: update to 4.4.99
linux-yocto/4.9: fix aufs build
linux-yocto/4.9: update to v4.9.71
linux-yocto/4.x: configuration updates
linux-yocto/4.9: update to v4.9.65
linux-yocto/4.9: update to v4.9.61
linux-yocto/4.9: update to v4.9.57
linux-yocto/4.4: update to v4.4.93
linux-yocto-tiny: Enable qemux86-64 on linux-yocto-tiny 4.10
linux-yocto-tiny: Enable qemux86-64 on linux-yocto-tiny 4.9
linux-yocto-tiny: Enable qemux86-64 on linux-yocto-tiny 4.4
pax-utils: update SRC_URI
documentation: Updated manual revision table for 2.3.4 release date
dev-manual: Fixed variable link to DEFAULTTUNE variable
documentation: Updates to support a 2.3.4 point release
ref-manual, yocto-project-qs, poky.ent: Fixed CentOS package
ref-manual: Updated Note to use bullet forms
populate_sdk_ext: Set cleandirs correctly
lib/oe/package_manager/sdk: Ensure do_populate_sdk_ext and do_populate_sdk repos don't conflict
python3-native: Add python3-misc-native to RPROVIDES
insane: consider INSANE_SKIP without package-specifier too
linux-firmware: Bump to bf04291 revision
linux-firmware: Split out the QAT firmware
linux-firmware: make i.MX SDMA split complete
linux-firmware: Split i.MX SDMA firmwares
linux-firmware: package Broadcom BCM43362 firmware
linux-firmware: bump to latest linux-firmware git revision
linux-firmware: package Marvell PCIe WiFi firmwares
linux-firmware: package ibt-firmware
linux-firmware: package iwlfifi-3160-[10-17] firmware
linux-firmware: add support for mt7601u WiFi chip
linux-firmware: package Qualcomm QCA firmware
linux-firmware: enable netronome firmware
image: Expand PV to avoid AUTOREV parsing failures
bitbake: bitbake-user-manual: Fixed porno hack for hello world example
webkitgtk: update to 2.18.5 (includes Spectre mitigations; see commit description)
libunwind: Disable documentation explicitly
ovmf: Fix build with gcc7
portmaper: checkuri fails.
linux-firmware: Remove iwlwifi-8000C-19 SRC_URI
diffstat: use HTTP mirror for SRC_URI
liburi-perl: update SRC_URI to yoctoproject mirror
v86d: take tarball from debian
staging.bbclass: handle postinst-useradd-* fixmes
runqemu: Add workaround for APIC hang on pre 4.15 kernels on qemux86
cross.bbclass: Remove usage of host flags for cross-compilation
archiver: preserve sysroot paths in configured mode
archiver: avoid archiving source for glibc-locale
archiver.bbclass: adapt do_unpack_and_patch to RSS
archiver.bbclass: fix do_ar_original error for matchbox-desktop
archiver.bbclass: do not cause kernel rebuilds
archiver.bbclass: various fixes for original+diff mode
archiver.bbclass: enhance do_ar_recipe task signature
archiver: Escape recipe name in regex
classes: drop image dependencies on TOPDIR variable
image.bbclass: drop initramfs bundle related code
local.conf.sample: Weakly set BB_DISKMON_DIRS
documenation: Prepared docs for a 2.3.3 point release
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-3.0] tests/libqtest: Improve kill_qemu() assert
From: Eric Blake @ 2018-07-23 18:59 UTC (permalink / raw)
To: Peter Maydell, qemu-devel
Cc: Michael S . Tsirkin, Richard Henderson, Alex Bennée,
Philippe Mathieu-Daudé, patches
In-Reply-To: <20180723184752.22150-1-peter.maydell@linaro.org>
On 07/23/2018 01:47 PM, Peter Maydell wrote:
> In kill_qemu() we have an assert that checks that the QEMU process
> didn't dump core:
> assert(!WCOREDUMP(wstatus));
>
> Unfortunately the WCOREDUMP macro here means the resulting message
> is not very easy to comprehend on at least some systems:
>
> ahci-test: tests/libqtest.c:113: kill_qemu: Assertion `!(((__extension__ (((union { __typeof(wstatus) __in; int __i; }) { .__in = (wstatus) }).__i))) & 0x80)' failed.
>
> and it doesn't identify what signal the process took.
>
> Instead of using a raw assert, print the information in an
> easier to understand way:
>
> /i386/ahci/sanity: tests/libqtest.c:119: kill_qemu() tried to terminate QEMU process but it dumped core with signal 11 (Segmentation fault)
> Aborted (core dumped)
>
> (Of course, the really useful information would be why the QEMU
> process dumped core in the first place, but we don't have that
> by the time the test program has picked up the exit status.)
Last time we bike-shedded this, I suggested that we fix things to call
waitpid() in a loop, and that we just assert that exit status is 0:
https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg05610.html
In other words, why are we special-casing death-by-coredump, when ALL
non-zero exit status (whether or not a core dump was involved) is
contrary to the assumptions of the testsuite?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: [PATCH v3 2/3] perf arm64: Generate system call table from asm/unistd.h
From: Arnaldo Carvalho de Melo @ 2018-07-23 18:59 UTC (permalink / raw)
To: Kim Phillips
Cc: Arnaldo Carvalho de Melo, Ravi Bangoria, Alexander Shishkin,
Hendrik Brueckner, Jiri Olsa, Michael Ellerman, Namhyung Kim,
Thomas Richter, Peter Zijlstra, Ingo Molnar, linux-kernel
In-Reply-To: <20180720150653.GD4329@kernel.org>
Em Fri, Jul 20, 2018 at 12:06:53PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Jul 18, 2018 at 12:57:52PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Jul 06, 2018 at 04:34:43PM -0500, Kim Phillips escreveu:
> > > This should speed up accessing new system calls introduced with the
> > > kernel rather than waiting for libaudit updates to include them.
> > >
> > > Using the existing other arch scripts resulted in this error:
> > >
> > > tools/perf/arch/arm64/entry/syscalls//mksyscalltbl: 25: printf: __NR3264_ftruncate: expected numeric value
> > >
> > > because, unlike other arches, asm-generic's unistd.h does things like:
> > >
> > > #define __NR_ftruncate __NR3264_ftruncate
> > >
> > > Turning the scripts printf's %d into a %s resulted in this in the
> > > generated syscalls.c file:
> > >
> > > static const char *syscalltbl_arm64[] = {
> > > [__NR3264_ftruncate] = "ftruncate",
> > >
> > > So we use the host C compiler to fold the macros, and print them out
> > > from within a temporary C program, in order to get the correct output:
> > >
> > > static const char *syscalltbl_arm64[] = {
> > > [46] = "ftruncate",
> > >
> >
> > One of my containers, ubuntu:14.04.4-x-linaro-arm64, that build perf in
> > a cross-build env, failed to build, please take a look if what is in the
> > output below is enough for you to find the problem, perhaps you forgot
> > to add the new files grabbed from the kernel sources to the
> > tools/perf/MANIFEST file that is used to create the tarball that is then
> > used to test build it? I'll check that later, in a hurry right now.
>
So it fails with:
perfbuilder@7dbfe2fe9bef:/git/perf$ tools/perf/arch/arm64/entry/syscalls/mksyscalltbl /gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc gcc tools/arch/arm64/include/uapi/asm/unistd.h
static const char *syscalltbl_arm64[] = {
<stdin>: In function 'main':
<stdin>:257:38: error: '__NR_getrandom' undeclared (first use in this function)
<stdin>:257:38: note: each undeclared identifier is reported only once for each function it appears in
<stdin>:258:41: error: '__NR_memfd_create' undeclared (first use in this function)
<stdin>:259:32: error: '__NR_bpf' undeclared (first use in this function)
<stdin>:260:37: error: '__NR_execveat' undeclared (first use in this function)
tools/perf/arch/arm64/entry/syscalls/mksyscalltbl: 47: tools/perf/arch/arm64/entry/syscalls/mksyscalltbl: /tmp/create-table-60liya: Permission denied
Because it uses as input this file
tools/arch/arm64/include/uapi/asm/unistd.h, that basically just does:
perfbuilder@1015f8b85ded:/git/perf$ cat tools/arch/arm64/include/uapi/asm/unistd.h
#define __ARCH_WANT_RENAMEAT
#include <asm-generic/unistd.h>
perfbuilder@1015f8b85ded:/git/perf$
And this ends up getting the system's asm-generic/unistd.h file, not the one
shipped in tools/, so:
perfbuilder@1015f8b85ded:/git/perf$ grep bpf /usr/include/asm-generic/unistd.h
perfbuilder@1015f8b85ded:/git/perf$ grep _NR_ /usr/include/asm-generic/unistd.h | tail -4
#define __NR_mmap2 __NR3264_mmap
#define __NR_fadvise64_64 __NR3264_fadvise64
#define __NR_stat64 __NR3264_stat
#define __NR_lstat64 __NR3264_lstat
perfbuilder@1015f8b85ded:/git/perf$
A quick hack is to do this instead:
diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 85fdf4949db3..f013b115dc86 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -11,7 +11,7 @@ PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
out := $(OUTPUT)arch/arm64/include/generated/asm
header := $(out)/syscalls.c
-sysdef := $(srctree)/tools/arch/arm64/include/uapi/asm/unistd.h
+sysdef := $(srctree)/tools/include/uapi/asm-generic/unistd.h
sysprf := $(srctree)/tools/perf/arch/arm64/entry/syscalls/
systbl := $(sysprf)/mksyscalltbl
diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
index c21023509960..52e197317d3e 100755
--- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
+++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
@@ -28,6 +28,7 @@ create_table_from_c()
cat <<-_EoHEADER
#include <stdio.h>
+ #define __ARCH_WANT_RENAMEAT
#include "$input"
int main(int argc, char *argv[])
{
^ permalink raw reply related
* Re: [PATCH 02/11] ASoC: SOF: Add Sound Open Firmware KControl support
From: Mark Brown @ 2018-07-23 18:58 UTC (permalink / raw)
To: Liam Girdwood; +Cc: alsa-devel
In-Reply-To: <20180719185335.30912-2-liam.r.girdwood@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 161 bytes --]
On Thu, Jul 19, 2018 at 07:53:26PM +0100, Liam Girdwood wrote:
> + pm_runtime_get_sync(sdev->dev);
There's no error checking on any of the runtime PM calls...
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases (rev5)
From: Patchwork @ 2018-07-23 18:58 UTC (permalink / raw)
To: Radhakrishna Sripada; +Cc: igt-dev
In-Reply-To: <20180723182545.19461-1-radhakrishna.sripada@intel.com>
== Series Details ==
Series: tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases (rev5)
URL : https://patchwork.freedesktop.org/series/40553/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> IGTPW_1632 =
== Summary - SUCCESS ==
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/40553/revisions/5/mbox/
== Known issues ==
Here are the changes found in IGTPW_1632 that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@drv_module_reload@basic-reload:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106248, fdo#106725)
igt@gem_pwrite@basic:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719)
igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
fi-glk-j4005: PASS -> FAIL (fdo#106765)
igt@kms_flip@basic-flip-vs-modeset:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000, fdo#106097)
igt@kms_flip@basic-flip-vs-wf_vblank:
fi-glk-j4005: PASS -> FAIL (fdo#100368)
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103)
==== Possible fixes ====
igt@debugfs_test@read_all_entries:
fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: FAIL (fdo#104008) -> PASS
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103
fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248
fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725
fdo#106765 https://bugs.freedesktop.org/show_bug.cgi?id=106765
== Participating hosts (47 -> 43) ==
Additional (1): fi-bsw-kefka
Missing (5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u
== Build changes ==
* IGT: IGT_4570 -> IGTPW_1632
CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_1632: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1632/
IGT_4570: 65cdccdc7bcbb791d791aeeeecb784a382110a3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1632/issues.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH 3/5] coccinelle: exclude sha1dc source files from static analysis
From: Eric Sunshine @ 2018-07-23 18:57 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Junio C Hamano, Git List, René Scharfe, Derrick Stolee,
Nguyễn Thái Ngọc Duy
In-Reply-To: <CAM0VKjkJoqRFmXdnuujSaiZ=hvz6MeAmgoUQNAkZ+82ZrKtotw@mail.gmail.com>
On Mon, Jul 23, 2018 at 2:44 PM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> On Mon, Jul 23, 2018 at 8:28 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > On Mon, Jul 23, 2018 at 9:51 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> > > +ifdef DC_SHA1_SUBMODULE
> > > +COCCI_SOURCES = $(filter-out sha1collisiondetection/%,$(C_SOURCES))
> > > +else
> > > +COCCI_SOURCES = $(filter-out sha1dc/%,$(C_SOURCES))
> > > +endif
> >
> > Can't you just filter out both of these unconditionally without
> > worrying about DC_SHA1_SUBMODULE?
>
> I'm not sure what you mean by that. Like this perhaps?
>
> COCCI_SOURCES = $(filter-out sha1collisiondetection/%,$(filter-out
> sha1dc/%,$(C_SOURCES)))
>
> While it's only a single line, I don't think it's any easier on the
> eyes.
I wasn't worried about readability or one or two lines (indeed, you
could still do the filtering over two statements).
What I meant was that sha1dc/ contains files whether DC_SHA1_SUBMODULE
is defined or not. If the idea of this change is that there's no point
in having Coccinelle check those foreign, imported files (and waste
time in the process), then I was thinking that you'd want to omit
sha1dc/* regardless of whether DC_SHA1_SUBMODULE is defined.
Looking more closely at the Makefile, however, I see that C_SOURCES
holds only one or the other of sha1dc/* or
sha1collisiondetection/lib/*, so my concern is unfounded, which
explains why my question confused you.
^ permalink raw reply
* Re: [PATCH 1/1] i2c: rcar: handle RXDMA HW behaviour on Gen3
From: Wolfram Sang @ 2018-07-23 17:55 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, linux-renesas-soc, Yoshihiro Shimoda,
Geert Uytterhoeven
In-Reply-To: <20180628204538.866-2-wsa+renesas@sang-engineering.com>
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
On Thu, Jun 28, 2018 at 10:45:38PM +0200, Wolfram Sang wrote:
> On Gen3, we can only do RXDMA once per transfer reliably. For that, we
> must reset the device, then we can have RXDMA once. This patch
> implements this. When there is no reset controller or the reset fails,
> RXDMA will be blocked completely. Otherwise, it will be disabled after
> the first RXDMA transfer. Based on a commit from the BSP by Hiromitsu
> Yamasaki, yet completely refactored to handle multiple read messages
> within one transfer.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 01/11] ASoC: SOF: Add Sound Open Firmware driver core
From: Mark Brown @ 2018-07-23 18:56 UTC (permalink / raw)
To: Liam Girdwood; +Cc: alsa-devel
In-Reply-To: <20180719185335.30912-1-liam.r.girdwood@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 2389 bytes --]
On Thu, Jul 19, 2018 at 07:53:25PM +0100, Liam Girdwood wrote:
> The Sound Open Firmware driver core is a generic architecture
> independent layer that allows SOF to be used on many different different
> architectures and platforms. It abstracts DSP operations and IO methods
> +++ b/include/sound/soc.h
> @@ -1133,6 +1133,7 @@ struct snd_soc_pcm_runtime {
> /* runtime devices */
> struct snd_pcm *pcm;
> struct snd_compr *compr;
> + struct snd_sof_pcm *sof;
> struct snd_soc_dai *codec_dai;
> struct snd_soc_dai *cpu_dai;
Can we rename this somehow to be less specific to SoF or move it to be
somewhere other than the runtime structure? I can see why you've done
this but I can also see every DSP vendor turning up and trying to add
their own field in here.
> +/*
> + * This file is provided under a dual BSD/GPLv2 license. When using or
> + * redistributing this file, you may do so under either license.
> + *
> + * Copyright(c) 2017 Intel Corporation. All rights reserved.
2017?
> index 000000000000..29458909182a
> --- /dev/null
> +++ b/sound/soc/sof/core.c
> @@ -0,0 +1,373 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +/*
> + * This file is provided under a dual BSD/GPLv2 license. When using or
Please make the entire comment a C++ one, it makes it look more
intentional.
> +static inline unsigned int sof_get_pages(size_t size)
> +{
> + return (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> +}
This feels like there should be a generic MM function for it?
> +/*
> + * Generic buffer page table creation.
> + */
> +
> +int snd_sof_create_page_table(struct snd_sof_dev *sdev,
> + struct snd_dma_buffer *dmab,
> + unsigned char *page_table, size_t size)
> +{
> + int i, pages;
> +
> + pages = snd_sgbuf_aligned_pages(size);
> +
> + dev_dbg(sdev->dev, "generating page table for %p size 0x%zx pages %d\n",
> + dmab->area, size, pages);
> +
> + for (i = 0; i < pages; i++) {
> + u32 idx = (((i << 2) + i)) >> 1;
> + u32 pfn = snd_sgbuf_get_addr(dmab, i * PAGE_SIZE) >> PAGE_SHIFT;
> + u32 *pg_table;
> +
> + dev_dbg(sdev->dev, "pfn i %i idx %d pfn %x\n", i, idx, pfn);
> +
> + pg_table = (u32 *)(page_table + idx);
> +
> + if (i & 1)
> + *pg_table |= (pfn << 4);
> + else
> + *pg_table |= pfn;
> + }
I'm not 100% clear what this is intended to do - lots of magic numbers
and dependencies on the host memory configuration.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Makefile: add a DEVOPTS flag to get pedantic compilation
From: Junio C Hamano @ 2018-07-23 18:53 UTC (permalink / raw)
To: Beat Bolli; +Cc: git
In-Reply-To: <20180721203647.2619-1-dev+git@drbeat.li>
Beat Bolli <dev+git@drbeat.li> writes:
> In the interest of code hygiene, make it easier to compile Git with the
> flag -pedantic.
>
> Pure pedantic compilation with GCC 7.3 results in one warning per use of
> the translation macro `N_`:
>
> warning: array initialized from parenthesized string constant [-Wpedantic]
>
> Therefore also disable the parenthesising of i18n strings with
> -DUSE_PARENS_AROUND_GETTEXT_N=no.
>
> Signed-off-by: Beat Bolli <dev+git@drbeat.li>
> ---
>
> This is the convenience knob for all developers that led to the series
> bb/pedantic[1]. It does not depend on this series, though.
Yup, but "make DEVELOPER=Yes" build won't pass unless this patch is
queued after those clean-up ;-)
Remind me if I forget to tweak =no back to =0 before pushing the
result out.
Thanks.
> [1] https://public-inbox.org/git/20180708144342.11922-1-dev+git@drbeat.li/T/#u
>
> Makefile | 6 ++++++
> config.mak.dev | 5 +++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 0cb6590f24..2bfc051652 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -484,6 +484,12 @@ all::
> # The DEVELOPER mode enables -Wextra with a few exceptions. By
> # setting this flag the exceptions are removed, and all of
> # -Wextra is used.
> +#
> +# pedantic:
> +#
> +# Enable -pedantic compilation. This also disables
> +# USE_PARENS_AROUND_GETTEXT_N to produce only relevant warnings.
>
> GIT-VERSION-FILE: FORCE
> @$(SHELL_PATH) ./GIT-VERSION-GEN
> diff --git a/config.mak.dev b/config.mak.dev
> index 2d244ca470..e11dd94741 100644
> --- a/config.mak.dev
> +++ b/config.mak.dev
> @@ -1,6 +1,11 @@
> ifeq ($(filter no-error,$(DEVOPTS)),)
> CFLAGS += -Werror
> endif
> +ifneq ($(filter pedantic,$(DEVOPTS)),)
> +CFLAGS += -pedantic
> +# don't warn for each N_ use
> +CFLAGS += -DUSE_PARENS_AROUND_GETTEXT_N=no
> +endif
> CFLAGS += -Wdeclaration-after-statement
> CFLAGS += -Wno-format-zero-length
> CFLAGS += -Wold-style-definition
^ permalink raw reply
* Re: [RFC PATCH 3/5] pack-objects: add delta-islands support
From: Stefan Beller @ 2018-07-23 18:52 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano, Jeff King, Christian Couder
In-Reply-To: <20180722054836.28935-4-chriscool@tuxfamily.org>
On Sat, Jul 21, 2018 at 10:49 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> From: Jeff King <peff@peff.net>
>
> Implement support for delta islands in git pack-objects
> and document how delta islands work in
> "Documentation/git-pack-objects.txt".
>
> Signed-off-by: Jeff King <peff@peff.net>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> Documentation/git-pack-objects.txt | 88 +++++++++++++++++++
> builtin/pack-objects.c | 130 ++++++++++++++++++++---------
> 2 files changed, 177 insertions(+), 41 deletions(-)
>
> diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
> index d95b472d16..7b7a36056f 100644
> --- a/Documentation/git-pack-objects.txt
> +++ b/Documentation/git-pack-objects.txt
> @@ -289,6 +289,94 @@ Unexpected missing object will raise an error.
> --unpack-unreachable::
> Keep unreachable objects in loose form. This implies `--revs`.
>
> +--delta-islands::
> + Restrict delta matches based on "islands". See DELTA ISLANDS
> + below.
> +
> +
> +DELTA ISLANDS
> +-------------
> +
> +When possible, `pack-objects` tries to reuse existing on-disk deltas to
> +avoid having to search for new ones on the fly. This is an important
> +optimization for serving fetches, because it means the server can avoid
> +inflating most objects at all and just send the bytes directly from
> +disk. This optimization can't work when an object is stored as a delta
> +against a base which the receiver does not have (and which we are not
> +already sending). In that case the server "breaks" the delta and has to
> +find a new one, which has a high CPU cost. Therefore it's important for
> +performance that the set of objects in on-disk delta relationships match
> +what a client would fetch.
> +
> +In a normal repository, this tends to work automatically. The objects
> +are mostly reachable from the branches and tags, and that's what clients
> +fetch. Any deltas we find on the server are likely to be between objects
> +the client has or will have.
> +
> +But in some repository setups, you may have several related but separate
> +groups of ref tips, with clients tending to fetch those groups
> +independently. For example, imagine that you are hosting several "forks"
> +of a repository in a single shared object store, and letting clients
> +view them as separate repositories through `GIT_NAMESPACE` or separate
> +repos using the alternates mechanism. A naive repack may find that the
> +optimal delta for an object is against a base that is only found in
> +another fork. But when a client fetches, they will not have the base
> +object, and we'll have to find a new delta on the fly.
> +
> +A similar situation may exist if you have many refs outside of
> +`refs/heads/` and `refs/tags/` that point to related objects (e.g.,
> +`refs/pull` or `refs/changes` used by some hosting providers). By
> +default, clients fetch only heads and tags, and deltas against objects
> +found only in those other groups cannot be sent as-is.
> +
> +Delta islands solve this problem by allowing you to group your refs into
> +distinct "islands". Pack-objects computes which objects are reachable
> +from which islands, and refuses to make a delta from an object `A`
> +against a base which is not present in all of `A`'s islands. This
> +results in slightly larger packs (because we miss some delta
> +opportunities), but guarantees that a fetch of one island will not have
> +to recompute deltas on the fly due to crossing island boundaries.
> +
> +Islands are configured via the `pack.island` option, which can be
> +specified multiple times. Each value is a left-anchored regular
> +expressions matching refnames. For example:
> +
> +-------------------------------------------
> +[pack]
> +island = refs/heads/
> +island = refs/tags/
> +-------------------------------------------
> +
> +puts heads and tags into an island (whose name is the empty string; see
> +below for more on naming). Any refs which do not match those regular
> +expressions (e.g., `refs/pull/123`) is not in any island. Any object
> +which is reachable only from `refs/pull/` (but not heads or tags) is
> +therefore not a candidate to be used as a base for `refs/heads/`.
> +
> +Refs are grouped into islands based on their "names", and two regexes
> +that produce the same name are considered to be in the same island. The
> +names are computed from the regexes by concatenating any capture groups
> +from the regex (and if there are none, then the name is the empty
> +string, as in the above example). This allows you to create arbitrary
> +numbers of islands. For example, imagine you store the refs for each
> +fork in `refs/virtual/ID`, where `ID` is a numeric identifier. You might
> +then configure:
> +
> +-------------------------------------------
> +[pack]
> +island = refs/virtual/([0-9]+)/heads/
> +island = refs/virtual/([0-9]+)/tags/
> +island = refs/virtual/([0-9]+)/(pull)/
> +-------------------------------------------
> +
> +That puts the heads and tags for each fork in their own island (named
> +"1234" or similar), and the pull refs for each go into their own
> +"1234-pull".
> +
> +Note that we pick a single island for each regex to go into, using "last
> +one wins" ordering (which allows repo-specific config to take precedence
> +over user-wide config, and so forth).
I had to read all of this [background information] to understand the
concept and I think it is misnamed, as my gut instinct first told me
to have deltas only "within an island and no island hopping is allowed".
(This message reads a bit like a commit message, not as documentation
as it is long winded, too).
This feature makes sure that the "common foundation" base is packed
in a way that it is not borrowing construction pieces from any of
the different things atop the common foundation.
It really is about packing the base, but naming it related to the
islands, that are on top of the common sea bed led me to think
that the islands are important of this feature, but really it is about
making the sea bed easy to use and not tied to one of the islands?
What about renaming this feature to
[pack]
excludePartialReach = refs/virtual/[0-9]]+/tags/
"By setting `pack.excludePartialReach`, object deltafication is
prohibited for objects that are not reachable from all
manifestations of the given regex"
Cryptic, but it explains it in my mind in a shorter, more concise way. ;-)
> @@ -3182,6 +3225,8 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> option_parse_missing_action },
> OPT_BOOL(0, "exclude-promisor-objects", &exclude_promisor_objects,
> N_("do not pack objects in promisor packfiles")),
> + OPT_BOOL(0, "delta-islands", &use_delta_islands,
> + N_("enable islands for delta compression")),
We enable this feature, but we disallow certain patterns to be used in packing,
so it sounds weird to me as we tell Git to *not* explore the full design space,
so we're not enabling it, but rather restricting it?
^ permalink raw reply
* Re: [PATCH] Makefile: add a DEVOPTS flag to get pedantic compilation
From: Junio C Hamano @ 2018-07-23 18:51 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Beat Bolli, git
In-Reply-To: <87wotobclv.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> +CFLAGS += -pedantic
>> +# don't warn for each N_ use
>> +CFLAGS += -DUSE_PARENS_AROUND_GETTEXT_N=0
>> +endif
>
> ...and set this to "no" not "0" since we document that that's the way to
> toggle it off in the Makefile, i.e. let's be consistent.
The Make variable USE_PARENS_AROUND_GETTEXT_N is described as taking
"yes" or "no".
# Define USE_PARENS_AROUND_GETTEXT_N to "yes" if your compiler happily
# compiles the following initialization:
#
# static const char s[] = ("FOO");
#
# and define it to "no" if you need to remove the parentheses () around the
# constant. The default is "auto", which means to use parentheses if your
# compiler is detected to support it.
But the knob on the CFLAGS set by these variables take 1 or 0
ifeq (yes,$(USE_PARENS_AROUND_GETTEXT_N))
BASIC_CFLAGS += -DUSE_PARENS_AROUND_GETTEXT_N=1
else
ifeq (no,$(USE_PARENS_AROUND_GETTEXT_N))
BASIC_CFLAGS += -DUSE_PARENS_AROUND_GETTEXT_N=0
endif
endif
And the code that uses the CFLAGS knob
/* Mark msgid for translation but do not translate it. */
#if !USE_PARENS_AROUND_GETTEXT_N
#define N_(msgid) msgid
#else
...
#define N_(msgid) (msgid)
#endif
pays attention to the truth/false in usual C preprocessor sense.
Your "no" happens to serve as 0 just like "yes" would.
So I think you suggestion is a bad one that makes a misleading
result.
[Footnote]
*1* The following shows all "not X" except for "not one".
#include <stdio.h>
#define ZERO 0
#define ONE 1
#define YES yes
#define NO no
#undef UNDEF
const char *msgs[] = {
#if !ZERO
"not zero",
#endif
#if !ONE
"not one",
#endif
#if !YES
"not yes",
#endif
#if !NO
"not no",
#endif
#if !UNDEF
"not undef",
#endif
NULL
};
int main(int ac, char **av)
{
const char **cp = msgs;
while (*cp) {
printf("%s\n", *cp);
cp++;
}
return 0;
}
^ permalink raw reply
* Re: bitbake is corrupting my files during unpacking
From: Burton, Ross @ 2018-07-23 18:51 UTC (permalink / raw)
To: Andre McCurdy; +Cc: Yocto discussion list
In-Reply-To: <CAJ86T=WtLMKA3M5-fWR1pm-x8PRRGwFihuwpuhbzEtQaGwFRTA@mail.gmail.com>
Yes, please do. Mohammad, as you can replicate this on demand, would
you be able to fix the unzip recipe with the patch in that bug and
send a patch?
Ross
On 23 July 2018 at 19:42, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Sat, Jul 21, 2018 at 12:55 AM, MOHAMMAD RASIM
> <mohammad.rasim96@gmail.com> wrote:
>> well apparently this is caused by the unzip binary that is compiled by the
>> openembedded unzip recipe.
>> If I unzip the same zip file with the unzip binary that is shipped with my
>> system(manjaro) then the files are not corrupted but when I use the unzip
>> binary compiled by the openembedded recipe I get error and file corruptions.
>> These are some of the errors I get when unzipping with the openembedded
>> unzip:
>> ...
>> symlink error: File name too long
>>
>> This error happens to multiple files where the file is symlinked to the
>> content of the file and not to a path !
>> Where should I report this bug ? openembedded ? unzip upstream ?
>
> If you google the "symlink error" you should find multiple hits, which
> all indicate a known bug in upstream unzip 6.0.
>
> So, it should be reported upstream. However, given that the last unzip
> release is now over 9 years old and there doesn't appear to be a
> public upstream development branch, the chances of getting a timely
> response don't look too good.
>
> We should probably add the fix to the unzip recipe in oe-core:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=972427
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply
* [Qemu-devel] [Bug 1769189] Re: Issue with qemu 2.12.0 + SATA
From: John Snow @ 2018-07-23 18:39 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <152544791493.32626.6219738999075353422.malonedeb@gac.canonical.com>
The fix posted exclusively changes the behavior of AHCI devices; however
the locking changes that jostled the AHCI bug loose could in theory
jostle loose some bugs in other devices, too.
I don't think it is possible that the fix for AHCI would have any impact
on virtio-scsi devices.
If you're seeing issues in virtio-scsi, I'd make a new writeup in a new LP.
--js
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769189
Title:
Issue with qemu 2.12.0 + SATA
Status in QEMU:
Fix Committed
Bug description:
[EDIT: I first thought that OVMF was the issue, but it turns out to be
SATA]
I had a Windows 10 VM running perfectly fine with a SATA drive, since
I upgraded to qemu 2.12, the guests hangs for a couple of minutes,
works for a few seconds, and hangs again, etc. By "hang" I mean it
doesn't freeze, but it looks like it's waiting on IO or something, I
can move the mouse but everything needing disk access is unresponsive.
What doesn't work: qemu 2.12 with SATA
What works: using VirIO-SCSI with qemu 2.12 or downgrading qemu to 2.11.1 and keep using SATA.
Platform is arch linux 4.16.7 on skylake and Haswell, I have attached
the vm xml file.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1769189/+subscriptions
^ permalink raw reply
* Re: [PATCH v2] pack-objects: fix performance issues on packing large deltas
From: Duy Nguyen @ 2018-07-23 18:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Elijah Newren, Jeff King
In-Reply-To: <CACsJy8BskYdANe9HnuLj8sqa8hRqzSAQ+q11C8faJ-YBtA3Xeg@mail.gmail.com>
On Mon, Jul 23, 2018 at 8:38 PM Duy Nguyen <pclouds@gmail.com> wrote:
> I will have to study the thread dispatch code more to have a better
> answer, unfortunately.
Well.. I thought I would need this weekend for this, but a quick look
and ll_find_deltas() suggests that what we're doing is safe. At least
you and Jeff are way to familiar with the delta window concept in
pack-objects. So in multithread mode, we have a big list of all
objects, then the list is cut in N sublists and each is owned entirely
by one thread. Each thread then can slide a window over this sublist
to search for the best delta.
Because of this partitioning, if trg_entry is being processed now, it
will not be accessed by any other thread. It's owned by this thread
and will be accessed again as src_entry when the next entry becomes
the delta target in the same thread. As long as we don't access
objects of another thread (and my v1 violates this) we should be ok.
At the end of ll_find_deltas() though, we have the "stealing" stuff,
but it's protected by progress_lock() already, outside try_delta() so
we're sure nobody is updating any object_entry when the stealing
happens.
I will double check again this weekend just to be sure.
--
Duy
^ permalink raw reply
* Re: Reg. rpm changelog
From: Burton, Ross @ 2018-07-23 18:49 UTC (permalink / raw)
To: Vikram Chhibber; +Cc: Yocto-mailing-list
In-Reply-To: <CALBAsRwS7cEcx1mp3GGx4vWeLzjW7i0MNcN-aO0o+Mog3xbdYQ@mail.gmail.com>
On 23 July 2018 at 18:30, Vikram Chhibber <vikram.chhibber@gmail.com> wrote:
> Thanks Mark. Is it possible to somehow use already created changelog while
> building rpm?
You mean that you'll maintain an independent changelog but want it to
be in the RPM?
Ross
^ 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.