* 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
* [linux-3.18 test] 125505: regressions - FAIL
From: osstest service owner @ 2018-07-23 18:49 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 125505 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125138
test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail REGR. vs. 125138
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125138
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125138
test-amd64-amd64-xl-xsm 10 debian-install fail REGR. vs. 125138
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 7 xen-boot fail REGR. vs. 125138
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-check(1) blocked n/a
test-arm64-arm64-examine 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 125138
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail like 125138
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 125138
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 125138
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 125138
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125138
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125138
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
build-arm64-pvops 6 kernel-build fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
version targeted for testing:
linux 7612025fbc7a5ab54bf71f48b99b0b6a15fc7b06
baseline version:
linux ac35b66883e8330ffde609152e13c225b12de6a4
Last test of basis 125138 2018-07-12 16:49:01 Z 11 days
Testing same since 125505 2018-07-22 12:11:31 Z 1 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Alex Vesker <valex@mellanox.com>
Amit Pundir <amit.pundir@linaro.org>
Andreas Schwab <schwab@linux-m68k.org>
Christian Lamparter <chunkeey@googlemail.com>
Dan Carpenter <dan.carpenter@oracle.com>
David S. Miller <davem@davemloft.net>
Eric Biggers <ebiggers@google.com>
Eric Dumazet <edumazet@google.com>
Florian Westphal <fw@strlen.de>
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Herbert Xu <herbert@gondor.apana.org.au>
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Jann Horn <jannh@google.com>
Jason Gunthorpe <jgg@mellanox.com>
Jason Wang <jasowang@redhat.com>
Jens Axboe <axboe@kernel.dk>
Johan Hovold <johan@kernel.org>
Jonas Gorski <jonas.gorski@gmail.com>
Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Leon Romanovsky <leonro@mellanox.com>
Linus Torvalds <torvalds@linux-foundation.org>
Neal Cardwell <ncardwell@google.com>
Nico Sneck <snecknico@gmail.com>
Pablo Neira Ayuso <pablo@netfilter.org>
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Saeed Mahameed <saeedm@mellanox.com>
Santosh Shilimkar <santosh.shilimkar@oracle.com>
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Theodore Ts'o <tytso@mit.edu>
Yuchung Cheng <ycheng@google.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops fail
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl blocked
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm blocked
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm fail
test-arm64-arm64-xl-xsm blocked
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 blocked
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-amd64-examine pass
test-arm64-arm64-examine blocked
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-xl-qemut-win10-i386 fail
test-amd64-i386-xl-qemut-win10-i386 fail
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 733 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [Intel-wired-lan] [jkirsher-next-queue:dev-queue] BUILD SUCCESS 4518264e4c304d1e5a8c0dd081fe723430aaaa65
From: kbuild test robot @ 2018-07-23 18:49 UTC (permalink / raw)
To: intel-wired-lan
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
branch HEAD: 4518264e4c304d1e5a8c0dd081fe723430aaaa65 ixgb: use dma_zalloc_coherent instead of allocator/memset
elapsed time: 83m
configs tested: 140
The following configs have been built successfully.
More configs may be tested in the coming days.
alpha defconfig
parisc allnoconfig
parisc b180_defconfig
parisc c3000_defconfig
parisc defconfig
x86_64 allmodconfig
powerpc mpc8560_ads_defconfig
x86_64 randconfig-a0-07232124
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 nfsroot
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
i386 randconfig-c0-07231120
powerpc mpc5200_defconfig
sh magicpanelr2_defconfig
i386 randconfig-n0-201829
x86_64 randconfig-x007-201829
x86_64 randconfig-x003-201829
x86_64 randconfig-x000-201829
x86_64 randconfig-x005-201829
x86_64 randconfig-x004-201829
x86_64 randconfig-x008-201829
x86_64 randconfig-x001-201829
x86_64 randconfig-x009-201829
x86_64 randconfig-x002-201829
x86_64 randconfig-x006-201829
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 default_defconfig
i386 randconfig-i0-201829
i386 randconfig-i1-201829
i386 defconfig
arm vf610m4_defconfig
x86_64 randconfig-v0-07232238
c6x evmc6678_defconfig
h8300 h8300h-sim_defconfig
nios2 10m50_defconfig
xtensa common_defconfig
xtensa iss_defconfig
i386 allmodconfig
x86_64 randconfig-x018-201829
x86_64 randconfig-x011-201829
x86_64 randconfig-x015-201829
x86_64 randconfig-x019-201829
x86_64 randconfig-x014-201829
x86_64 randconfig-x010-201829
x86_64 randconfig-x013-201829
x86_64 randconfig-x016-201829
x86_64 randconfig-x017-201829
x86_64 randconfig-x012-201829
i386 randconfig-a0-201829
i386 randconfig-a1-201829
x86_64 randconfig-s0-07231842
x86_64 randconfig-s1-07231842
x86_64 randconfig-s2-07231842
arm pxa3xx_defconfig
ia64 gensparse_defconfig
mips db1xxx_defconfig
sh secureedge5410_defconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
i386 randconfig-s0-201829
i386 randconfig-s1-201829
x86_64 randconfig-s3-07232252
x86_64 randconfig-s4-07232252
x86_64 randconfig-s5-07232252
x86_64 randconfig-i0-201829
sparc defconfig
sparc64 allnoconfig
sparc64 defconfig
powerpc pcm030_defconfig
powerpc tqm8548_defconfig
sh hp6xx_defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc ppc6xx_defconfig
powerpc64 allmodconfig
x86_64 randconfig-u0-07240101
s390 performance_defconfig
sh allyesconfig
x86_64 randconfig-ne0-07232115
i386 randconfig-x012-201829
i386 randconfig-x017-201829
i386 randconfig-x014-201829
i386 randconfig-x016-201829
i386 randconfig-x013-201829
i386 randconfig-x011-201829
i386 randconfig-x018-201829
i386 randconfig-x010-201829
i386 randconfig-x015-201829
i386 randconfig-x019-201829
i386 randconfig-sb0-07231305
x86_64 randconfig-ws0-07230849
i386 randconfig-x078-201829
i386 randconfig-x070-201829
i386 randconfig-x075-201829
i386 randconfig-x076-201829
i386 randconfig-x074-201829
i386 randconfig-x079-201829
i386 randconfig-x071-201829
i386 randconfig-x073-201829
i386 randconfig-x072-201829
i386 randconfig-x077-201829
ia64 alldefconfig
ia64 allnoconfig
ia64 defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 rhel
x86_64 rhel-7.2
openrisc or1ksim_defconfig
um i386_defconfig
um x86_64_defconfig
arm shannon_defconfig
mips ip28_defconfig
x86_64 randconfig-r0-07231315
i386 randconfig-x008-201829
i386 randconfig-x009-201829
i386 randconfig-x005-201829
i386 randconfig-x000-201829
i386 randconfig-x003-201829
i386 randconfig-x001-201829
i386 randconfig-x004-201829
i386 randconfig-x006-201829
i386 randconfig-x007-201829
i386 randconfig-x002-201829
i386 alldefconfig
i386 allnoconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [Qemu-devel] [PATCH for-3.0] tests/libqtest: Improve kill_qemu() assert
From: Peter Maydell @ 2018-07-23 18:47 UTC (permalink / raw)
To: qemu-devel
Cc: patches, Richard Henderson, Philippe Mathieu-Daudé,
Alex Bennée, Michael S . Tsirkin
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.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
changes v1->v2: addressed some of the bikeshedding with:
* print file-and-line in the fprintf message, and then
just abort(), rather than assert(0)
* print the signal name via strsignal() as well
tests/libqtest.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/libqtest.c b/tests/libqtest.c
index 098af6aec44..bfc86a15f4b 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -110,7 +110,16 @@ static void kill_qemu(QTestState *s)
pid = waitpid(s->qemu_pid, &wstatus, 0);
if (pid == s->qemu_pid && WIFSIGNALED(wstatus)) {
- assert(!WCOREDUMP(wstatus));
+ if (WCOREDUMP(wstatus)) {
+ int sig = WTERMSIG(wstatus);
+ const char *signame = strsignal(sig) ?: "unknown ???";
+
+ fprintf(stderr,
+ "%s:%d: kill_qemu() tried to terminate QEMU "
+ "process but it dumped core with signal %d (%s)\n",
+ __FILE__, __LINE__, sig, signame);
+ abort();
+ }
}
}
}
--
2.17.1
^ permalink raw reply related
* [PATCH v2] rfkill: fix spelling mistake contidion to condition
From: Richard Guy Briggs @ 2018-07-23 18:47 UTC (permalink / raw)
To: netdev; +Cc: Linux-Audit Mailing List, Richard Guy Briggs
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>
---
net/rfkill/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index a7a4e6f..3aab053 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -508,8 +508,8 @@ void rfkill_remove_epo_lock(void)
/**
* rfkill_is_epo_lock_active - returns true EPO is active
*
- * Returns 0 (false) if there is NOT an active EPO contidion,
- * and 1 (true) if there is an active EPO contition, which
+ * Returns 0 (false) if there is NOT an active EPO condition,
+ * and 1 (true) if there is an active EPO condition, which
* locks all radios in one of the BLOCKED states.
*
* Can be called in atomic context.
--
1.8.3.1
^ permalink raw reply related
* Re: Regression with crc32c selection?
From: Holger Hoffstätte @ 2018-07-23 17:45 UTC (permalink / raw)
To: dsterba, linux-btrfs
In-Reply-To: <20180723165040.GP26141@twin.jikos.cz>
On 07/23/18 18:50, David Sterba wrote:
> On Mon, Jul 23, 2018 at 04:13:26PM +0200, Holger Hoffstätte wrote:
>> While backporting a bunch of fixes to my own 4.16.x tree
>> (4.17 had a few too many bugs for my taste) I also ended up merging:
>
> Curious, bugs in btrfs or the whole 4.17 kernel? And if bugs, real
> breakage or backported fixes?
Overall. I don't remember specifics but skimming lkml at the time
didn't inspire a lot of confidence, and since I already had a large
number of hand-picked & backported patches from 4.17/4.18/4.19 :) for
btrfs, xfs, net, blk-mq & drivers - just the stuff I care about - I skipped
it instead of upgrading & rebasing everything. Might well be that the latest
4.17-stable works reliably, but 4.18 is already around the corner, so..
no really good reason. :)
cheers
Holger
^ permalink raw reply
* Re: [SPDK] Howto build with an external env, i.e. alternate CONFIG_ENV
From: Lance Hartmann ORACLE @ 2018-07-23 18:46 UTC (permalink / raw)
To: spdk
[-- Attachment #1: Type: text/plain, Size: 4633 bytes --]
> On Jul 20, 2018, at 5:17 PM, Walker, Benjamin <benjamin.walker(a)intel.com> wrote:
>
> Hi Lance,
>
> On Fri, 2018-07-20 at 16:34 -0500, Lance Hartmann ORACLE wrote:
>> Another especially notable take-away for me was the realization that the
>> environment library -- I'll refer to the default env for example here,
>> libspdk_env_dpdk.a -- consists only of the objects compiled from
>> SPDK_ROOT_DIR/lib/env_dpdk. With the ability to specify an alternate
>> environment, semantically, I had mistakenly assumed that the env library would
>> contain not only the SPDK implementation of the environment API, but also
>> everything on which it depended; i.e. for the default environment, the DPDK
>> objects. But, that doesn't appear to be so. Instead, when performing final
>> linking of each SPDK executable, not only is the SPDK environment library
>> specified, but so are the necessary DPDK libs on which it depends. Variables
>> pulled in from the SPDK's environment makefile, env.mk, are used to specify
>> those DPDK libs along with additional, special linking flags.
>>
>> We need to update the doc's Porting Guide to reflect these details, and I'd be
>> happy to volunteer to work on that effort.
>
> Please do!
>
>> However, before embarking on that task, I'd like to pose the question: are
>> there reasons why we couldn't or shouldn't produce the environment library to
>> consist of both the SPDK env implementation layer and the objects on which it
>> depends? It would seem that would make final linking of executables a little
>> easier and reduce the complexity/effort of someone wanting to develop and use
>> an alternate environment.
>
> How do you envision this playing with environment libraries that need to link
> against shared libraries, especially ones provided with the system itself? I'm
> not an expert in all of the available linker options, so maybe there is some way
> to embed enough information to properly link/load a shared library directly into
> the static library.
>
This is an area in which I would greatly appreciate additional discussion, weighing the engineering cost/benefits of such flexibility. I, myself, could for example embrace the idea that for the sake of simplifying final linking that we propose the SPDK env implementation is built as a shared library which could be generated with a dependency on the DPDK (or its replaced equivalent) which also be shared lib(s). Alternatively, I could also potentially be persuaded that we take an all static approach, though I hasten to add I can appreciate there may be stakeholders who strongly advocate/need shared libs. I am aware of precedents where a package provided both static and shared versions of their libraries, and sometimes even in separate packages; i.e. a "static" package. So, for greater flexibility, I could also envision a new SPDK configure option enabling the developer to specify static vs. dynamic, and perhaps with the options for the needed linking flags. On the latter, I'm aware per configure that it appears the build of the SPDK can/will honor shell environment variables for CFLAGS, CXXFLAGS, LDFLAGS and DESTDIR, but I don't know how challenging the use of those could be to override (or concatenate) those already figured out in the *mk/Makefile files.
Out of curiosity, I retrieved the available DPDK packages from Ubuntu, and there are quite a few of them, including those with a static and dynamic dpdk library. I haven't dug through all of the SPDK build options, but my initial pass would suggest it's currently built with only static env (and static DPDK) libs, at least for the default configuration.
Taking all of this a step further is the expectation that in the future we will provide two very different ways to build with the SPDK. Today, we're checking out the SPDK repo and relying on the collection of makefiles therein to build the SPDK. But, moving forward, we hope to produce an spdk-devel package(s) so that SPDK app developers could build against it/them. Such a build environment there is outside our purview save for our need to provide the proper contents of those devel package(s).
In summary, I'm seeking, if possible, to simplify the build with respect to the env while keeping in mind the future with -devel package(s). I'm very much hoping to get more input from others in the SPDK community on this topic, and am happy to volunteer on the implementation and documentation thereof once we can form a broader consensus.
thanks much,
--
Lance Hartmann
lance.hartmann(a)oracle.com
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7435 bytes --]
^ permalink raw reply
* [PATCH] drm/msm: Replace PTR_RET with PTR_ERR_OR_ZERO
From: Gustavo A. R. Silva @ 2018-07-23 18:46 UTC (permalink / raw)
To: Rob Clark, David Airlie
Cc: linux-arm-msm, dri-devel, freedreno, linux-kernel,
Gustavo A. R. Silva
PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
index 8d907fa..25ddbb8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
@@ -35,7 +35,7 @@ int msm_dss_get_clk(struct device *dev, struct dss_clk *clk_arry, int num_clk)
for (i = 0; i < num_clk; i++) {
clk_arry[i].clk = clk_get(dev, clk_arry[i].clk_name);
- rc = PTR_RET(clk_arry[i].clk);
+ rc = PTR_ERR_OR_ZERO(clk_arry[i].clk);
if (rc) {
DEV_ERR("%pS->%s: '%s' get failed. rc=%d\n",
__builtin_return_address(0), __func__,
--
2.7.4
^ permalink raw reply related
* [rocko/master][PATCH] tidl-utils: SRCREV bump
From: Djordje Senicic @ 2018-07-23 18:46 UTC (permalink / raw)
To: meta-arago; +Cc: d-senicic1, Djordje Senicic
* SRC rev increase to include fixed paths of configuration files
Signed-off-by: Djordje Senicic <x0157990@ti.com>
---
| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--git a/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb b/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
index 264b030..e4fb600 100644
--- a/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
+++ b/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://docs/LICENSE.txt;md5=a93aa5af7a3bbbb6fb34c8df59efaa5c
RDEPENDS_${PN} += " tidl-api tidl-examples "
SRC_URI = "git://git.ti.com/tidl/tidl-utils.git;protocol=git;branch=master"
-SRCREV = "93f66d2c53960b13b7e7f20208ee205f727aaf28"
+SRCREV = "994d90ae583610673d9d39086ca5e84027a9c56e"
PR = "${INC_PR}.0"
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/5] coccinelle: exclude sha1dc source files from static analysis
From: SZEDER Gábor @ 2018-07-23 18:43 UTC (permalink / raw)
To: Eric Sunshine
Cc: Junio C Hamano, Git mailing list, René Scharfe,
Derrick Stolee, Nguyễn Thái Ngọc Duy
In-Reply-To: <CAPig+cSOZd+t17j7FSCYAydS34ZtfcRFZyE6E9fz=u7xB-01Mg@mail.gmail.com>
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:
> > sha1dc is an external library, that we carry in-tree for convenience
> > or grab as a submodule, so there is no use in applying our semantic
> > patches to its source files.
> >
> > Therefore, exclude sha1dc's source files from Coccinelle's static
> > analysis.
> >
> > Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
> > ---
> > diff --git a/Makefile b/Makefile
> > @@ -2666,10 +2666,16 @@ check: command-list.h
> > +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.
^ permalink raw reply
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Alex Ghiti @ 2018-07-23 17:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux, catalin.marinas, will.deacon, tony.luck, fenghua.yu, ralf,
paul.burton, jhogan, jejb, deller, benh, paulus, ysato, dalias,
davem, tglx, mingo, hpa, x86, arnd, linux-arm-kernel,
linux-kernel, linux-ia64, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, linux-arch, Naoya Horiguchi, Mike Kravetz,
Michal Hocko
In-Reply-To: <87d0vehx16.fsf@concordia.ellerman.id.au>
Ok will do and report when done.
Thanks for your feedback,
Alex
On 07/23/2018 02:00 PM, Michael Ellerman wrote:
> Alex Ghiti <alex@ghiti.fr> writes:
>
>> Does anyone have any suggestion about those patches ?
> Cross compiling it for some non-x86 arches would be a good start :)
>
> There are cross compilers available here:
>
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
>
>
> cheers
>
>> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>>> [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-alex@ghiti.fr]
>>>
>>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>>> In order to reduce copy/paste of functions across architectures and then
>>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>>> patchset intends to factorize the numerous hugetlb primitives that are
>>>> defined across all the architectures.
>>>>
>>>> Except for prepare_hugepage_range, this patchset moves the versions that
>>>> are just pass-through to standard pte primitives into
>>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>>
>>>> s390 architecture has not been tackled in this serie since it does not
>>>> use asm-generic/hugetlb.h at all.
>>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>>
>>>> This patchset has been compiled on x86 only.
>>>>
>>>> Changelog:
>>>>
>>>> v4:
>>>> Fix powerpc build error due to misplacing of #include
>>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>>> pointed by Christophe Leroy.
>>>>
>>>> v1, v2, v3:
>>>> Same version, just problems with email provider and misuse of
>>>> --batch-size option of git send-email
>>>>
>>>> Alexandre Ghiti (11):
>>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>>> hugetlb: Introduce generic version of set_huge_pte_at
>>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>>> hugetlb: Introduce generic version of huge_pte_none
>>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>>> hugetlb: Introduce generic version of huge_ptep_get
>>>>
>>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>>> arch/x86/include/asm/hugetlb.h | 72 +----------------------
>>>> include/asm-generic/hugetlb.h | 88 +++++++++++++++++++++++++++-
>>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>>
>>>> --
>>>> 2.16.2
^ permalink raw reply
* [PATCH] net/9p/trans_fd.c: fix race by holding the lock
From: Tomas Bortoli @ 2018-07-23 18:42 UTC (permalink / raw)
To: ericvh, rminnich, lucho
Cc: asmadeus, davem, v9fs-developer, netdev, linux-kernel, syzkaller,
Tomas Bortoli
It may be possible to run p9_fd_cancel() with a deleted req->req_list
and incur in a double del. To fix hold the client->lock while changing
the status, so the other threads will be synchronized.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
---
net/9p/trans_fd.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 588bf88c3305..f9f96d50d96d 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -197,15 +197,14 @@ static void p9_mux_poll_stop(struct p9_conn *m)
static void p9_conn_cancel(struct p9_conn *m, int err)
{
struct p9_req_t *req, *rtmp;
- unsigned long flags;
LIST_HEAD(cancel_list);
p9_debug(P9_DEBUG_ERROR, "mux %p err %d\n", m, err);
- spin_lock_irqsave(&m->client->lock, flags);
+ spin_lock(&m->client->lock);
if (m->err) {
- spin_unlock_irqrestore(&m->client->lock, flags);
+ spin_unlock(&m->client->lock);
return;
}
@@ -217,7 +216,6 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
list_for_each_entry_safe(req, rtmp, &m->unsent_req_list, req_list) {
list_move(&req->req_list, &cancel_list);
}
- spin_unlock_irqrestore(&m->client->lock, flags);
list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
@@ -226,6 +224,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
req->t_err = err;
p9_client_cb(m->client, req, REQ_STATUS_ERROR);
}
+ spin_unlock(&m->client->lock);
}
static __poll_t
@@ -373,8 +372,9 @@ static void p9_read_work(struct work_struct *work)
if (m->req->status != REQ_STATUS_ERROR)
status = REQ_STATUS_RCVD;
list_del(&m->req->req_list);
- spin_unlock(&m->client->lock);
+ /* update req->status while holding client->lock */
p9_client_cb(m->client, m->req, status);
+ spin_unlock(&m->client->lock);
m->rc.sdata = NULL;
m->rc.offset = 0;
m->rc.capacity = 0;
--
2.11.0
^ permalink raw reply related
* Re: bitbake is corrupting my files during unpacking
From: Andre McCurdy @ 2018-07-23 18:42 UTC (permalink / raw)
To: MOHAMMAD RASIM; +Cc: Yocto discussion list
In-Reply-To: <2d030ea4-b2df-58fe-9947-e1c4e40ea17b@gmail.com>
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
^ permalink raw reply
* [U-Boot] [PATCH 3/4] gpio: xilinx: Not read output values via regs
From: Stefan Herbrechtsmeier @ 2018-07-23 18:42 UTC (permalink / raw)
To: u-boot
In-Reply-To: <c0bbc06f6f2033844a73a78bc994c14fa965048c.1532346215.git.michal.simek@xilinx.com>
Hi Michal,
Am 23.07.2018 um 13:43 schrieb Michal Simek:
> Reading registers for finding out output value is not working because
> input value is read instead in case of tristate.
>
> Reported-by: Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> drivers/gpio/xilinx_gpio.c | 38 +++++++++++++++++++++++++++++++++-----
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
> index 4da9ae114d87..9d3e9379d0e5 100644
> --- a/drivers/gpio/xilinx_gpio.c
> +++ b/drivers/gpio/xilinx_gpio.c
> @@ -358,6 +358,11 @@ struct xilinx_gpio_platdata {
> int bank_max[XILINX_GPIO_MAX_BANK];
> int bank_input[XILINX_GPIO_MAX_BANK];
> int bank_output[XILINX_GPIO_MAX_BANK];
> + u32 dout_default[XILINX_GPIO_MAX_BANK];
> +};
> +
> +struct xilinx_gpio_privdata {
> + u32 output_val[XILINX_GPIO_MAX_BANK];
> };
>
> static int xilinx_gpio_get_bank_pin(unsigned offset, u32 *bank_num,
> @@ -387,6 +392,7 @@ static int xilinx_gpio_set_value(struct udevice *dev, unsigned offset,
> int value)
> {
> struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
> + struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
> int val, ret;
> u32 bank, pin;
>
> @@ -394,19 +400,21 @@ static int xilinx_gpio_set_value(struct udevice *dev, unsigned offset,
> if (ret)
> return ret;
>
> - debug("%s: regs: %lx, value: %x, gpio: %x, bank %x, pin %x\n",
> - __func__, (ulong)platdata->regs, value, offset, bank, pin);
> + val = priv->output_val[bank];
> +
> + debug("%s: regs: %lx, value: %x, gpio: %x, bank %x, pin %x, out %x\n",
> + __func__, (ulong)platdata->regs, value, offset, bank, pin, val);
>
> if (value) {
> - val = readl(&platdata->regs->gpiodata + bank * 2);
> val = val | (1 << pin);
> writel(val, &platdata->regs->gpiodata + bank * 2);
> } else {
> - val = readl(&platdata->regs->gpiodata + bank * 2);
> val = val & ~(1 << pin);
> writel(val, &platdata->regs->gpiodata + bank * 2);
> }
You could replace the two writel function calls by one.
>
> + priv->output_val[bank] = val;
> +
> return val;
> };
>
> @@ -441,6 +449,7 @@ static int xilinx_gpio_get_function(struct udevice *dev, unsigned offset)
> static int xilinx_gpio_get_value(struct udevice *dev, unsigned offset)
> {
> struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
> + struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
> int val, ret;
> u32 bank, pin;
>
> @@ -451,7 +460,14 @@ static int xilinx_gpio_get_value(struct udevice *dev, unsigned offset)
> debug("%s: regs: %lx, gpio: %x, bank %x, pin %x\n", __func__,
> (ulong)platdata->regs, offset, bank, pin);
>
> - val = readl(&platdata->regs->gpiodata + bank * 2);
> + if (xilinx_gpio_get_function(dev, offset) == GPIOF_INPUT) {
> + debug("%s: Read input value from reg\n", __func__);
> + val = readl(&platdata->regs->gpiodata + bank * 2);
> + } else {
> + debug("%s: Read saved output value\n", __func__);
> + val = priv->output_val[bank];
> + }
Why you don't always read the data register? This doesn't work for three
state outputs.
> +
> val = !!(val & (1 << pin));
>
> return val;
> @@ -558,11 +574,17 @@ static int xilinx_gpio_probe(struct udevice *dev)
> {
> struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
> struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> + struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
>
> uc_priv->bank_name = dev->name;
>
> uc_priv->gpio_count = platdata->bank_max[0] + platdata->bank_max[1];
>
> + priv->output_val[0] = platdata->dout_default[0];
> +
> + if (platdata->bank_max[1])
> + priv->output_val[1] = platdata->dout_default[1];
> +
> return 0;
> }
>
> @@ -579,6 +601,9 @@ static int xilinx_gpio_ofdata_to_platdata(struct udevice *dev)
> "xlnx,all-inputs", 0);
> platdata->bank_output[0] = dev_read_u32_default(dev,
> "xlnx,all-outputs", 0);
> + platdata->dout_default[0] = dev_read_u32_default(dev,
> + "xlnx,dout-default",
> + 0);
>
> is_dual = dev_read_u32_default(dev, "xlnx,is-dual", 0);
> if (is_dual) {
> @@ -588,6 +613,8 @@ static int xilinx_gpio_ofdata_to_platdata(struct udevice *dev)
> "xlnx,all-inputs-2", 0);
> platdata->bank_output[1] = dev_read_u32_default(dev,
> "xlnx,all-outputs-2", 0);
> + platdata->dout_default[1] = dev_read_u32_default(dev,
> + "xlnx,dout-default-2", 0);
> }
>
> return 0;
> @@ -606,5 +633,6 @@ U_BOOT_DRIVER(xilinx_gpio) = {
> .ofdata_to_platdata = xilinx_gpio_ofdata_to_platdata,
> .probe = xilinx_gpio_probe,
> .platdata_auto_alloc_size = sizeof(struct xilinx_gpio_platdata),
> + .priv_auto_alloc_size = sizeof(struct xilinx_gpio_privdata),
> };
> #endif
Best regards
 Stefan
^ permalink raw reply
* [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name
From: Simon Glass @ 2018-07-23 18:41 UTC (permalink / raw)
To: u-boot
In-Reply-To: <f6624e7e-2b89-ff90-c648-c43316aca718@xilinx.com>
Hi Michal,
On 23 July 2018 at 03:08, Michal Simek <michal.simek@xilinx.com> wrote:
>
> On 20.7.2018 21:31, Stefan Herbrechtsmeier wrote:
> > Hi Michal,
> >
> > Am 12.07.2018 um 16:04 schrieb Michal Simek:
> >> There should be proper bank name setup to distiguish between different
> >> gpio drivers. Use dev->name for it.
> >>
> >> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> >> ---
> >>
> >> drivers/gpio/zynq_gpio.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
> >> index 26f69b1a713f..f793ee5754a8 100644
> >> --- a/drivers/gpio/zynq_gpio.c
> >> +++ b/drivers/gpio/zynq_gpio.c
> >> @@ -337,6 +337,8 @@ static int zynq_gpio_probe(struct udevice *dev)
> >> struct zynq_gpio_privdata *priv = dev_get_priv(dev);
> >> struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> >> + uc_priv->bank_name = dev->name;
> >> +
> >> if (priv->p_data)
> >> uc_priv->gpio_count = priv->p_data->ngpio;
> >>
> > Does this not lead to ugly names because the gpio number is append to
> > the bank_name? Have you check the "gpio status -a" output?
>
> Yes I was checking it. Names are composed together but also just numbers
> works as before.
>
> gpio at ff0a00000: input: 0 [ ]
> gpio at ff0a00001: input: 0 [ ]
> gpio at ff0a00002: input: 0 [ ]
> gpio at ff0a00003: input: 0 [ ]
> gpio at ff0a00004: input: 0 [ ]
> gpio at ff0a00005: input: 0 [ ]
> gpio at ff0a00006: input: 0 [ ]
> gpio at ff0a00007: input: 0 [ ]
> gpio at ff0a00008: input: 0 [ ]
> gpio at ff0a00009: input: 0 [ ]
>
> If you know better way how to setup a bank name please let me know but I
> need to distinguish ps gpio from pl one and for pl we need to know the
> address.
>
> >
> > Other drivers use the gpio-bank-name from the device tree.
>
> I can't see this property inside Linux kernel. If this has been reviewed
> by dt guys please let me know.
Linux doesn't have this concept and has no command line. I am
skeptical they would be interested in adding the property.
If we can get this in by renaming it (e.g. to u-boot,gpio-bank-name)
then that would be OK. Otherwise I think we just have to rely on
having our own binding file.
Regards,
Simon
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V10 10/20] qmp event: Add COLO_EXIT event to notify users while exited COLO
From: Eric Blake @ 2018-07-23 18:41 UTC (permalink / raw)
To: Zhang Chen, qemu-devel, Paolo Bonzini, Juan Quintela,
Dr . David Alan Gilbert, Jason Wang, Markus Armbruster
Cc: zhanghailiang, Li Zhijian
In-Reply-To: <20180722193350.6028-11-zhangckid@gmail.com>
On 07/22/2018 02:33 PM, Zhang Chen wrote:
> From: zhanghailiang <zhang.zhanghailiang@huawei.com>
>
> If some errors happen during VM's COLO FT stage, it's important to
> notify the users of this event. Together with 'x-colo-lost-heartbeat',
> Users can intervene in COLO's failover work immediately.
> If users don't want to get involved in COLO's failover verdict,
> it is still necessary to notify users that we exited COLO mode.
>
> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
> Signed-off-by: Zhang Chen <zhangckid@gmail.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> Reviewed-by: Markus Armbruster <armbru@redhat.com>
> ---
> migration/colo.c | 31 +++++++++++++++++++++++++++++++
> qapi/migration.json | 38 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 69 insertions(+)
At this point in the release cycle, this series feels like enough of a
new feature (rather than a bug fix) that it is probably not appropriate
for 3.0, which means...
> +++ b/qapi/migration.json
> @@ -900,6 +900,44 @@
> { 'enum': 'FailoverStatus',
> 'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] }
>
> +##
> +# @COLO_EXIT:
> +#
> +# Emitted when VM finishes COLO mode due to some errors happening or
> +# at the request of users.
> +#
> +# @mode: report COLO mode when COLO exited.
> +#
> +# @reason: describes the reason for the COLO exit.
> +#
> +# Since: 3.0
...this and other references should be updated to 3.1.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: [PATCH] tpm: add support for nonblocking operation
From: Jarkko Sakkinen @ 2018-07-23 17:38 UTC (permalink / raw)
To: Tadeusz Struk; +Cc: flihp, linux-integrity
In-Reply-To: <7c197161-9cb2-1e67-bb7f-b360d557bad9@intel.com>
On Mon, Jul 16, 2018 at 01:10:42PM -0700, Tadeusz Struk wrote:
> On 07/16/2018 10:34 AM, Jarkko Sakkinen wrote:
> > On Thu, Jul 05, 2018 at 04:15:06PM -0700, flihp wrote:
> >> Thanks for reviewing the patch Jarkko. While you're doing that I took
> >> some time to hack up code to demonstrate the utility of supporting this
> >> feature. The code can be found here:
> >>
> >> https://github.com/flihp/glib-tss2-async-example
> >>
> >> In short, the example application `glib-tss2-event` uses a glib main
> >> event loop to create an RSA 2048 primary key in the TPM2 NULL hierarchy
> >> while using a glib timer event to time the operation. A GSource object
> >> is used to generate an event when the FD underlying the tss2 function
> >> call has data ready. While the application waits for an event indicating
> >> that the CreatePrimary operation is complete, it counts timer events
> >> that occur every 100ms. Once the CreatePrimary operation completes the
> >> number of timer events that occurred is used to make a rough calculation
> >> of the elapsed time. This value is then printed to the console.
> >>
> >> This takes ~300 lines of C code and requires no management or
> >> synchronization of threads. The glib GMainContext is "just a poll()
> >> loop" according to the glib documentation here:
> >>
> >> https://developer.gnome.org/programming-guidelines/stable/main-contexts.html.en
> >>
> >> and so supporting 'poll' is the easiest way to integrate with glib /
> >> gtk+. This is true of any other event system that relies on 'poll'
> >> instead of worker threads.
> >>
> >> I've tested this against the userspace resource management daemon (which
> >> supports 'poll') as well as the kernel interface using Tadeusz's patch
> >> currently under review here. If / when this gets merged feel free to add
> >> a "tested-by" line for myself:
> >> Tested-by: Philip Tricca <philip.b.tricca@intel.com>
> >
> > I see the value now. I'll test this at early August when I'm back from
> > my leave.
> >
> > Noticed now that the whole patch should be reposted because CC is missing
> > linux-kernel and linux-security-module (maybe with a link to your test
> > application in the cover letter).
>
> I'll rebase and resend it after you will be back from vacation.
> Thanks,
> --
> Tadeusz
Please add also the requested CC's. Thank you.
/Jarkko
^ permalink raw reply
* Re: [PATCH] firmware: vpd: Fix section enabled flag on vpd_section_destroy
From: Dmitry Torokhov @ 2018-07-23 18:39 UTC (permalink / raw)
To: Guenter Roeck
Cc: Anton Vasilyev, Greg Kroah-Hartman, Samuel Holland, Pan Bian,
linux-kernel, ldv-project
In-Reply-To: <20180723182710.GB2964@roeck-us.net>
On Mon, Jul 23, 2018 at 11:27:10AM -0700, Guenter Roeck wrote:
> On Mon, Jul 23, 2018 at 10:23:05AM -0700, Dmitry Torokhov wrote:
> > On Mon, Jul 23, 2018 at 10:13:36AM -0700, Guenter Roeck wrote:
> > > On Mon, Jul 23, 2018 at 07:48:57PM +0300, Anton Vasilyev wrote:
> > > > static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
> > > > in vpd_probe() based on header's ro and rw sizes.
> > > > In vpd_remove() vpd_section_destroy() performs deinitialization based
> > > > on enabled flag, which is set to true by vpd_sections_init().
> > > > This leads to call of vpd_section_destroy() on already destroyed section
> > > > for probe-release-probe-release sequence if first probe performs
> > > > ro_vpd initialization and second probe does not initialize it.
> > > >
> > >
> > > I am not sure if the situation described can be seen in the first place.
> > > The second probe would only not perform ro_vpd initialization if it fails
> > > prior to that, ie if it fails to allocate memory or if there is a
> > > consistency problem. In that case the remove function would not be called.
> > >
> > > However, there is a problem in the code: A partially failed probe will
> > > leave the system in inconsistent state. Example: ro section initializes,
> > > rw section fails to initialize. The probe will fail, but the ro section
> > > will not be destroyed, its sysfs attributes still exist, and its memory
> > > is still mapped. It would make more sense to fix _that_ problem.
> > > Essentially, vpd_sections_init() should clean up after itself after it
> > > fails to initialize a section.
> > >
> > > Note that I am not convinced that the "enabled" flag is needed in the first
> > > place. It is only relevant if vpd_section_destroy() is called, which only
> > > happens from the remove function. The remove function is only called if the
> > > probe function succeeded. In that case it is always set for both sections.
> >
> > The problem will happen if coreboot memory changes between 2 probes so
> > that header.ro_size is not 0 on the first pass and is 0 on the second
> > pass. Not quite likely to ever happen in real life, but resetting a flag
> > is pretty cheap to not do it.
> >
>
> If that can happen between probes, meaning it is not guaranteed to be
> constant during the lifetime of the system, doesn't that mean it can
> happen anytime ?
I think we can assume that the data is stable while coreboot device is
registered, but I can imagine one can theoretically have a debug
coreboot data provider that can supply different coreboot parameters
across load/unload. I.e. we have coreboot_table-acpi.c and
coreboot_table-of.c, we might create coreboot_table-test.c to feed
arbitrary data to the subsystem.
Thanks.
--
Dmitry
^ 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.