* ✓ Fi.CI.IGT: success for igt/kms_rotation_crc: Add horizontal flip subtest.
From: Patchwork @ 2017-10-05 2:27 UTC (permalink / raw)
To: Anusha Srivatsa; +Cc: intel-gfx
In-Reply-To: <1507164223-22598-1-git-send-email-anusha.srivatsa@intel.com>
== Series Details ==
Series: igt/kms_rotation_crc: Add horizontal flip subtest.
URL : https://patchwork.freedesktop.org/series/31407/
State : success
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_299/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [Bug 187051] "orphan list check failed" error in ext4
From: bugzilla-daemon @ 2017-10-05 2:27 UTC (permalink / raw)
To: linux-ext4
In-Reply-To: <bug-187051-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=187051
--- Comment #21 from Theodore Tso (tytso@mit.edu) ---
Can you try to see if you can reliably reproduce the problem?
And then can you see if you can reproduce it on some other hardware?
Note that one of the reasons why it's unfortunate when people reopen bugs,
especially when the original reporter has concluded it was probably caused by a
hardware issue in his case, is that it can sometimes be hard to disambiguate
data from the first report and successive reports. (This is why I hate it
when Ubuntu users, in particular, glom on to reports by googling by symptom,
and assume that just because it has the same symptom, that it must be related
to every other problem with the same symptom, and all pile onto the same
Launchpad bug. It's also why I believe Launchpad is mostly hopeless for a
developer....)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Buildroot] [Bug 10361] New: python3 python-config script generates invalid includes
From: bugzilla at busybox.net @ 2017-10-05 2:19 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=10361
Bug ID: 10361
Summary: python3 python-config script generates invalid
includes
Product: buildroot
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: matthew.weber at rockwellcollins.com
CC: buildroot at uclibc.org
Target Milestone: ---
If building in a path that starts with /usr, the includedir=$(echo
"@includedir@" | sed "s#^$prefix_build#$prefix_real#") assignment in the
python-config.sh ends up having the path it processes ran through a path
substitution once before this line is executed because the @includedir@ in the
python-config.sh.in is set to the string '${prefix}/include'. ${prefix} is
assigned just above includedir in python-config.sh to prefix=$(echo
"$prefix_build" | sed "s#^$prefix_build#$prefix_real#")
I believe we need to update the line ref below to
includedir=$(echo "@includedir@")
https://git.busybox.net/buildroot/tree/package/python3/0010-Misc-python-config.sh.in-ensure-sed-invocations-only.patch#n43
Another option would be to rename the prefix variable in this file so that
there isn't a naming conflict......
Example build failure
http://autobuild.buildroot.net/results/dfd/dfdac93d25d5730f08aa747e615a1a1c3ac7f1c0/
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options
From: Tobin C. Harding @ 2017-10-05 2:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Roberts, William C, Tejun Heo, Jordan Glover, Greg KH,
Petr Mladek, Joe Perches, Ian Campbell, Sergey Senozhatsky,
kernel-hardening@lists.openwall.com, Catalin Marinas, Will Deacon,
Steven Rostedt, Chris Fries, Dave Weinstein
In-Reply-To: <CA+55aFwEZCT6=BCdmaNn5LGeU8g-2qi4OnM9MTOep3NOZVXjMg@mail.gmail.com>
On Wed, Oct 04, 2017 at 04:52:58PM -0700, Linus Torvalds wrote:
> On Wed, Oct 4, 2017 at 2:58 PM, Roberts, William C
> <william.c.roberts@intel.com> wrote:
> >
> > I agree with you 100% kptr restrict is odd, and I don't think anyone should have had to opt in to be
> > cleansed via kptr_restrict value via %pK. Opt-in never works. One nice thing now, is that checkpatch
> > has checking of %p usages and warns.
>
> Yeah, the checkpatch thing may help for future patches.
>
> > As far as broken things, I can't comment on desktop systems where I think it's harder to make that claim.
> > I see value in embedded systems where I am shipping the whole image, So I know when/what will
> > break.
> >
> > If this was in-tree, Android would be setting this to 4 immediately FWIW.
>
> Does android set it to 2 right now?
>
> But even if it does, my point is that we've had this thing for 6+
> years, and it really hasn't helped fix our code much at all.
>
> In fact, I think the opposite is true. I think it *hurts*. It hurts
> exactly because it's a hack, and it makes people not bother to fix the
> real problems.
>
> I think we'd be better off just fixing code.
>
> One thing you can do today is just look through your 'dmesg' for what
> looks like kernel addresses (if virtual addresses is what you're
> interested in - obviously physical addresses will look different). On
> x86-64, for example, something like this:
>
> dmesg | egrep 'ffff[0-9a-f]{12}'
>
> might be interesting to look at. It shows (for me) that we show the
> percpu address mapping, for example. That certainly sounds interesting
> to a potential attacker, and I suspect Tejun isn't really interested
> in that information any more. Added to Cc.
>
> It also shows
>
> software IO TLB [mem PA-PB] (64MB) mapped at [VA-VB]
>
> for example. And THIS IS IMPORTANT! The physical address is shown
> with "%#010llx".
>
> See what I'm saying? The kptr_restrict games are just that: games and
> security theater. If you actually care about things like physical
> addresses, you don't say "let's hide %pa". Because that's not how the
> real world works. I found one case that would entirely have missed
> with the very first trivial grep I did.
>
> So I'm claiming that anybody who says "it's too hard to fix it for
> real, let's just paper over it in vsprintf.c" is fundamentally going
> to miss things like this. I agree that it might be painful to try to
> figure out where the problems are, but somebody like google probably
> has a lot of dmesg output, and it should not be that hard to do the
> above kinds of "let's just see what leaks, and FIX it".
This sounds like just the job for an upcoming kernel hacker, with a lot of time
and not much experience, to do something laborious that no one else wants to do
and learn a bunch about the kernel.
So what if we drop this patch set and
1. Find and fix every place in the kernel that leaks addresses.
2. Verify that checkpatch.pl warns for all potential future leakage.
2. Add a script to check dmesg output for future hardening.
I'm super keen to work. I would have to get everyone to dump their ideas/demands
onto me if we are to get this fixed fully.
thanks,
Tobin.
^ permalink raw reply
* Re: [PATCH v4 11/14] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver
From: Darren Hart @ 2017-10-05 2:14 UTC (permalink / raw)
To: Mario Limonciello
Cc: Andy Shevchenko, LKML, platform-driver-x86, Andy Lutomirski,
quasisec, pali.rohar, rjw, mjg59, hch, Greg KH
In-Reply-To: <8b37d47244fbba75ea264d06d4e7966a1f8f8f7a.1507156392.git.mario.limonciello@dell.com>
On Wed, Oct 04, 2017 at 05:48:37PM -0500, Mario Limonciello wrote:
> The dell-smbios stack only currently uses an SMI interface which grants
> direct access to physical memory to the firmware SMM methods via a pointer.
>
> This dispatcher driver adds a WMI-ACPI interface that is detected by WMI
> probe and preferred over the SMI interface in dell-smbios.
>
> Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
> for a buffer of data storage when SMM calls are performed.
>
> This is a safer approach to use in kernel drivers as the SMM will
> only have access to that OperationRegion.
>
> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
> MAINTAINERS | 6 +
> drivers/platform/x86/Kconfig | 16 ++-
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/dell-smbios-wmi.c | 215 +++++++++++++++++++++++++++++++++
> drivers/platform/x86/dell-smbios-wmi.h | 28 +++++
> 5 files changed, 265 insertions(+), 1 deletion(-)
> create mode 100644 drivers/platform/x86/dell-smbios-wmi.c
> create mode 100644 drivers/platform/x86/dell-smbios-wmi.h
>
...
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index f0b97cb8e449..ef597f440d2e 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -93,13 +93,27 @@ config ASUS_LAPTOP
>
> config DELL_SMBIOS
> tristate "Dell SMBIOS calling interface"
> - depends on DELL_SMBIOS_SMM
> + depends on DELL_SMBIOS_WMI || DELL_SMBIOS_SMM
> ---help---
> This module provides common functions for kernel modules using
> Dell SMBIOS.
You use select DELL_SMBIOS below, which implies this modules should be
invisible. Indeed, there is no need for the user to see the DELL_SMBIOS
option at all now, they can select DELL_SMBIOS_WMI and or
DELL_SMBIOS_SMM, no need to keep the DELL_SMBIOS option.
> diff --git a/drivers/platform/x86/dell-smbios-wmi.c b/drivers/platform/x86/dell-smbios-wmi.c
> +static void __init parse_b1_table(const struct dmi_header *dm)
> +{
> + struct misc_bios_flags_structure *flags =
> + container_of(dm, struct misc_bios_flags_structure, header);
> +
> + /* 4 bytes header, and one word of flags */
Assuming specifically 8 bytes of flags, independent of arch?
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] nfp: convert nfp_eth_set_bit_config() into a macro
From: Manoj Gupta @ 2017-10-05 2:13 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Matthias Kaehlcke, Joe Perches, David S . Miller, Simon Horman,
Dirk van der Merwe, oss-drivers, netdev, linux-kernel,
Renato Golin, Guenter Roeck, Doug Anderson
In-Reply-To: <20171004190621.4f0a8f83@cakuba.netronome.com>
On Wed, Oct 4, 2017 at 7:06 PM, Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
> On Wed, 4 Oct 2017 18:50:04 -0700, Manoj Gupta wrote:
>> On Wed, Oct 4, 2017 at 5:56 PM, Jakub Kicinski wrote:
>> > On Wed, 4 Oct 2017 17:38:22 -0700, Manoj Gupta wrote:
>> >> On Wed, Oct 4, 2017 at 4:25 PM, Jakub Kicinski wrote:
>> >> > On Wed, 4 Oct 2017 16:16:49 -0700, Matthias Kaehlcke wrote:
>> >> >> > > Thanks for the suggestion. This seems a viable alternative if David
>> >> >> > > and the NFP owners can live without the extra checking provided by
>> >> >> > > __BF_FIELD_CHECK.
>> >> >> >
>> >> >> > The reason the __BF_FIELD_CHECK refuses to compile non-constant masks
>> >> >> > is that it will require runtime ffs on the mask, which is potentially
>> >> >> > costly. I would also feel quite stupid adding those macros to the nfp
>> >> >> > driver, given that I specifically created the bitfield.h header to not
>> >> >> > have to reimplement these in every driver I write/maintain.
>> >> >>
>> >> >> That make sense, thanks for providing more context.
>> >> >>
>> >> >> > Can you please test the patch I provided in the other reply?
>> >> >>
>> >> >> With this patch there are no errors when building the kernel with
>> >> >> clang.
>> >> >
>> >> > Cool, thanks for checking! I will run it through full tests and queue
>> >> > for upstreaming :)
>> >>
>> >> Just to let you know, using __BF_FIELD_CHECK macro will not Link with
>> >> -O0 (GCC or Clang) since references to __compiletime_assert_xxx will
>> >> not be cleaned up.
>> >
>> > Do you mean the current nfp_eth_set_bit_config() will not work with -O0
>> > on either complier, or any use of __BF_FIELD_CHECK() will not compile
>> > with -O0?
>>
>> Any use of __BF_FIELD_CHECK. The code will compile but not link since
>> calls to ____compiletime_assert_xxx (added by compiletime_assert
>> macro) will not be removed in -O0.
>
> Why would that be, it's just a macro? Does it by extension mean any
> use of BUILD_BUG_ON_MSG() will not compile with -O0?
You have to look at the the code added once the macro is expanded :).
Please look at implementation of compiletime_assert at
http://elixir.free-electrons.com/linux/v4.12.14/source/include/linux/compiler.h#L507
It creates a call to __compiler_assert_xxx inside a loop which is not
cleaned up in -O0.
Thanks,
Manoj
^ permalink raw reply
* Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers
From: Jonathan Nieder @ 2017-10-05 2:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Taylor Blau, git, peff
In-Reply-To: <xmqq376y9xf7.fsf@gitster.mtv.corp.google.com>
Junio C Hamano wrote:
> From: Taylor Blau <me@ttaylorr.com>
> Date: Mon, 2 Oct 2017 09:10:34 -0700
> Subject: [PATCH] ref-filter.c: pass empty-string as NULL to atom parsers
>
> Peff points out that different atom parsers handle the empty
> "sub-argument" list differently. An example of this is the format
> "%(refname:)".
>
> Since callers often use `string_list_split` (which splits the empty
> string with any delimiter as a 1-ary string_list containing the empty
> string), this makes handling empty sub-argument strings non-ergonomic.
>
> Let's fix this by declaring that atom parser implementations must
> not care about distinguishing between the empty string "%(refname:)"
> and no sub-arguments "%(refname)". Current code aborts, either with
> "unrecognised arg" (e.g. "refname:") or "does not take args"
> (e.g. "body:") as an error message.
>
> Signed-off-by: Taylor Blau <me@ttaylorr.com>
> Reviewed-by: Jeff King <peff@peff.net>
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> ref-filter.c | 10 +++++++++-
> t/t6300-for-each-ref.sh | 1 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
Thanks for taking care of it. This is indeed still
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* [LTP] [PATCH v2] cve/cve-2016-10044.c: fix two errors
From: Xiao Yang @ 2017-10-05 2:11 UTC (permalink / raw)
To: ltp
In-Reply-To: <1506391449-5646-1-git-send-email-yangx.jy@cn.fujitsu.com>
Hi,
Ping :-)
Thanks,
Xiao Yang.
On 2017/09/26 10:04, Xiao Yang wrote:
> 1) If the number of nr_events exceeds the limit of available events
> defined in /proc/sys/fs/aio-max-nr, it returns EAGAIN. We should
> call io_destroy() to cleanup the AIO context after finishing test.
>
> Steps to reproduce this error:
> #echo 4 > /proc/sys/fs/aio-max-nr
> # ./cve-2016-10044 -i 5
> tst_test.c:908: INFO: Timeout per run is 0h 05m 00s
> cve-2016-10044.c:62: FAIL: AIO mapping is executable: rwxs!
> cve-2016-10044.c:62: FAIL: AIO mapping is executable: rwxs!
> cve-2016-10044.c:62: FAIL: AIO mapping is executable: rwxs!
> cve-2016-10044.c:62: FAIL: AIO mapping is executable: rwxs!
> cve-2016-10044.c:49: BROK: Failed to create AIO context: EAGAIN/EWOULDBLOCK
>
> 2) This case fails with TBROK on an old kernel(e.g. v2.6.32) because
> the mapping file does not exist.
>
> The old format of file is set to 'anon_inode:[aio]' by the following
> patch set:
> '55708698c5f1("fs/anon_inode: Introduce a new lib function anon_inode_getfile_private()")'
> '36bc08cc0170("fs/aio: Add support to aio ring pages migration")'
>
> The current format of file is set to '/[aio]' by the following patch:
> '71ad7490c1f3("rework aio migrate pages to use aio fs")'
>
> We change the keyword into '[aio]' to match as many formats as
> possible, and return TCONF if the mapping file does not exist.
>
> Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
> ---
> testcases/cve/cve-2016-10044.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/testcases/cve/cve-2016-10044.c b/testcases/cve/cve-2016-10044.c
> index 7928d27..14fa0a4 100644
> --- a/testcases/cve/cve-2016-10044.c
> +++ b/testcases/cve/cve-2016-10044.c
> @@ -50,10 +50,10 @@ static void run(void)
>
> f = SAFE_FOPEN("/proc/self/maps", "r");
> while (fgets(line, BUFSIZ, f) != NULL) {
> - if (strstr(line, "/[aio]") != NULL)
> + if (strstr(line, "[aio]") != NULL)
> goto found_mapping;
> }
> - tst_brk(TBROK, "Could not find mapping in /proc/self/maps");
> + tst_brk(TCONF, "Could not find mapping in /proc/self/maps");
>
> found_mapping:
> if (sscanf(line, "%*x-%*x %s7", perms) < 0)
> @@ -63,6 +63,9 @@ found_mapping:
> else
> tst_res(TPASS, "AIO mapping is not executable: %s", perms);
>
> + if (tst_syscall(__NR_io_destroy, ctx))
> + tst_brk(TBROK | TERRNO, "Failed to destroy AIO context");
> +
> SAFE_FCLOSE(f);
> f = NULL;
> }
^ permalink raw reply
* Re: [PATCH 13/25] xfs: scrub inode btrees
From: Dave Chinner @ 2017-10-05 2:08 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <150706333138.19351.1481631767118687082.stgit@magnolia>
On Tue, Oct 03, 2017 at 01:42:11PM -0700, Darrick J. Wong wrote:
> +/*
> + * Set us up to scrub inode btrees.
> + * If we detect a discrepancy between the inobt and the inode,
> + * try again after forcing logged inode cores out to disk.
> + */
> +int
> +xfs_scrub_setup_ag_iallocbt(
> + struct xfs_scrub_context *sc,
> + struct xfs_inode *ip)
> +{
> + return xfs_scrub_setup_ag_btree(sc, ip, sc->try_harder);
> +}
> +
> +/* Inode btree scrubber. */
> +
> +/* Is this chunk worth checking? */
> +STATIC bool
> +xfs_scrub_iallocbt_chunk(
> + struct xfs_scrub_btree *bs,
> + struct xfs_inobt_rec_incore *irec,
> + xfs_agino_t agino,
> + xfs_extlen_t len)
> +{
> + struct xfs_mount *mp = bs->cur->bc_mp;
> + struct xfs_agf *agf;
> + unsigned long long rec_end;
> + xfs_agblock_t eoag;
> + xfs_agblock_t bno;
> +
> + agf = XFS_BUF_TO_AGF(bs->sc->sa.agf_bp);
> + eoag = be32_to_cpu(agf->agf_length);
Probably should use the AGI for this.
> + bno = XFS_AGINO_TO_AGBNO(mp, agino);
> + rec_end = (unsigned long long)bno + len;
> +
> + if (bno >= mp->m_sb.sb_agblocks || bno >= eoag ||
> + rec_end > mp->m_sb.sb_agblocks || rec_end > eoag) {
Same comment as last patch.
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> + return false;
> + }
> +
> + return true;
> +}
I note there is no check on the length passed in for the inode
chunk - should that be verified?
> +
> +/* Count the number of free inodes. */
> +static unsigned int
> +xfs_scrub_iallocbt_freecount(
> + xfs_inofree_t freemask)
> +{
> + int bits = XFS_INODES_PER_CHUNK;
> + unsigned int ret = 0;
> +
> + while (bits--) {
> + if (freemask & 1)
> + ret++;
> + freemask >>= 1;
> + }
Seems a little cumbersome. Perhaps a loop using xfs_next_bit()
might be a bit faster, something like:
nextbit = xfs_next_bit(&freemask, 1, 0);
while (nextbit != -1) {
ret++;
nextbit = xfs_next_bit(&freemask, 1, nextbit + 1);
}
> +/* Check a particular inode with ir_free. */
> +STATIC int
> +xfs_scrub_iallocbt_check_cluster_freemask(
> + struct xfs_scrub_btree *bs,
> + xfs_ino_t fsino,
> + xfs_agino_t chunkino,
> + xfs_agino_t clusterino,
> + struct xfs_inobt_rec_incore *irec,
> + struct xfs_buf *bp)
> +{
> + struct xfs_dinode *dip;
> + struct xfs_mount *mp = bs->cur->bc_mp;
> + bool freemask_ok;
> + bool inuse;
> + int error;
> +
> + dip = xfs_buf_offset(bp, clusterino * mp->m_sb.sb_inodesize);
> + if (be16_to_cpu(dip->di_magic) != XFS_DINODE_MAGIC ||
> + (dip->di_version >= 3 &&
> + be64_to_cpu(dip->di_ino) != fsino + clusterino)) {
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> + goto out;
> + }
> +
> + freemask_ok = !!(irec->ir_free & XFS_INOBT_MASK(chunkino + clusterino));
No need for !!(...) for a bool type - the compiler will squash it
down to 0/1 autmoatically.
> + error = xfs_icache_inode_is_allocated(mp, bs->cur->bc_tp,
> + fsino + clusterino, &inuse);
> + if (error == -ENODATA) {
> + /* Not cached, just read the disk buffer */
I think that is wrong. xfs_icache_inode_is_allocated() returns
-ENOENT if the inode is not in cache....
> + freemask_ok ^= !!(dip->di_mode);
> + if (!bs->sc->try_harder && !freemask_ok)
> + return -EDEADLOCK;
> + } else if (error < 0) {
> + /* Inode is only half assembled, don't bother. */
> + freemask_ok = true;
Or we had an IO error looking it up. i.e. -EAGAIN is the "half
assembled" state (i.e. in the XFS_INEW state) or the half
*disasembled* state (i.e. XFS_IRECLAIMABLE), anything
else is an error...
> + } else {
> + /* Inode is all there. */
> + freemask_ok ^= inuse;
So inuse is returned from a mode check after iget succeeds. The mode
isn't zeroed until /after/ XFS_IRECLAIMABLE is set, but it's also
set before XFS_INEW is cleared. IOWs, how can
xfs_icache_inode_is_allocated() report anything
other than inuse == true here? If that's the case, what's the point
of the mode check inside xfs_icache_inode_is_allocated()?
> + }
> + if (!freemask_ok)
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +out:
> + return 0;
> +}
> +
> +/* Make sure the free mask is consistent with what the inodes think. */
> +STATIC int
> +xfs_scrub_iallocbt_check_freemask(
> + struct xfs_scrub_btree *bs,
> + struct xfs_inobt_rec_incore *irec)
> +{
> + struct xfs_owner_info oinfo;
> + struct xfs_imap imap;
> + struct xfs_mount *mp = bs->cur->bc_mp;
> + struct xfs_dinode *dip;
> + struct xfs_buf *bp;
> + xfs_ino_t fsino;
> + xfs_agino_t nr_inodes;
> + xfs_agino_t agino;
> + xfs_agino_t chunkino;
> + xfs_agino_t clusterino;
> + xfs_agblock_t agbno;
> + int blks_per_cluster;
> + uint16_t holemask;
> + uint16_t ir_holemask;
> + int error = 0;
> +
> + /* Make sure the freemask matches the inode records. */
> + blks_per_cluster = xfs_icluster_size_fsb(mp);
> + nr_inodes = XFS_OFFBNO_TO_AGINO(mp, blks_per_cluster, 0);
Does this setup and loop work for the case where we have 64k
filesystem blocks and so two or more inode chunks per filesystem
block (i.e. ppc64)?
> +/* Scrub an inobt/finobt record. */
> +STATIC int
> +xfs_scrub_iallocbt_helper(
> + struct xfs_scrub_btree *bs,
> + union xfs_btree_rec *rec)
> +{
> + struct xfs_mount *mp = bs->cur->bc_mp;
> + struct xfs_agi *agi;
> + struct xfs_inobt_rec_incore irec;
> + uint64_t holes;
> + xfs_agino_t agino;
> + xfs_agblock_t agbno;
> + xfs_extlen_t len;
> + int holecount;
> + int i;
> + int error = 0;
> + unsigned int real_freecount;
> + uint16_t holemask;
> +
> + xfs_inobt_btrec_to_irec(mp, rec, &irec);
> +
> + if (irec.ir_count > XFS_INODES_PER_CHUNK ||
> + irec.ir_freecount > XFS_INODES_PER_CHUNK)
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + real_freecount = irec.ir_freecount +
> + (XFS_INODES_PER_CHUNK - irec.ir_count);
> + if (real_freecount != xfs_scrub_iallocbt_freecount(irec.ir_free))
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + agi = XFS_BUF_TO_AGI(bs->sc->sa.agi_bp);
> + agino = irec.ir_startino;
> + agbno = XFS_AGINO_TO_AGBNO(mp, irec.ir_startino);
> + if (agbno >= be32_to_cpu(agi->agi_length)) {
Validate as per every other agbno?
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> + goto out;
> + }
> +
> + if ((agbno & (xfs_ialloc_cluster_alignment(mp) - 1)) ||
> + (agbno & (xfs_icluster_size_fsb(mp) - 1)))
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
What's the magic masking checks being done here? (comment?)
> + /* Handle non-sparse inodes */
> + if (!xfs_inobt_issparse(irec.ir_holemask)) {
> + len = XFS_B_TO_FSB(mp,
> + XFS_INODES_PER_CHUNK * mp->m_sb.sb_inodesize);
> + if (irec.ir_count != XFS_INODES_PER_CHUNK)
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + if (!xfs_scrub_iallocbt_chunk(bs, &irec, agino, len))
> + goto out;
> + goto check_freemask;
> + }
> +
> + /* Check each chunk of a sparse inode cluster. */
> + holemask = irec.ir_holemask;
> + holecount = 0;
> + len = XFS_B_TO_FSB(mp,
> + XFS_INODES_PER_HOLEMASK_BIT * mp->m_sb.sb_inodesize);
> + holes = ~xfs_inobt_irec_to_allocmask(&irec);
> + if ((holes & irec.ir_free) != holes ||
> + irec.ir_freecount > irec.ir_count)
> + xfs_scrub_btree_set_corrupt(bs->sc, bs->cur, 0);
> +
> + for (i = 0; i < XFS_INOBT_HOLEMASK_BITS; holemask >>= 1,
> + i++, agino += XFS_INODES_PER_HOLEMASK_BIT) {
Urk. THat's a bit hard to read.
> + if (holemask & 1) {
> + holecount += XFS_INODES_PER_HOLEMASK_BIT;
> + continue;
> + }
> +
> + if (!xfs_scrub_iallocbt_chunk(bs, &irec, agino, len))
> + break;
> + }
How about
for (i = 0; i < XFS_INOBT_HOLEMASK_BITS; i++) {
if (holemask & 1) {
holecount += XFS_INODES_PER_HOLEMASK_BIT;
} else if (!xfs_scrub_iallocbt_chunk(bs, &irec, agino, len))
break;
holemask >>= 1;
agino += XFS_INODES_PER_HOLEMASK_BIT;
}
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH] nfp: convert nfp_eth_set_bit_config() into a macro
From: Jakub Kicinski @ 2017-10-05 2:06 UTC (permalink / raw)
To: Manoj Gupta
Cc: Matthias Kaehlcke, Joe Perches, David S . Miller, Simon Horman,
Dirk van der Merwe, oss-drivers, netdev, linux-kernel,
Renato Golin, Guenter Roeck, Doug Anderson
In-Reply-To: <CAAMbb05o=50E9_MDuuo1uSTKbr-=Vy4gLgD0Bg-8pMMCcL2kjw@mail.gmail.com>
On Wed, 4 Oct 2017 18:50:04 -0700, Manoj Gupta wrote:
> On Wed, Oct 4, 2017 at 5:56 PM, Jakub Kicinski wrote:
> > On Wed, 4 Oct 2017 17:38:22 -0700, Manoj Gupta wrote:
> >> On Wed, Oct 4, 2017 at 4:25 PM, Jakub Kicinski wrote:
> >> > On Wed, 4 Oct 2017 16:16:49 -0700, Matthias Kaehlcke wrote:
> >> >> > > Thanks for the suggestion. This seems a viable alternative if David
> >> >> > > and the NFP owners can live without the extra checking provided by
> >> >> > > __BF_FIELD_CHECK.
> >> >> >
> >> >> > The reason the __BF_FIELD_CHECK refuses to compile non-constant masks
> >> >> > is that it will require runtime ffs on the mask, which is potentially
> >> >> > costly. I would also feel quite stupid adding those macros to the nfp
> >> >> > driver, given that I specifically created the bitfield.h header to not
> >> >> > have to reimplement these in every driver I write/maintain.
> >> >>
> >> >> That make sense, thanks for providing more context.
> >> >>
> >> >> > Can you please test the patch I provided in the other reply?
> >> >>
> >> >> With this patch there are no errors when building the kernel with
> >> >> clang.
> >> >
> >> > Cool, thanks for checking! I will run it through full tests and queue
> >> > for upstreaming :)
> >>
> >> Just to let you know, using __BF_FIELD_CHECK macro will not Link with
> >> -O0 (GCC or Clang) since references to __compiletime_assert_xxx will
> >> not be cleaned up.
> >
> > Do you mean the current nfp_eth_set_bit_config() will not work with -O0
> > on either complier, or any use of __BF_FIELD_CHECK() will not compile
> > with -O0?
>
> Any use of __BF_FIELD_CHECK. The code will compile but not link since
> calls to ____compiletime_assert_xxx (added by compiletime_assert
> macro) will not be removed in -O0.
Why would that be, it's just a macro? Does it by extension mean any
use of BUILD_BUG_ON_MSG() will not compile with -O0?
^ permalink raw reply
* RE: [PATCH v4 rdma-next 17/18] IB/core: Define 'ib' and 'roce' rdma_ah_attr types
From: Hefty, Sean @ 2017-10-05 2:02 UTC (permalink / raw)
To: Parav Pandit, Hiatt, Don, Dasaratharaman Chandramouli,
Doug Ledford
Cc: linux-rdma
In-Reply-To: <VI1PR0502MB3008B828399AB0A08AA08AC6D1730-o1MPJYiShExKsLr+rGaxW8DSnupUy6xnnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
> > >> +static inline enum rdma_ah_attr_type rdma_ah_find_type(struct
> > >> +ib_device
> > >> *dev,
> > >> + u32 port_num)
> > >> +{
> > >> + if ((rdma_protocol_roce(dev, port_num)) ||
> > >> + (rdma_protocol_iwarp(dev, port_num)))
> > >> + return RDMA_AH_ATTR_TYPE_ROCE;
> > > Check for iWarp to define AH attribute type as RoCE appears error
> to me.
> > > Taking quick look at i40iw and nes drivers appears to return -
> ENOSYS
> > > for
> > i40iw_create_ah(), nes_create_ah.
> > > Will you please submit a fix that avoids above iWarp check?
> > >
> > >
> > i40iw_port_immutable sets the RDMA_CORE_PORT_IWARP immutable flag,
> But when would someone create or initialize ah for iWarp port, given
> than create_ah is unsupported.
> AH type of RoCE for iWarp, doesn't sound correct.
I agree with Parav. Mapping iWarp to AH type RoCE doesn't make sense. IMO, iWarp should map to AH_ATTR_TYPE_UNDEFINED or something similar.
- Sean
^ permalink raw reply
* Re: [PATCH linux dev-4.10] Revert "drivers/hwmon/occ: Add temperature fault attribute and VRM temp alarm"
From: Brad Bishop @ 2017-10-05 2:01 UTC (permalink / raw)
To: Eddie James; +Cc: Joel Stanley, Edward A. James, OpenBMC Maillist
In-Reply-To: <614fb026-d8fa-da2e-584a-c9766319ecea@linux.vnet.ibm.com>
> On Oct 4, 2017, at 11:04 AM, Eddie James <eajames@linux.vnet.ibm.com> wrote:
>
>
>
> On 10/03/2017 11:38 PM, Joel Stanley wrote:
>> On Wed, Oct 4, 2017 at 4:44 AM, Eddie James <eajames@linux.vnet.ibm.com> wrote:
>>> From: "Edward A. James" <eajames@us.ibm.com>
>>>
>>> This reverts commit e55423ee10a5057338d24383c00e813436a126ea.
>>>
>>> Apologies for pushing this up so early... Userspace applications aren't
>>> ready for this change. The hwmon polling application cannot accept EGAIN
>>> yet, and we can't be returning apparent errors if the sensor is
>>> temporarily unavailable.
>> Can you go into some more detail here please.
>>
>> It looks like these changes are within the hwmon ABI, so userspace
>> that supports hwmon devices shouldn't break.
>
> Sure. With this change, the driver returns -EAGAIN when reading temperature sensors that show 0 temperature. Temperature 0 is how the OCC indicates that the sensor is not available at the moment. So, we should retry in a bit. But the hwmon application currently sees any negative errno as an error,
Actually the userspace retries for a configurable period on eio, etimedout,
ebadmsg, eagain, and exnio. It also exits cleanly on enoent.
If any of these errnos don’t go away after the configured number of retry
attempts, an error is logged. Any other errnos and an error is logged
immediately. If this list needs improvement I’d love to hear about it.
ebadmsg and enxio are observed when i2c devices are unplugged with transfers
in various stages of flight. They occur just before the driver is unbound
after the presence gpio toggle on these devices is noticed and processed
(killing the hwmon userspace daemon cleanly).
eio, etimedout seem to be bus type errors that appear somewhat infrequently,
but occur nevertheless.
we all know what eagain means…
It isn’t so much that the hwmon userspace doesn’t support this change,
its just the resulting behavior difference at the other end of the
hwmon abi <-> dbus api translation is not optimal, right now.
1 - Without this change, the hwmon userspace reads a value of 0 out of
the sysfs attribute and happily reports that as the temp at the DBus level.
With this change, the hwmon userspace would read the attribute, get an
error and retry for a bit. After a number of retries, the error is
logged and the sensor is marked faulted at a dbus level.
The issue is the consumer of the sensor at the dbus level. Today, the
dbus consumer happens to translate the sensor value of zero into the
desired behavior. If we submit this change the sensor will be put
into faulted state and the consuming application doesn’t have support
for that yet.
We have open issues to enhance the application to support faulted sensors,
its just not implemented yet.
I hope this helps a decision to be made.
-brad
> and will not retry on -EAGAIN. So now we get errors when we don't want them (for now), basically.
>
> Thanks,
> Eddie
^ permalink raw reply
* Re: Having trouble getting recipe to run in proper directory
From: Paul Eggleton @ 2017-10-05 2:01 UTC (permalink / raw)
To: Greg Wilson-Lindberg; +Cc: yocto
In-Reply-To: <2376f96acc0f4c3db9c3b40a3cfc98f3@sakuraus.com>
Hi Greg,
On Thursday, 5 October 2017 1:16:15 PM NZDT Greg Wilson-Lindberg wrote:
> I'm trying to create a new recipe for a package that has a version and non-numeric rev
> in its name (canfestival-3-asc). I've gotten bitbake to unpack the package into a tree
> that looks ok, but it keeps trying to run the compile at least in the wrong directory.
> Here is the recipe:
>
>
> SUMMARY = "Independent CANOpen® stack"
> DESCRIPTION = "CanFestival focuses on providing an ANSI-C platform independent \
> CANOpen® stack that can be built as master or slave nodes on PCs, \
> Real-time IPCs, and Microcontrollers."
>
> HOMEPAGE = "http://www.canfestival.org/"
>
> SRCREV = "895:8973dd8be7e8"
>
> SRC_URI = "hg://bitbucket.org/Mongo;protocol=https;module=canfestival-3-asc"
> SRC_URI[md5sum] = ""
> SRC_URI[sha256sum] = ""
>
> PN = "canfestival"
> PV = '3'
> PR = 'asc'
>
> LICENSE = "LGPL-2"
> LIC_FILES_CHKSUM = "file://COPYING;md5= \
> file://LICENCE;md5="
>
> inherit autotools
>
> # Specify any options you want to pass to the configure script using EXTRA_OECONF:
> EXTRA_OECONF = "-can=socket -timers=unix -SDO_MAX_SIMULTANEOUS_TRANSFERS=25 \
> -SDO_MAX_LENGTH_TRANSFER=4096 -MAX_NB_TIMER=128 -SDO_TIMEOUT_MS=1000"
>
> PROVIDES = "canfestival"
>
> The directory structure that bitbake builds is:
>
>
> canfestival
>
> 3-asc
>
> build
>
> canfestival-3 # directory that bitbake is trying to compile in
>
> canfestival-3-asc # directory that code was extracted to
>
> temp
>
>
> I'm not getting any errors from the configure task, but the log file looks like
> it is trying to run from the canfestival-3 directory, not the canfestival-3-asc. What
> can I do to the recipe to get the build to run in the canfestival-3-asc directory?
> Or, i guess, get bitbake to unpack the source into the canfestival-3, or a
> different directory that it will actually run the tasks in.
So firstly the directory where the build system should expect to find the
source after do_unpack is specified by the S variable, whose default
is "${WORKDIR}/${BP}" where BP defaults to "${BPN}-${PV}" and BPN will be the
same as PN in this case. However, you're setting the "asc" part in PR -
typically PR is left under the control of the build system and thus your PV
would typically be set to "3-asc" in which case S would default to the right value i.e.
"canfestival-3-asc" (but if it didn't, you would just set S to fix it).
To summarise, set PV = "3-asc" (or alternatively have it picked up from the
file name, i.e. name it canfestival_3-asc.bb) and it should work as you
expect.
A couple of other notes:
* For LICENSE, LGPL-2 isn't a standard value - LGPLv2, LGPLv2.0, LGPLv2.1,
LGPL-2.0, or LGPL-2.1 (with or without + at the end) would be understood
by the build system
* You don't need SRC_URI md5sum/sha256sum for an hg:// URL.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH v4 10/14] platform/x86: dell-smbios-smm: test for WSMT
From: Darren Hart @ 2017-10-05 1:59 UTC (permalink / raw)
To: Mario Limonciello
Cc: Andy Shevchenko, LKML, platform-driver-x86, Andy Lutomirski,
quasisec, pali.rohar, rjw, mjg59, hch, Greg KH
In-Reply-To: <1e16313531397b43c16e147a3a5ad9e74ca3428a.1507156392.git.mario.limonciello@dell.com>
On Wed, Oct 04, 2017 at 05:48:36PM -0500, Mario Limonciello wrote:
> WSMT is as an attestation to the OS that the platform won't
> modify memory outside of pre-defined areas.
>
> If a platform has WSMT enabled in BIOS setup, SMM calls through
> dcdbas will fail. The only way to access platform data in these
> instances is through the WMI SMBIOS calling interface.
Nit: This should probably come after 11/14 where the WMI SMBIOS calling
interface is introduced.
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* ARM32 - build-issues with xen/arm: vpl011: Add a new vuart node in the xenstore
From: Konrad Rzeszutek Wilk @ 2017-10-05 1:58 UTC (permalink / raw)
To: xen-devel, bhupinder.thakur, wei.liu2, sstabellini
I get this when compiling under ARM32 (Ubuntu 15.04,
gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2):
libxl_console.c: In function ‘libxl__device_vuart_add’:
libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=]
flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
^
;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v4 03/15] perf util: refactor inline_list to operate on symbols
From: Namhyung Kim @ 2017-10-05 1:56 UTC (permalink / raw)
To: Milian Wolff
Cc: acme, jolsa, Jin Yao, Linux-kernel, linux-perf-users, Jiri Olsa,
Arnaldo Carvalho de Melo, David Ahern, Peter Zijlstra,
kernel-team
In-Reply-To: <20171001143100.19988-4-milian.wolff@kdab.com>
Hi Milian,
On Sun, Oct 01, 2017 at 04:30:48PM +0200, Milian Wolff wrote:
> This is a requirement to create real callchain entries for inlined
> frames.
>
> Since the list of inlines usually contains the target symbol too,
> i.e. the location where the frames get inlined to, we alias that
> symbol and reuse it as-is is. This ensures that other dependent
> functionality keeps working, most notably annotation of the
> target frames.
>
> For all other entries in the inline_list, a fake symbol is created.
> These are marked by new 'inlined' member which is set to true. Only
> those symbols are managed by the inline_list and get freed when
> the inline_list is deleted from within inline_node__delete.
>
> Cc: Jiri Olsa <jolsa@redhat.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: David Ahern <dsahern@gmail.com>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Yao Jin <yao.jin@linux.intel.com>
> Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
> ---
[SNIP]
> +static struct symbol *new_inline_sym(struct dso *dso,
> + struct symbol *base_sym,
> + const char *funcname)
> +{
> + struct symbol *inline_sym;
> + char *demangled = NULL;
> +
> + if (dso) {
> + demangled = dso__demangle_sym(dso, 0, funcname);
> + if (demangled)
> + funcname = demangled;
> + }
> +
> + if (strcmp(funcname, base_sym->name) == 0) {
It seems you need to check availability of base_sym first as 'else'
statement below checks it. Or if it's guaranteed not NULL (I think
you make it so later), remove the check (and add an assert?) instead.
Thanks,
Namhyung
> + /* reuse the real, existing symbol */
> + inline_sym = base_sym;
> + /* ensure that we don't alias an inlined symbol, which could
> + * lead to double frees in inline_node__delete
> + */
> + assert(!base_sym->inlined);
> + } else {
> + /* create a fake symbol for the inline frame */
> + inline_sym = symbol__new(base_sym ? base_sym->start : 0,
> + base_sym ? base_sym->end : 0,
> + base_sym ? base_sym->binding : 0,
> + funcname);
> + if (inline_sym)
> + inline_sym->inlined = 1;
> + }
> +
> + free(demangled);
> +
> + return inline_sym;
> +}
^ permalink raw reply
* Re: [PATCH v4 09/14] platform/x86: dell-smbios: Introduce dispatcher for SMM calls
From: Darren Hart @ 2017-10-05 1:57 UTC (permalink / raw)
To: Mario Limonciello
Cc: Andy Shevchenko, LKML, platform-driver-x86, Andy Lutomirski,
quasisec, pali.rohar, rjw, mjg59, hch, Greg KH
In-Reply-To: <151b8e5bb0be0a9ef88282581d441a4211465ae7.1507156392.git.mario.limonciello@dell.com>
On Wed, Oct 04, 2017 at 05:48:35PM -0500, Mario Limonciello wrote:
> This splits up the dell-smbios driver into two drivers:
> * dell-smbios
> * dell-smbios-smm
>
> dell-smbios can operate with multiple different dispatcher drivers to
> perform SMBIOS operations.
>
> Also modify the interface that dell-laptop and dell-wmi use align to this
> model more closely. Rather than a single global buffer being allocated
> for all drivers, each driver will allocate and be responsible for it's own
> buffer. The pointer will be passed to the calling function and each
> dispatcher driver will then internally copy it to the proper location to
> perform it's call.
>
> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
> MAINTAINERS | 6 ++
> drivers/platform/x86/Kconfig | 17 ++-
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/dell-laptop.c | 191 ++++++++++++++++-----------------
> drivers/platform/x86/dell-smbios-smm.c | 136 +++++++++++++++++++++++
> drivers/platform/x86/dell-smbios-smm.h | 22 ++++
> drivers/platform/x86/dell-smbios.c | 120 +++++++++++++--------
> drivers/platform/x86/dell-smbios.h | 13 ++-
> drivers/platform/x86/dell-wmi.c | 8 +-
> 9 files changed, 361 insertions(+), 153 deletions(-)
> create mode 100644 drivers/platform/x86/dell-smbios-smm.c
> create mode 100644 drivers/platform/x86/dell-smbios-smm.h
>
...
> +config DELL_SMBIOS_SMM
> + tristate "Dell SMBIOS calling interface (SMM implementation)"
> + depends on DCDBAS
> + default DCDBAS
> + select DELL_SMBIOS
> + ---help---
> + This provides an implementation for the Dell SMBIOS calling interface
> + communicated over ACPI-WMI.
Not over ACPI-WMI... over SMM.... right?
> diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
> index f42159fd2031..c648bbfcc394 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -85,6 +85,7 @@ static struct platform_driver platform_driver = {
> }
> };
>
> +static struct calling_interface_buffer *buffer;
> static struct platform_device *platform_device;
> static struct backlight_device *dell_backlight_device;
> static struct rfkill *wifi_rfkill;
> @@ -405,7 +406,6 @@ static const struct dmi_system_id dell_quirks[] __initconst = {
>
> static int dell_rfkill_set(void *data, bool blocked)
> {
> - struct calling_interface_buffer *buffer;
> int disable = blocked ? 1 : 0;
> unsigned long radio = (unsigned long)data;
> int hwswitch_bit = (unsigned long)data - 1;
> @@ -413,19 +413,21 @@ static int dell_rfkill_set(void *data, bool blocked)
> int status;
> int ret;
>
> - buffer = dell_smbios_get_buffer();
> -
> - dell_smbios_send_request(17, 11);
> + memset(buffer, 0, sizeof(struct calling_interface_buffer));
> + buffer->class = 17;
> + buffer->select = 11;
Please move these three lines into a function, it's used far far too
often to be open coded. The dell_smbios_send_request is a reasonable
wrapper which you could just define here as well. This would minimize
the change to the driver.
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* [Qemu-devel] [Bug 1719196] Re: [arm64 ocata] newly created instances are unable to raise network interfaces
From: Sean Feole @ 2017-10-05 1:46 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <150626680089.6094.17724106932405637799.malonedeb@soybean.canonical.com>
I was able to gather libvirt XMLs from both Newton and Ocata Instances,
see attached
sfeole@BSG-75:~$ diff xmlocata xmlnewton
1,2c1,2
<
< main type='kvm' id='1'>
---
> ubuntu@lundmark:/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c$ sudo virsh dumpxml instance-00000001
> <domain type='kvm' id='1'>
4c4
< <uuid>7c0dcd78-d6b4-4575-a882-ee5d29c64fe0</uuid>
---
> <uuid>358596e4-135d-461d-a514-84116440014c</uuid>
7,9c7,9
< <nova:package version="15.0.6"/>
< <nova:name>sfeole14</nova:name>
< <nova:creationTime>2017-10-05 00:58:15</nova:creationTime>
---
> <nova:package version="14.0.8"/>
> <nova:name>sfeole-newton</nova:name>
> <nova:creationTime>2017-10-05 01:40:39</nova:creationTime>
18,19c18,19
< <nova:user uuid="d9f92a61c37948d9a29b8cc37e1bca05">admin</nova:user>
< <nova:project uuid="701441267bd148d3842f1696530b1c92">admin</nova:project>
---
> <nova:user uuid="12d13712253141ab845b89406507cd6c">admin</nova:user>
> <nova:project uuid="8b8fcaf183954f45b3eb15b27c52ec94">admin</nova:project>
21c21
< <nova:root type="image" uuid="f329117f-5da2-4d61-8341-89a969bf00e7"/>
---
> <nova:root type="image" uuid="fcdf7c26-4238-4594-b8ee-fd59f601fdcb"/>
34c34
< <type arch='aarch64' machine='virt-2.8'>hvm</type>
---
> <type arch='aarch64' machine='virt'>hvm</type>
58c58
< <source file='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/disk'/>
---
> <source file='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/disk'/>
61c61
< <source file='/var/lib/nova/instances/_base/035458feead7f83be80ed020442ebf815a4067ea'/>
---
> <source file='/var/lib/nova/instances/_base/ab7429e8558ea27fb54f70eb92fbd0c1c07dd595'/>
70c70
< <source file='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/disk.eph0'/>
---
> <source file='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/disk.eph0'/>
82a83,93
> <controller type='pci' index='1' model='dmi-to-pci-bridge'>
> <model name='i82801b11-bridge'/>
> <alias name='pci.1'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
> </controller>
> <controller type='pci' index='2' model='pci-bridge'>
> <model name='pci-bridge'/>
> <target chassisNr='2'/>
> <alias name='pci.2'/>
> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
> </controller>
84,86c95,97
< <mac address='fa:16:3e:a6:4b:d4'/>
< <source bridge='qbra7012530-32'/>
< <target dev='tapa7012530-32'/>
---
> <mac address='fa:16:3e:8e:fc:48'/>
> <source bridge='qbrb5d335fc-46'/>
> <target dev='tapb5d335fc-46'/>
92c103
< <source path='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/console.log'/>
---
> <source path='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/console.log'/>
95a107,111
> <serial type='pty'>
> <source path='/dev/pts/3'/>
> <target port='1'/>
> <alias name='serial1'/>
> </serial>
97c113
< <source path='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/console.log'/>
---
> <source path='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/console.log'/>
108,113c124,125
< <label>libvirt-7c0dcd78-d6b4-4575-a882-ee5d29c64fe0</label>
< <imagelabel>libvirt-7c0dcd78-d6b4-4575-a882-ee5d29c64fe0</imagelabel>
< </seclabel>
< <seclabel type='dynamic' model='dac' relabel='yes'>
< <label>+64055:+117</label>
< <imagelabel>+64055:+117</imagelabel>
---
> <label>libvirt-358596e4-135d-461d-a514-84116440014c</label>
> <imagelabel>libvirt-358596e4-135d-461d-a514-84116440014c</imagelabel>
sfeole@BSG-75:~$
** Attachment added: "xmlnotes.txt"
https://bugs.launchpad.net/libvirt/+bug/1719196/+attachment/4962430/+files/xmlnotes.txt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
[arm64 ocata] newly created instances are unable to raise network
interfaces
Status in libvirt:
New
Status in QEMU:
New
Bug description:
arm64 Ocata ,
I'm testing to see I can get Ocata running on arm64 and using the
openstack-base bundle to deploy it. I have added the bundle to the
log file attached to this bug.
When I create a new instance via nova, the VM comes up and runs,
however fails to raise its eth0 interface. This occurs on both
internal and external networks.
ubuntu@openstackaw:~$ nova list
+--------------------------------------+---------+--------+------------+-------------+--------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+---------+--------+------------+-------------+--------------------+
| dcaf6d51-f81e-4cbd-ac77-0c5d21bde57c | sfeole1 | ACTIVE | - | Running | internal=10.5.5.3 |
| aa0b8aee-5650-41f4-8fa0-aeccdc763425 | sfeole2 | ACTIVE | - | Running | internal=10.5.5.13 |
+--------------------------------------+---------+--------+------------+-------------+--------------------+
ubuntu@openstackaw:~$ nova show aa0b8aee-5650-41f4-8fa0-aeccdc763425
+--------------------------------------+----------------------------------------------------------+
| Property | Value |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | awrep3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | awrep3.maas |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | - |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2017-09-24T14:23:08.000000 |
| OS-SRV-USG:terminated_at | - |
| accessIPv4 | |
| accessIPv6 | |
| config_drive | |
| created | 2017-09-24T14:22:41Z |
| flavor | m1.small (717660ae-0440-4b19-a762-ffeb32a0575c) |
| hostId | 5612a00671c47255d2ebd6737a64ec9bd3a5866d1233ecf3e988b025 |
| id | aa0b8aee-5650-41f4-8fa0-aeccdc763425 |
| image | zestynosplash (e88fd1bd-f040-44d8-9e7c-c462ccf4b945) |
| internal network | 10.5.5.13 |
| key_name | mykey |
| metadata | {} |
| name | sfeole2 |
| os-extended-volumes:volumes_attached | [] |
| progress | 0 |
| security_groups | default |
| status | ACTIVE |
| tenant_id | 9f7a21c1ad264fec81abc09f3960ad1d |
| updated | 2017-09-24T14:23:09Z |
| user_id | e6bb6f5178a248c1b5ae66ed388f9040 |
+--------------------------------------+----------------------------------------------------------+
As seen above the instances boot an run. Full Console output is
attached to this bug.
[ OK ] Started Initial cloud-init job (pre-networking).
[ OK ] Reached target Network (Pre).
[ OK ] Started AppArmor initialization.
Starting Raise network interfaces...
[FAILED] Failed to start Raise network interfaces.
See 'systemctl status networking.service' for details.
Starting Initial cloud-init job (metadata service crawler)...
[ OK ] Reached target Network.
[ 315.051902] cloud-init[881]: Cloud-init v. 0.7.9 running 'init' at Fri, 22 Sep 2017 18:29:15 +0000. Up 314.70 seconds.
[ 315.057291] cloud-init[881]: ci-info: +++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++
[ 315.060338] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+
[ 315.063308] cloud-init[881]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
[ 315.066304] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+
[ 315.069303] cloud-init[881]: ci-info: | eth0: | True | . | . | . | fa:16:3e:39:4c:48 |
[ 315.072308] cloud-init[881]: ci-info: | eth0: | True | . | . | d | fa:16:3e:39:4c:48 |
[ 315.075260] cloud-init[881]: ci-info: | lo: | True | 127.0.0.1 | 255.0.0.0 | . | . |
[ 315.078258] cloud-init[881]: ci-info: | lo: | True | . | . | d | . |
[ 315.081249] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+
[ 315.084240] cloud-init[881]: 2017-09-22 18:29:15,393 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0xffffb10794e0>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
----------------
I have checked all services in neutron and made sure that they are
running and restarted in neutron-gateway
[ + ] neutron-dhcp-agent
[ + ] neutron-l3-agent
[ + ] neutron-lbaasv2-agent
[ + ] neutron-metadata-agent
[ + ] neutron-metering-agent
[ + ] neutron-openvswitch-agent
[ + ] neutron-ovs-cleanup
and have also restarted and checked the nova-compute logs for their
neutron counterparts.
[ + ] neutron-openvswitch-agent
[ + ] neutron-ovs-cleanup
There are some warnings/errors in the neutron-gateway logs which I
have attached the full tarball in a separate attachment to this bug:
2017-09-24 14:39:33.152 10322 INFO ryu.base.app_manager [-] instantiating app ryu.controller.ofp_handler of OFPHandler
2017-09-24 14:39:33.153 10322 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService
2017-09-24 14:39:39.577 10322 ERROR neutron.agent.ovsdb.impl_vsctl [req-2f084ae8-13dc-47dc-b351-24c8f3c57067 - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID e02a5f7f-bfd2-4a1d-ae3c-0321db4bd3fb, existed in the database before this transaction and was not modified by the transaction. Second row, with UUID 6e9aba3a-471a-4976-bffd-b7131bbe5377, was inserted by this transaction.","error":"constraint violation"}
These warnings/errors also occur on the nova-compute hosts in
/var/log/neutron/
2017-09-22 18:54:52.130 387556 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService
2017-09-22 18:54:56.124 387556 ERROR neutron.agent.ovsdb.impl_vsctl [req-e291c2f9-a123-422c-be7c-fadaeb5decfa - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID 9f27ddee-9881-4cbc-9777-2f42fee735e9, was inserted by this transaction. Second row, with UUID ccf0e097-09d5-449c-b353-6b69781dc3f7, existed in the database before this transaction and was not modified by the transaction.","error":"constraint violation"}
I'm not sure if the above error could be pertaining to the failure, I
have also attached those logs to this bug as well...
.
(neutron) agent-list
+--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+
| id | agent_type | host | availability_zone | alive | admin_state_up | binary |
+--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+
| 0cca03fb-abb2-4704-8b0b-e7d3e117d882 | DHCP agent | awrep1 | nova | :-) | True | neutron-dhcp-agent |
| 14a5fd52-fbc3-450c-96d5-4e9a65776dad | L3 agent | awrep1 | nova | :-) | True | neutron-l3-agent |
| 2ebc7238-5e61-41f8-bc60-df14ec6b226b | Loadbalancerv2 agent | awrep1 | | :-) | True | neutron-lbaasv2-agent |
| 4f6275be-fc8b-4994-bdac-13a4b76f6a83 | Metering agent | awrep1 | | :-) | True | neutron-metering-agent |
| 86ecc6b0-c100-4298-b861-40c17516cc08 | Open vSwitch agent | awrep1 | | :-) | True | neutron-openvswitch-agent |
| 947ad3ab-650b-4b96-a520-00441ecb33e7 | Open vSwitch agent | awrep4 | | :-) | True | neutron-openvswitch-agent |
| 996b0692-7d19-4641-bec3-e057f4a856f6 | Open vSwitch agent | awrep3 | | :-) | True | neutron-openvswitch-agent |
| ab6b1065-0b98-4cf3-9f46-6bddba0c5e75 | Metadata agent | awrep1 | | :-) | True | neutron-metadata-agent |
| fe24f622-b77c-4eed-ae22-18e4195cf763 | Open vSwitch agent | awrep2 | | :-) | True | neutron-openvswitch-agent |
+--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+
Should neutron-openvswitch be assigned to the 'nova' availability zone?
I have also attached the ovs-vsctl show from a nova-compute host and
the neutron-gateway host to ensure that the open v switch routes are
correct.
I can supply more logs if required.
To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/1719196/+subscriptions
^ permalink raw reply
* Re: [PATCH 0/3] for-each-ref: add :remote-ref and :remote-name specifiers
From: Junio C Hamano @ 2017-10-05 1:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <cover.1506952571.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> Note: the `%(push:remote-name)` placeholder is only interpolated by the value
> of `branch.<name>.pushRemote`; unlike `git push`, it does not fall back to
> `branch.<name>.remote`. Likewise, `%(push:remote-ref)` interpolates to the
> empty string unless `remote.<nick>.pushRefs` is configured.
I think the reason why I had to spend more time than necessary on
the above point during my review on this (otherwise mostly well
done) topic was because of this note. It says what it does, but
does not say why this behaviour is better than the other obvious
alternative.
In a reroll to address the remaining points, please update the log
message (not the cover, which won't be in the committed history) to
explain why we think this is a better choice than an obvious
alternative. Let's help future readers of "git log".
Thanks.
^ permalink raw reply
* Re: [PATCH] nfp: convert nfp_eth_set_bit_config() into a macro
From: Manoj Gupta @ 2017-10-05 1:50 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Matthias Kaehlcke, Joe Perches, David S . Miller, Simon Horman,
Dirk van der Merwe, oss-drivers, netdev, linux-kernel,
Renato Golin, Guenter Roeck, Doug Anderson
In-Reply-To: <20171004175603.4ba68737@cakuba.netronome.com>
On Wed, Oct 4, 2017 at 5:56 PM, Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
> On Wed, 4 Oct 2017 17:38:22 -0700, Manoj Gupta wrote:
>> On Wed, Oct 4, 2017 at 4:25 PM, Jakub Kicinski wrote:
>> > On Wed, 4 Oct 2017 16:16:49 -0700, Matthias Kaehlcke wrote:
>> >> > > Thanks for the suggestion. This seems a viable alternative if David
>> >> > > and the NFP owners can live without the extra checking provided by
>> >> > > __BF_FIELD_CHECK.
>> >> >
>> >> > The reason the __BF_FIELD_CHECK refuses to compile non-constant masks
>> >> > is that it will require runtime ffs on the mask, which is potentially
>> >> > costly. I would also feel quite stupid adding those macros to the nfp
>> >> > driver, given that I specifically created the bitfield.h header to not
>> >> > have to reimplement these in every driver I write/maintain.
>> >>
>> >> That make sense, thanks for providing more context.
>> >>
>> >> > Can you please test the patch I provided in the other reply?
>> >>
>> >> With this patch there are no errors when building the kernel with
>> >> clang.
>> >
>> > Cool, thanks for checking! I will run it through full tests and queue
>> > for upstreaming :)
>>
>> Just to let you know, using __BF_FIELD_CHECK macro will not Link with
>> -O0 (GCC or Clang) since references to __compiletime_assert_xxx will
>> not be cleaned up.
>
> Do you mean the current nfp_eth_set_bit_config() will not work with -O0
> on either complier, or any use of __BF_FIELD_CHECK() will not compile
> with -O0?
Any use of __BF_FIELD_CHECK. The code will compile but not link since
calls to ____compiletime_assert_xxx (added by compiletime_assert
macro) will not be removed in -O0.
Thanks,
Manoj
^ permalink raw reply
* Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers
From: Junio C Hamano @ 2017-10-05 1:49 UTC (permalink / raw)
To: Taylor Blau; +Cc: Jonathan Nieder, git, peff
In-Reply-To: <20171003033726.GA84817@D-10-157-251-166.dhcp4.washington.edu>
Taylor Blau <me@ttaylorr.com> writes:
> On Tue, Oct 03, 2017 at 08:55:01AM +0900, Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>> > The above does a nice job of explaining
>> >
>> > - what this change is going to do
>> > - how it's good for the internal code structure / maintainability
>> >
>> > What it doesn't tell me about is why the user-facing effect won't
>> > cause problems. Is there no atom where %(atom:) was previously
>> > accepted and did something meaningful that this may break?
This loose end needs to be tied.
I replaced "let's assume that doing this change is OK" from the
original log message with something a bit stronger, as with this
change, we are saying that it is forbidden to treat %(atom) and
%(atom:) differently. I also recorded the result of due-diligence
survey of the current code to suggest that the change would be OK
for current users.
-- >8 --
From: Taylor Blau <me@ttaylorr.com>
Date: Mon, 2 Oct 2017 09:10:34 -0700
Subject: [PATCH] ref-filter.c: pass empty-string as NULL to atom parsers
Peff points out that different atom parsers handle the empty
"sub-argument" list differently. An example of this is the format
"%(refname:)".
Since callers often use `string_list_split` (which splits the empty
string with any delimiter as a 1-ary string_list containing the empty
string), this makes handling empty sub-argument strings non-ergonomic.
Let's fix this by declaring that atom parser implementations must
not care about distinguishing between the empty string "%(refname:)"
and no sub-arguments "%(refname)". Current code aborts, either with
"unrecognised arg" (e.g. "refname:") or "does not take args"
(e.g. "body:") as an error message.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
ref-filter.c | 10 +++++++++-
t/t6300-for-each-ref.sh | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/ref-filter.c b/ref-filter.c
index bc591f4f3d..f3e53d4448 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -415,8 +415,16 @@ static int parse_ref_filter_atom(const struct ref_format *format,
REALLOC_ARRAY(used_atom, used_atom_cnt);
used_atom[at].name = xmemdupz(atom, ep - atom);
used_atom[at].type = valid_atom[i].cmp_type;
- if (arg)
+ if (arg) {
arg = used_atom[at].name + (arg - atom) + 1;
+ if (!*arg) {
+ /*
+ * Treat empty sub-arguments list as NULL (i.e.,
+ * "%(atom:)" is equivalent to "%(atom)").
+ */
+ arg = NULL;
+ }
+ }
memset(&used_atom[at].u, 0, sizeof(used_atom[at].u));
if (valid_atom[i].parser)
valid_atom[i].parser(format, &used_atom[at], arg);
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 2274a4b733..edc1bd8eab 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -51,6 +51,7 @@ test_atom() {
}
test_atom head refname refs/heads/master
+test_atom head refname: refs/heads/master
test_atom head refname:short master
test_atom head refname:lstrip=1 heads/master
test_atom head refname:lstrip=2 master
--
2.14.2-921-g20a440a8ba
^ permalink raw reply related
* Re: local fetcher and devtool don't work well together
From: Paul Eggleton @ 2017-10-05 1:47 UTC (permalink / raw)
To: Aaron_Wright; +Cc: yocto
In-Reply-To: <OFAC655E34.B4B3A1E0-ON882581AF.007C1B86-882581AF.007DD7C9@selinc.com>
Hi Aaron,
On Thursday, 5 October 2017 11:54:32 AM NZDT Aaron_Wright@selinc.com wrote:
> I have a recipe with:
>
> SRC_URI = "file://a/b/c/d;subdir=src"
> S = "${WORKDIR}/src/a/b/c/d"
>
> First off, ${S} must be set to the full path because the basepath uri
> parameter[1] doesn't work. So this doesn't work:
>
> SRC_URI = "file://a/b/c/d;subdir=src;basepath=a/b/c/d"
> S = "${WORKDIR}/src"
>
> I wish it would, but that's ok. I can deal with the long ${S} path as it
> compiles and works fine with bitbake.
My question would be what are you trying to achieve here? Should you be using
the externalsrc class perhaps?
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source
> However, it doesn't work with
> devtool:
>
> $ devtool modify -n d ~/mysrc/a/b/c/d
> NOTE: Creating workspace layer in <... snip
> ...>/yocto/poky/build/workspace
> NOTE: Enabling workspace layer in bblayers.conf
> Parsing recipes..done.
> NOTE: Recipe d now set up to build from ~/mysrc/a/b/c/d/b/c/d
>
> Where is the extra 'b/c/d' coming from in where it will be built from?
> This directory is reflected in the bbappends created the workspace:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> FILESPATH_prepend := "~/mysrc/a/b/c/d/b/c/d/oe-local-files:"
>
> Is it possible to have a ${S} of "${WORKDIR}/src" in this situation?
> How can I get devtool to behave and not duplicate the path?
The ~ shouldn't be in the value of FILESPATH, it ought to be expanded, so
that's something we need to fix. With regard to the path doubling of the
subdirectories, it's assuming that because you have that subdirectory path in
S then you need that underneath the specified source directory (since that is
usually true if you were for example pointing to a checkout of a git
repository, or an extracted source tarball).
devtool hasn't been written to handle this usage (which is unusual - typically
the recipe is pointing at remote source). It would be good to get an
understanding of your use case here so we can figure out where to go from
here.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: Line ending normalization doesn't work as expected
From: Jonathan Nieder @ 2017-10-05 1:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Dailey, Torsten Bögershausen, Git
In-Reply-To: <xmqqbmlm9y94.fsf@gitster.mtv.corp.google.com>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> git checkout --renormalize .
>> git status; # Show files that will be normalized
>> git commit; # Commit the result
>>
>> What do you think? Would you be interested in writing a patch for it?
>> ("No" is as always an acceptable answer.)
>
> I actually think what is being requested is the opposite, i.e. "the
> object registered in the index have wrong line endings, and the
> safe-crlf is getting in the way to prevent me from correcting by
> hashing the working tree contents again to register contents with
> corrected line endings, even with 'git add .'".
>
> So I would understand if your suggestion were for
>
> git checkin --renormalize .
>
> but not "git checkout". And it probably is more familiar to lay
> people if we spelled that as "git add --renormalize ." ;-)
Good catch. You understood correctly --- "git add --renormalize" is
the feature that I think is being hinted at here.
Thanks,
Jonathan
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 0/4] blockjobs: add explicit job reaping
From: John Snow @ 2017-10-05 1:46 UTC (permalink / raw)
To: Kevin Wolf; +Cc: qemu-block, pkrempa, jtc, qemu-devel, Fam Zheng
In-Reply-To: <20171004182732.GE9801@localhost.localdomain>
"Oh boy, another email from John! I bet it's concisely worded."
Ha ha. I see my reputation precedes me.
"Holy crap dude, that's a lot of words you've typed down there!"
It's okay, skip to the "TLDR" for the conclusion I arrived at if you
don't care how I got there!
"Sigh, okay, John."
Yes!!
On 10/04/2017 02:27 PM, Kevin Wolf wrote:
> Am 04.10.2017 um 03:52 hat John Snow geschrieben:
>> For jobs that complete when a monitor isn't looking, there's no way to
>> tell what the job's final return code was. We need to allow jobs to
>> remain in the list until queried for reliable management.
>
> Just a short summary of what I discussed with John on IRC:
>
> Another important reason why we want to have an explicit end of block
> jobs is that job completion often makes changes to the graph. For a
> management tool that manages the block graph on a node level, it is a
> big problem if graph changes can happen at any point that can lead to
> bad race conditions. Giving the management tool control over the end of
> the block job makes it aware that graph changes happen.
>
> This means that compared to this RFC series, we need to move the waiting
> earlier in the process:
>
> 1. Block job is done and calls block_job_completed()
> 2. Wait for other block jobs in the same job transaction to complete
> 3. Send a (new) QMP event to the management tool to notify it that the
> job is ready to be reaped
Oh, I suppose to distinguish it from "COMPLETED" in that sense, because
it isn't actually COMPLETED anymore under your vision, so it requires a
new event in this proposal.
This becomes a bit messy, bumping up against both "READY" and a
transactional pre-completed state semantically. Uhhhh, for lack of a
better word in the timeframe I'd like to complete this email in, let's
call this new theoretical state "PENDING"?
So presently, a job goes through the following life cycle:
1. CREATED --> RUNNING
2. RUNNING <--> PAUSED
3. RUNNING --> (READY | COMPLETED | CANCELED)
4. READY --> (COMPLETED | CANCELED)
5. (COMPLETED | CANCELED) --> NULL
Where we emit an event upon entering "READY", "COMPLETED" or "CANCELED".
My patchset here effectively adds a new optional terminal state:
5. (COMPLETED | CANCELED) --> (NULL | FINISHED)
6. FINISHED --> NULL
Where the last transition from FINISHED to NULL is performed via
block-job-reap, but notably we get to re-use the events for COMPLETED |
CANCELED to indicate the availability of this operation to be performed.
What happens in the case of transactionally managed jobs presently is
that jobs get stuck as they enter the COMPLETED|CANCELED state. If you
were to query them they behave as if they're RUNNING. There's no
discrete state that exists for this presently.
You can cancel these as normal, but I'm not sure if you can pause them,
actually. (Note to self, test that.) I think they have almost exactly
like any RUNNING job would.
What you're proposing here is the formalization of the pre-completion
state ("PENDING") and that in this state, a job outside of a transaction
can exist until it is manually told to finally, once and for all,
actually finish its business. We can use this as a hook to perform and
last graph changes so they will not come as a surprise to the management
application. Maybe this operation should be called "Finalize". Again,
for lack of a better term in the timeframe, I'll refer to it as such for
now.
I think importantly this actually distinguishes it from "reap" in that
the commit phase can still fail, so we can't let the job follow that
auto transition back to the NULL state. That means that we'd need both a
block-job-finalize AND a block-job-reap to accomplish both of the
following goals:
(1) Allow the management application to control graph changes [libvirt]
(2) Prevent auto transitions to NULL state for asynchronous clients [A
requirement mentioned by Virtuozzo]
It looks like this, overall:
1. CREATED --> RUNNING
2. RUNNING <--> PAUSED
3. RUNNING --> PENDING
via: auto transition
event: BLOCK_JOB_PENDING
4. PENDING --> (COMPLETED | CANCELED)
via: block-job-finalize
event: (COMPLETED | ERROR)
5. (COMPLETED | CANCELED) --> (NULL | FINISHED)
via: auto transition
event: none
6. FINISHED --> NULL
via: block-job-reap
event: none
"Hey, wait, where did the ready state go?"
Good question, I'm not sure how it fits in to something like "PENDING"
which is, I think NEARLY equivalent to a proposed pending->finalized
transition. Is it meaningful to have a job go from
running->ready->pending or running->pending->ready? I actually doubt it is.
The only difference really is that not all jobs use the READY -->
COMPLETE transition. We could implement it into those jobs if the job is
created with some kind of boolean, like
auto-complete: true/false
where this defaults to true, the legacy behavior.
For "mirror" we would just omit allowing people to set this setting
(auto-complete is effectively always off) because it is requisite and
essential to the operation of the job.
"OK, maybe that could work; what about transactions?"
Transactions have to be a bit of their own case, I think.
Essentially jobs that transactionally complete already hang around in
pending until all jobs complete, so they can do so together.
What we don't really want is to force users to have to dig into the jobs
manually and complete each one individually. (I think...?) or have to
deal with the managerial nightmare of having some autocomplete, some
that don't, etc.
What I propose for transactions is:
1) Add a new property for transactions also named "auto-complete"
2) If the property is set to false, Jobs in this transaction will have
their auto-complete values forcibly set to false
3) Once all jobs in the transaction are set to pending, emit an event
("TRANSACTION_READY", for instance)
4) Allow the transaction to be manually committed.
The alternative is to leave it on a per-job basis and just stipulate
that any bizarre or inconvenient configurations are the fault of the
caller. Leaving transactions completely untouched should theoretically work.
> 4. On block-job-reap, call the .commit/.abort callbacks of the jobs in
> the transaction. They will do most of the work that is currently done
> in the completion callbacks, in particular any graph changes. If we
> need to allow error cases, we can add a .prepare_completion callback
> that can still let the whole transaction fail.
Makes sense by analogy. Probably worth having anyway. I moved some
likely-to-deadlock code from the backup cleanup into .commit even when
it runs outside of transactions. Other jobs can likely benefit from some
simplified assumptions by running in that context, too.
> 5. Send the final QMP completion event for each job in the transaction
> with the final error code. This is the existing BLOCK_JOB_COMPLETED
> or BLOCK_JOB_CANCELLED event.
>
> The current RFC still executes .commit/.abort before block-job-reap, so
> the graph changes happen too early to be under control of the management
> tool.
>
>> RFC:
>> The next version will add tests for transactions.
>> Kevin, can you please take a look at bdrv_is_root_node and how it is
>> used with respect to do_drive_backup? I suspect that in this case that
>> "is root" should actually be "true", but a node in use by a job has
>> two roles; child_root and child_job, so it starts returning false here.
>>
>> That's fine because we prevent a collision that way, but it makes the
>> error messages pretty bad and misleading. Do you have a quick suggestion?
>> (Should I just amend the loop to allow non-root nodes as long as they
>> happen to be jobs so that the job creation code can check permissions?)
>
> We kind of sidestepped this problem by deciding that there is no real
> reason for the backup job to require the source to be a root node.
>
> I'm not completely sure how we could easily get a better message while
> still requiring a root node (and I suppose there are other places that
> rightfully still require a root node). Ignoring children with child_job
> feels ugly, but might be the best option.
>
> Note that this will not make the conflicting command work suddenly,
> because every node that has a child_job parent also has op blockers for
> everything, but the error message should be less confusing than "is not
> a root node".
>
> Kevin
>
TLDR:
- I think we may need to have optional manual completion steps both
before and after the job .prepare()/.commit()/.abort() phase.
- Before, like "block-job-complete" to allow graph changes to be under
management tool control, and
- After, so that final job success status can be queried even if the
event was missed.
Proposal:
(1) Extend block-job-complete semantics to all jobs that opt in via
"auto-complete: false" which is not allowed to be set for mirror jobs
(2) If the modern overloading of the BLOCK_JOB_READY event is apt to
cause confusion for existing tools, a new event BLOCK_JOB_PENDING could
be emitted instead for any job capable of accepting the
auto-complete=true/false parameter and emit it upon reaching this state.
(3) Continue forward with this patchset's current persistent/reap
nomenclature to prevent automatic cleanup if desired, and
(4) Implement transaction-wide settings for auto-complete alongside a
new "transaction complete" event to allow for a transaction-wide
"complete" command.
Hopefully that's not too braindead.
--js
^ permalink raw reply
* Re: [PATCH v2 0/2] kbuild: Cache exploratory calls to the compiler
From: Guenter Roeck @ 2017-10-05 1:46 UTC (permalink / raw)
To: Douglas Anderson
Cc: Masahiro Yamada, Michal Marek, Guenter Roeck, sjg, Brian Norris,
Marcin Nowakowski, Matthias Kaehlcke, Cao jin, Arnd Bergmann,
Mark Charlebois, Linux Kbuild mailing list, linux-doc,
Jonathan Corbet, linux-kernel, James Hogan, Josh Poimboeuf,
Ingo Molnar
In-Reply-To: <20171004223717.3010-1-dianders@chromium.org>
On Wed, Oct 4, 2017 at 3:37 PM, Douglas Anderson <dianders@chromium.org> wrote:
> This two-patch series attempts to speed incremental builds of the
> kernel up by a bit. How much of a speedup you get depends a lot on
> your environment, specifically the speed of your workstation and how
> fast it takes to invoke the compiler.
>
> In the Chrome OS build environment you get a really big win. For an
> incremental build (via emerge) I measured a speedup from ~1 minute to
> ~35 seconds. ...but Chrome OS calls the compiler through a number of
> wrapper scripts and also calls the kernel make at least twice for an
> emerge (during compile stage and install stage), so it's a bit of a
> worst case.
>
> Perhaps a more realistic measure of the speedup others might see is
> running "time make help > /dev/null" outside of the Chrome OS build
> environment on my system. When I do this I see that it took more than
> 1.0 seconds before and less than 0.2 seconds after. So presumably
> this has the ability to shave ~0.8 seconds off an incremental build
> for most folks out there. While 0.8 seconds savings isn't huge, it
> does make incremental builds feel a lot snappier.
>
> Caveats from v1 still copied here, though with Masahiro Yamada's
> suggestions from v1 this is starting to feel a little more baked and
> I've even dropped the RFC from it (though extra testing still
> appreciated):
>
> Please note that I make no illusions of being a Makefile expert nor do
> I have any belief that I fully understand the Linux kernel build
> system. Please take this patch series as the start of a discussion
> about whether others feel like this type of speedup is worthwhile and
> how to best accomplish it. Specific things to note:
>
> - I'm happy to paint the bikeshed any color that maintainers want. If
> you'd like the cache named differently, in a slightly different
> format, or you want me to adjust the spacing / names of Makefile
> stuff then please just let me know.
>
> - If this is totally the wrong approach and you have a better idea
> then let me know. If you want something that's super complicated to
> explain then feel free to post a replacement patch and I'm happy to
> test.
>
> - This patch definitely needs extra testing. I've tested it on a very
> limited build environment and it seems to be working fine, but I
> could believe that with some weird compiler options or on certain
> architectures you might need some extra escaping here and there.
>
Not being a makefile expert, I can't say anything about the merits of
this series. However, it does pass a run on my test farm at
kerneltests.org. So. I'll give it a
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
> Changes in v2:
> - Abstract at a different level (like shell-cached) per Masahiro Yamada
> - Include ld-version, which I missed the first time
>
> Douglas Anderson (2):
> kbuild: Add a cache for generated variables
> kbuild: Cache a few more calls to the compiler
>
> Documentation/kbuild/makefiles.txt | 21 +++++++++
> Makefile | 4 +-
> scripts/Kbuild.include | 90 ++++++++++++++++++++++++++++++++------
> 3 files changed, 99 insertions(+), 16 deletions(-)
>
> --
> 2.14.2.920.gcf0c67979c-goog
>
^ 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.