* Re: S variable for svn fetcher Was: State of OE world - 2020-02-18
From: Adrian Bunk @ 2020-02-20 16:11 UTC (permalink / raw)
To: Martin Jansa; +Cc: openembeded-devel
In-Reply-To: <20200220153758.o25tn46hhewgmasd@jama>
On Thu, Feb 20, 2020 at 04:37:58PM +0100, Martin Jansa wrote:
> On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
> > On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
> > >...
> > > Any idea why these aren't shown in our build?
> > >...
> >
> > What is your mirror configuration?
> >
> > Default configuration downloads the tarball from [1].
>
> Maybe I'm missing your point, but these aren't fetch issues.
>...
MIRRORS = "" (and deleting the downloaded tar) is what I needed for
getting a build failure.
> Cheers,
cu
Adrian
^ permalink raw reply
* [Intel-gfx] [PATCH v2] drm/i915: Use intel_plane_data_rate for min_cdclk calculation
From: Stanislav Lisovskiy @ 2020-02-20 16:08 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate and which is also used in bandwidth
calculations. However for calculating min_cdclk we have another
piece of code, doing almost same calculation, but a bit differently
and in a different place. However as both are actually part of same
formula, probably would be wise to use plane data rate calculations
as a basis anyway, thus avoiding code duplication and possible bugs
related to this.
Another thing is that I've noticed that during min_cdclk calculations
we account for plane scaling, while for plane data rate, we don't.
crtc->pixel_rate seems to account only for pipe ratio, however it is
clearly stated in BSpec that plane data rate also need to account
plane ratio as well.
So what this commit does is:
- Adds a plane ratio calculation to intel_plane_data_rate
- Removes redundant calculations from skl_plane_min_cdclk which is
used for gen9+ and now uses intel_plane_data_rate as a basis from
there as well.
v2: - Don't use 64 division if not needed(Ville Syrjälä)
- Now use intel_plane_pixel_rate as a basis for calculations both
at intel_plane_data_rate and skl_plane_min_cdclk(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 22 +++++++++++++++-
.../gpu/drm/i915/display/intel_atomic_plane.h | 3 +++
drivers/gpu/drm/i915/display/intel_sprite.c | 26 +++++++------------
3 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index c86d7a35c816..3bd7ea9bf1b4 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -133,11 +133,31 @@ intel_plane_destroy_state(struct drm_plane *plane,
kfree(plane_state);
}
+unsigned int intel_plane_pixel_rate(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
+{
+ unsigned int src_w, src_h, dst_w, dst_h;
+
+ src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
+ src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
+ dst_w = drm_rect_width(&plane_state->uapi.dst);
+ dst_h = drm_rect_height(&plane_state->uapi.dst);
+
+ /* Downscaling limits the maximum pixel rate */
+ dst_w = min(src_w, dst_w);
+ dst_h = min(src_h, dst_h);
+
+ return DIV_ROUND_UP(mul_u32_u32(crtc_state->pixel_rate,
+ src_w * src_h),
+ mul_u32_u32(dst_w, dst_h));
+}
+
unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int cpp;
+ unsigned int plane_pixel_rate = intel_plane_pixel_rate(crtc_state, plane_state);
if (!plane_state->uapi.visible)
return 0;
@@ -153,7 +173,7 @@ unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
if (fb->format->is_yuv && fb->format->num_planes > 1)
cpp *= 4;
- return cpp * crtc_state->pixel_rate;
+ return mul_u32_u32(plane_pixel_rate, cpp);
}
int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 2bcf15e34728..a6bbf42bae1f 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -18,6 +18,9 @@ struct intel_plane_state;
extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
+unsigned int intel_plane_pixel_rate(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state);
+
unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state);
void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state *plane_state,
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c
index 7abeefe8dce5..4fa3081e2074 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -330,9 +330,9 @@ bool icl_is_hdr_plane(struct drm_i915_private *dev_priv, enum plane_id plane_id)
}
static void
-skl_plane_ratio(const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state,
- unsigned int *num, unsigned int *den)
+skl_plane_bpp_constraints(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state,
+ unsigned int *num, unsigned int *den)
{
struct drm_i915_private *dev_priv = to_i915(plane_state->uapi.plane->dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
@@ -355,27 +355,19 @@ static int skl_plane_min_cdclk(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(plane_state->uapi.plane->dev);
- unsigned int pixel_rate = crtc_state->pixel_rate;
- unsigned int src_w, src_h, dst_w, dst_h;
unsigned int num, den;
+ int plane_pixel_rate = intel_plane_pixel_rate(crtc_state, plane_state);
- skl_plane_ratio(crtc_state, plane_state, &num, &den);
+ skl_plane_bpp_constraints(crtc_state, plane_state, &num, &den);
/* two pixels per clock on glk+ */
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
den *= 2;
- src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
- src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
- dst_w = drm_rect_width(&plane_state->uapi.dst);
- dst_h = drm_rect_height(&plane_state->uapi.dst);
-
- /* Downscaling limits the maximum pixel rate */
- dst_w = min(src_w, dst_w);
- dst_h = min(src_h, dst_h);
-
- return DIV64_U64_ROUND_UP(mul_u32_u32(pixel_rate * num, src_w * src_h),
- mul_u32_u32(den, dst_w * dst_h));
+ /*
+ * Plane pixel rate is a pipe pixel rate * plane ratio * pipe ratio
+ */
+ return DIV64_U64_ROUND_UP(plane_pixel_rate * num, den);
}
static unsigned int
--
2.24.1.485.gad05a3d8e5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PULL 08/18] block/backup-top: fix flags handling
From: Max Reitz @ 2020-02-20 16:07 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
backup-top "supports" write-unchanged, by skipping CBW operation in
backup_top_co_pwritev. But it forgets to do the same in
backup_top_co_pwrite_zeroes, as well as declare support for
BDRV_REQ_WRITE_UNCHANGED.
Fix this, and, while being here, declare also support for flags
supported by source child.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200207161231.32707-1-vsementsov@virtuozzo.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
block/backup-top.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/block/backup-top.c b/block/backup-top.c
index fa78f3256d..1bfb360bd3 100644
--- a/block/backup-top.c
+++ b/block/backup-top.c
@@ -48,11 +48,17 @@ static coroutine_fn int backup_top_co_preadv(
}
static coroutine_fn int backup_top_cbw(BlockDriverState *bs, uint64_t offset,
- uint64_t bytes)
+ uint64_t bytes, BdrvRequestFlags flags)
{
BDRVBackupTopState *s = bs->opaque;
- uint64_t end = QEMU_ALIGN_UP(offset + bytes, s->bcs->cluster_size);
- uint64_t off = QEMU_ALIGN_DOWN(offset, s->bcs->cluster_size);
+ uint64_t off, end;
+
+ if (flags & BDRV_REQ_WRITE_UNCHANGED) {
+ return 0;
+ }
+
+ off = QEMU_ALIGN_DOWN(offset, s->bcs->cluster_size);
+ end = QEMU_ALIGN_UP(offset + bytes, s->bcs->cluster_size);
return block_copy(s->bcs, off, end - off, NULL);
}
@@ -60,7 +66,7 @@ static coroutine_fn int backup_top_cbw(BlockDriverState *bs, uint64_t offset,
static int coroutine_fn backup_top_co_pdiscard(BlockDriverState *bs,
int64_t offset, int bytes)
{
- int ret = backup_top_cbw(bs, offset, bytes);
+ int ret = backup_top_cbw(bs, offset, bytes, 0);
if (ret < 0) {
return ret;
}
@@ -71,7 +77,7 @@ static int coroutine_fn backup_top_co_pdiscard(BlockDriverState *bs,
static int coroutine_fn backup_top_co_pwrite_zeroes(BlockDriverState *bs,
int64_t offset, int bytes, BdrvRequestFlags flags)
{
- int ret = backup_top_cbw(bs, offset, bytes);
+ int ret = backup_top_cbw(bs, offset, bytes, flags);
if (ret < 0) {
return ret;
}
@@ -84,11 +90,9 @@ static coroutine_fn int backup_top_co_pwritev(BlockDriverState *bs,
uint64_t bytes,
QEMUIOVector *qiov, int flags)
{
- if (!(flags & BDRV_REQ_WRITE_UNCHANGED)) {
- int ret = backup_top_cbw(bs, offset, bytes);
- if (ret < 0) {
- return ret;
- }
+ int ret = backup_top_cbw(bs, offset, bytes, flags);
+ if (ret < 0) {
+ return ret;
}
return bdrv_co_pwritev(bs->backing, offset, bytes, qiov, flags);
@@ -196,8 +200,13 @@ BlockDriverState *bdrv_backup_top_append(BlockDriverState *source,
return NULL;
}
- top->total_sectors = source->total_sectors;
state = top->opaque;
+ top->total_sectors = source->total_sectors;
+ top->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED |
+ (BDRV_REQ_FUA & source->supported_write_flags);
+ top->supported_zero_flags = BDRV_REQ_WRITE_UNCHANGED |
+ ((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK) &
+ source->supported_zero_flags);
bdrv_ref(target);
state->target = bdrv_attach_child(top, target, "target", &child_file, errp);
--
2.24.1
^ permalink raw reply related
* [PULL 07/18] block: always fill entire LUKS header space with zeros
From: Max Reitz @ 2020-02-20 16:06 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
From: Daniel P. Berrangé <berrange@redhat.com>
When initializing the LUKS header the size with default encryption
parameters will currently be 2068480 bytes. This is rounded up to
a multiple of the cluster size, 2081792, with 64k sectors. If the
end of the header is not the same as the end of the cluster we fill
the extra space with zeros. This was forgetting that not even the
space allocated for the header will be fully initialized, as we
only write key material for the first key slot. The space left
for the other 7 slots is never written to.
An optimization to the ref count checking code:
commit a5fff8d4b4d928311a5005efa12d0991fe3b66f9 (refs/bisect/bad)
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: Wed Feb 27 16:14:30 2019 +0300
qcow2-refcount: avoid eating RAM
made the assumption that every cluster which was allocated would
have at least some data written to it. This was violated by way
the LUKS header is only partially written, with much space simply
reserved for future use.
Depending on the cluster size this problem was masked by the
logic which wrote zeros between the end of the LUKS header and
the end of the cluster.
$ qemu-img create --object secret,id=cluster_encrypt0,data=123456 \
-f qcow2 -o cluster_size=2k,encrypt.iter-time=1,\
encrypt.format=luks,encrypt.key-secret=cluster_encrypt0 \
cluster_size_check.qcow2 100M
Formatting 'cluster_size_check.qcow2', fmt=qcow2 size=104857600
encrypt.format=luks encrypt.key-secret=cluster_encrypt0
encrypt.iter-time=1 cluster_size=2048 lazy_refcounts=off refcount_bits=16
$ qemu-img check --object secret,id=cluster_encrypt0,data=redhat \
'json:{"driver": "qcow2", "encrypt.format": "luks", \
"encrypt.key-secret": "cluster_encrypt0", \
"file.driver": "file", "file.filename": "cluster_size_check.qcow2"}'
ERROR: counting reference for region exceeding the end of the file by one cluster or more: offset 0x2000 size 0x1f9000
Leaked cluster 4 refcount=1 reference=0
...snip...
Leaked cluster 130 refcount=1 reference=0
1 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.
127 leaked clusters were found on the image.
This means waste of disk space, but no harm to data.
Image end offset: 268288
The problem only exists when the disk image is entirely empty. Writing
data to the disk image payload will solve the problem by causing the
end of the file to be extended further.
The change fixes it by ensuring that the entire allocated LUKS header
region is fully initialized with zeros. The qemu-img check will still
fail for any pre-existing disk images created prior to this change,
unless at least 1 byte of the payload is written to.
Fully writing zeros to the entire LUKS header is a good idea regardless
as it ensures that space has been allocated on the host filesystem (or
whatever block storage backend is used).
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200207135520.2669430-1-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
block/qcow2.c | 11 +++--
tests/qemu-iotests/284 | 97 ++++++++++++++++++++++++++++++++++++++
tests/qemu-iotests/284.out | 62 ++++++++++++++++++++++++
tests/qemu-iotests/group | 1 +
4 files changed, 167 insertions(+), 4 deletions(-)
create mode 100755 tests/qemu-iotests/284
create mode 100644 tests/qemu-iotests/284.out
diff --git a/block/qcow2.c b/block/qcow2.c
index 8dcee5efec..3c754f616b 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -135,13 +135,16 @@ static ssize_t qcow2_crypto_hdr_init_func(QCryptoBlock *block, size_t headerlen,
s->crypto_header.length = headerlen;
s->crypto_header.offset = ret;
- /* Zero fill remaining space in cluster so it has predictable
- * content in case of future spec changes */
+ /*
+ * Zero fill all space in cluster so it has predictable
+ * content, as we may not initialize some regions of the
+ * header (eg only 1 out of 8 key slots will be initialized)
+ */
clusterlen = size_to_clusters(s, headerlen) * s->cluster_size;
assert(qcow2_pre_write_overlap_check(bs, 0, ret, clusterlen, false) == 0);
ret = bdrv_pwrite_zeroes(bs->file,
- ret + headerlen,
- clusterlen - headerlen, 0);
+ ret,
+ clusterlen, 0);
if (ret < 0) {
error_setg_errno(errp, -ret, "Could not zero fill encryption header");
return -1;
diff --git a/tests/qemu-iotests/284 b/tests/qemu-iotests/284
new file mode 100755
index 0000000000..071e89b33e
--- /dev/null
+++ b/tests/qemu-iotests/284
@@ -0,0 +1,97 @@
+#!/usr/bin/env bash
+#
+# Test ref count checks on encrypted images
+#
+# Copyright (C) 2019 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+
+# creator
+owner=berrange@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1 # failure is the default!
+
+_cleanup()
+{
+ _cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt qcow2
+_supported_proto generic
+_supported_os Linux
+
+
+size=1M
+
+SECRET="secret,id=sec0,data=astrochicken"
+
+IMGSPEC="driver=$IMGFMT,file.filename=$TEST_IMG,encrypt.key-secret=sec0"
+QEMU_IO_OPTIONS=$QEMU_IO_OPTIONS_NO_FMT
+
+_run_test()
+{
+ IMGOPTSSYNTAX=true
+ OLD_TEST_IMG="$TEST_IMG"
+ TEST_IMG="driver=$IMGFMT,file.filename=$TEST_IMG,encrypt.key-secret=sec0"
+ QEMU_IMG_EXTRA_ARGS="--image-opts --object $SECRET"
+
+ echo
+ echo "== cluster size $csize"
+ echo "== checking image refcounts =="
+ _check_test_img
+
+ echo
+ echo "== writing some data =="
+ $QEMU_IO -c "write -P 0x9 0 1" $QEMU_IMG_EXTRA_ARGS $TEST_IMG | _filter_qemu_io | _filter_testdir
+ echo
+ echo "== rechecking image refcounts =="
+ _check_test_img
+
+ echo
+ echo "== writing some more data =="
+ $QEMU_IO -c "write -P 0x9 $csize 1" $QEMU_IMG_EXTRA_ARGS $TEST_IMG | _filter_qemu_io | _filter_testdir
+ echo
+ echo "== rechecking image refcounts =="
+ _check_test_img
+
+ TEST_IMG="$OLD_TEST_IMG"
+ QEMU_IMG_EXTRA_ARGS=
+ IMGOPTSSYNTAX=
+}
+
+
+echo
+echo "testing LUKS qcow2 encryption"
+echo
+
+for csize in 512 2048 32768
+do
+ _make_test_img --object $SECRET -o "encrypt.format=luks,encrypt.key-secret=sec0,encrypt.iter-time=10,cluster_size=$csize" $size
+ _run_test
+ _cleanup_test_img
+done
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/284.out b/tests/qemu-iotests/284.out
new file mode 100644
index 0000000000..48216f5742
--- /dev/null
+++ b/tests/qemu-iotests/284.out
@@ -0,0 +1,62 @@
+QA output created by 284
+
+testing LUKS qcow2 encryption
+
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10
+
+== cluster size 512
+== checking image refcounts ==
+No errors were found on the image.
+
+== writing some data ==
+wrote 1/1 bytes at offset 0
+1 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+== rechecking image refcounts ==
+No errors were found on the image.
+
+== writing some more data ==
+wrote 1/1 bytes at offset 512
+1 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+== rechecking image refcounts ==
+No errors were found on the image.
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10
+
+== cluster size 2048
+== checking image refcounts ==
+No errors were found on the image.
+
+== writing some data ==
+wrote 1/1 bytes at offset 0
+1 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+== rechecking image refcounts ==
+No errors were found on the image.
+
+== writing some more data ==
+wrote 1/1 bytes at offset 2048
+1 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+== rechecking image refcounts ==
+No errors were found on the image.
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10
+
+== cluster size 32768
+== checking image refcounts ==
+No errors were found on the image.
+
+== writing some data ==
+wrote 1/1 bytes at offset 0
+1 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+== rechecking image refcounts ==
+No errors were found on the image.
+
+== writing some more data ==
+wrote 1/1 bytes at offset 32768
+1 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+== rechecking image refcounts ==
+No errors were found on the image.
+*** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 1904223020..818380a8f0 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -290,3 +290,4 @@
280 rw migration quick
281 rw quick
283 auto quick
+284 rw
--
2.24.1
^ permalink raw reply related
* Re: [PATCH AUTOSEL 5.5 096/542] powerpc/powernv/ioda: Fix ref count for devices with their own PE
From: Sasha Levin @ 2020-02-20 16:12 UTC (permalink / raw)
To: Frederic Barrat
Cc: linux-kernel, stable, Andrew Donnellan, Michael Ellerman,
linuxppc-dev
In-Reply-To: <0867167a-73b8-0735-78ce-0d984f7a80b5@linux.ibm.com>
On Mon, Feb 17, 2020 at 09:49:41AM +0100, Frederic Barrat wrote:
>
>
>Le 14/02/2020 à 16:41, Sasha Levin a écrit :
>>From: Frederic Barrat <fbarrat@linux.ibm.com>
>>
>>[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
>
>
>Hi,
>
>Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 doesn't
>really need to go to stable (any of 4.19, 5.4 and 5.5). While it's
>probably safe, the patch replaces a refcount leak by another one,
>which makes sense as part of the full series merged in 5.6-rc1, but
>isn't terribly useful standalone on the current stable branches.
I'll drop it, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [RFC PATCH v3 04/27] qcow2: Add get_l2_entry() and set_l2_entry()
From: Alberto Garcia @ 2020-02-20 16:08 UTC (permalink / raw)
To: Eric Blake, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <aca66606-11df-56df-e20a-a966d9c151c3@redhat.com>
On Thu 20 Feb 2020 04:22:24 PM CET, Eric Blake wrote:
>> +++ b/block/qcow2.h
>
> scripts/git.orderfile can be used to hoist this part of the patch to
> the front of the message (as it is more valuable to review first).
I didn't know that git had this feature, thanks for the tip!
Berto
^ permalink raw reply
* [PATCH] firmware: imx: scu: Fix corruption of header
From: Leonard Crestez @ 2020-02-20 16:12 UTC (permalink / raw)
To: Shawn Guo
Cc: Dong Aisheng, Franck LENORMAND, linux-imx, kernel, Fabio Estevam,
linux-arm-kernel
From: Franck LENORMAND <franck.lenormand@nxp.com>
The header of the message to send can be changed if the
response is longer than the request:
- 1st word, the header is sent
- the remaining words of the message are sent
- the response is received asynchronously during the
execution of the loop, changing the size field in
the header
- the for loop test the termination condition using
the corrupted header
It is the case for the API build_info which has just a
header as request but 3 words in response.
This issue is fixed by storing the header locally instead of
using a pointer on it.
Fixes: edbee095fafb (firmware: imx: add SCU firmware driver support)
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
Cc: stable@vger.kernel.org
---
drivers/firmware/imx/imx-scu.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
This can manifest as random crashes so Cc: stable
diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index 03b43b7a6d1d..2cf09f8a075c 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -132,24 +132,24 @@ static void imx_scu_rx_callback(struct mbox_client *c, void *msg)
complete(&sc_ipc->done);
}
static int imx_scu_ipc_write(struct imx_sc_ipc *sc_ipc, void *msg)
{
- struct imx_sc_rpc_msg *hdr = msg;
+ struct imx_sc_rpc_msg hdr = *(struct imx_sc_rpc_msg *)msg;
struct imx_sc_chan *sc_chan;
u32 *data = msg;
int ret;
int i;
/* Check size */
- if (hdr->size > IMX_SC_RPC_MAX_MSG)
+ if (hdr.size > IMX_SC_RPC_MAX_MSG)
return -EINVAL;
- dev_dbg(sc_ipc->dev, "RPC SVC %u FUNC %u SIZE %u\n", hdr->svc,
- hdr->func, hdr->size);
+ dev_dbg(sc_ipc->dev, "RPC SVC %u FUNC %u SIZE %u\n", hdr.svc,
+ hdr.func, hdr.size);
- for (i = 0; i < hdr->size; i++) {
+ for (i = 0; i < hdr.size; i++) {
sc_chan = &sc_ipc->chans[i % 4];
ret = mbox_send_message(sc_chan->ch, &data[i]);
if (ret < 0)
return ret;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] [CIFS] Add missing mount option 'signloosely' to what is displayed in /proc/mounts
From: Aurélien Aptel @ 2020-02-20 16:12 UTC (permalink / raw)
To: Steve French, CIFS
In-Reply-To: <CAH2r5msy+zQCWdBARfdw5TTk1va3vXU9f3JcWmd_xgHASJj9jQ@mail.gmail.com>
Reviewed-by: Aurelien Aptel <aaptel@suse.com>
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
^ permalink raw reply
* Re: [PATCH 39/52] drm/stm: Drop explicit drm_mode_config_cleanup call
From: Daniel Vetter @ 2020-02-20 16:12 UTC (permalink / raw)
To: Philippe CORNU
Cc: Maxime Coquelin, Intel Graphics Development, DRI Development,
Yannick FERTRE, Daniel Vetter, Vincent ABRIOU,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Alexandre TORGUE
In-Reply-To: <30ed80c9-8b18-8e23-a26b-2c406d43c90d@st.com>
On Thu, Feb 20, 2020 at 3:19 PM Philippe CORNU <philippe.cornu@st.com> wrote:
>
> Hi Daniel,
>
> On 2/19/20 11:21 AM, Daniel Vetter wrote:
> > It's right above the drm_dev_put().
> >
> > Aside: Another driver with a bit much devm_kzalloc, which should
> > probably use drmm_kzalloc instead ...
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Yannick Fertre <yannick.fertre@st.com>
> > Cc: Philippe Cornu <philippe.cornu@st.com>
> > Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> > Cc: Vincent Abriou <vincent.abriou@st.com>
> > Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> > Cc: Alexandre Torgue <alexandre.torgue@st.com>
> > Cc: linux-stm32@st-md-mailman.stormreply.com
> > Cc: linux-arm-kernel@lists.infradead.org
> > ---
> > drivers/gpu/drm/stm/drv.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> > index ea9fcbdc68b3..5b374531dd8c 100644
> > --- a/drivers/gpu/drm/stm/drv.c
> > +++ b/drivers/gpu/drm/stm/drv.c
> > @@ -88,7 +88,9 @@ static int drv_load(struct drm_device *ddev)
> >
> > ddev->dev_private = (void *)ldev;
> >
> > - drm_mode_config_init(ddev);
> > + ret = drm_mode_config_init(ddev);
> > + if (ret)
> > + return ret;
> >
> > /*
> > * set max width and height as default value.
> > @@ -103,7 +105,7 @@ static int drv_load(struct drm_device *ddev)
> >
> > ret = ltdc_load(ddev);
> > if (ret)
> > - goto err;
> > + return ret;
> >
> > drm_mode_config_reset(ddev);
> > drm_kms_helper_poll_init(ddev);
> > @@ -111,9 +113,6 @@ static int drv_load(struct drm_device *ddev)
> > platform_set_drvdata(pdev, ddev);
> >
> > return 0;
> > -err:
> > - drm_mode_config_cleanup(ddev);
> > - return ret;
> > }
> >
> > static void drv_unload(struct drm_device *ddev)
> > @@ -122,7 +121,6 @@ static void drv_unload(struct drm_device *ddev)
> >
> > drm_kms_helper_poll_fini(ddev);
> > ltdc_unload(ddev);
> > - drm_mode_config_cleanup(ddev);
> > }
> >
> > static __maybe_unused int drv_suspend(struct device *dev)
> >
>
> Thank you for your patch,
> For this stm part,
> Acked-by: Philippe Cornu <philippe.cornu@st.com>
>
> note: we will handle devm_kzalloc() asap, thanks.
Note that as-is you can't just blindly switch devm_kzalloc over to
drmm_kzalloc for the structures containing a drm_* object, or you'll
just replace one type of use-after free with another one (and probably
worse, since the new one will hit you on normal driver unload too).
There's a bit more work needed in this area, this here is just the
first steps and a heads up. And removing the devm_kzalloc would result
in lots of code added for a bunch of kfree() all over, not so great
option either.
I'd say wait for the next round :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/2] virtio: let virtio use DMA API when guest RAM is protected
From: Christoph Hellwig @ 2020-02-20 16:13 UTC (permalink / raw)
To: Halil Pasic
Cc: Michael S. Tsirkin, Jason Wang, Marek Szyprowski, Robin Murphy,
Christoph Hellwig, linux-s390, virtualization, linux-kernel,
iommu, Christian Borntraeger, Janosch Frank, Viktor Mihajlovski,
Cornelia Huck, Ram Pai, Thiago Jung Bauermann, David Gibson,
Lendacky, Thomas, Michael Mueller
In-Reply-To: <20200220160606.53156-3-pasic@linux.ibm.com>
On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 867c7ebd3f10..fafc8f924955 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -243,6 +243,9 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
> if (!virtio_has_iommu_quirk(vdev))
> return true;
>
> + if (force_dma_unencrypted(&vdev->dev))
> + return true;
Hell no. This is a detail of the platform DMA direct implementation.
Drivers have no business looking at this flag, and virtio finally needs
to be fixed to use the DMA API properly for everything but legacy devices.
No amount of desparate hacks is going to fix that fundamental problem,
and I'm starting to get really sick and tired of all the crap patches
published in this area.
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 39/52] drm/stm: Drop explicit drm_mode_config_cleanup call
From: Daniel Vetter @ 2020-02-20 16:12 UTC (permalink / raw)
To: Philippe CORNU
Cc: Maxime Coquelin, Intel Graphics Development, DRI Development,
Yannick FERTRE, Benjamin Gaignard, Daniel Vetter, Vincent ABRIOU,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Alexandre TORGUE
In-Reply-To: <30ed80c9-8b18-8e23-a26b-2c406d43c90d@st.com>
On Thu, Feb 20, 2020 at 3:19 PM Philippe CORNU <philippe.cornu@st.com> wrote:
>
> Hi Daniel,
>
> On 2/19/20 11:21 AM, Daniel Vetter wrote:
> > It's right above the drm_dev_put().
> >
> > Aside: Another driver with a bit much devm_kzalloc, which should
> > probably use drmm_kzalloc instead ...
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Yannick Fertre <yannick.fertre@st.com>
> > Cc: Philippe Cornu <philippe.cornu@st.com>
> > Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> > Cc: Vincent Abriou <vincent.abriou@st.com>
> > Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> > Cc: Alexandre Torgue <alexandre.torgue@st.com>
> > Cc: linux-stm32@st-md-mailman.stormreply.com
> > Cc: linux-arm-kernel@lists.infradead.org
> > ---
> > drivers/gpu/drm/stm/drv.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> > index ea9fcbdc68b3..5b374531dd8c 100644
> > --- a/drivers/gpu/drm/stm/drv.c
> > +++ b/drivers/gpu/drm/stm/drv.c
> > @@ -88,7 +88,9 @@ static int drv_load(struct drm_device *ddev)
> >
> > ddev->dev_private = (void *)ldev;
> >
> > - drm_mode_config_init(ddev);
> > + ret = drm_mode_config_init(ddev);
> > + if (ret)
> > + return ret;
> >
> > /*
> > * set max width and height as default value.
> > @@ -103,7 +105,7 @@ static int drv_load(struct drm_device *ddev)
> >
> > ret = ltdc_load(ddev);
> > if (ret)
> > - goto err;
> > + return ret;
> >
> > drm_mode_config_reset(ddev);
> > drm_kms_helper_poll_init(ddev);
> > @@ -111,9 +113,6 @@ static int drv_load(struct drm_device *ddev)
> > platform_set_drvdata(pdev, ddev);
> >
> > return 0;
> > -err:
> > - drm_mode_config_cleanup(ddev);
> > - return ret;
> > }
> >
> > static void drv_unload(struct drm_device *ddev)
> > @@ -122,7 +121,6 @@ static void drv_unload(struct drm_device *ddev)
> >
> > drm_kms_helper_poll_fini(ddev);
> > ltdc_unload(ddev);
> > - drm_mode_config_cleanup(ddev);
> > }
> >
> > static __maybe_unused int drv_suspend(struct device *dev)
> >
>
> Thank you for your patch,
> For this stm part,
> Acked-by: Philippe Cornu <philippe.cornu@st.com>
>
> note: we will handle devm_kzalloc() asap, thanks.
Note that as-is you can't just blindly switch devm_kzalloc over to
drmm_kzalloc for the structures containing a drm_* object, or you'll
just replace one type of use-after free with another one (and probably
worse, since the new one will hit you on normal driver unload too).
There's a bit more work needed in this area, this here is just the
first steps and a heads up. And removing the devm_kzalloc would result
in lots of code added for a bunch of kfree() all over, not so great
option either.
I'd say wait for the next round :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 2/2] virtio: let virtio use DMA API when guest RAM is protected
From: Christoph Hellwig @ 2020-02-20 16:13 UTC (permalink / raw)
To: Halil Pasic
Cc: linux-s390, Janosch Frank, Michael S. Tsirkin, Jason Wang,
Cornelia Huck, Ram Pai, linux-kernel, virtualization,
Christian Borntraeger, iommu, David Gibson, Michael Mueller,
Lendacky, Thomas, Viktor Mihajlovski, Robin Murphy,
Christoph Hellwig
In-Reply-To: <20200220160606.53156-3-pasic@linux.ibm.com>
On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 867c7ebd3f10..fafc8f924955 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -243,6 +243,9 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
> if (!virtio_has_iommu_quirk(vdev))
> return true;
>
> + if (force_dma_unencrypted(&vdev->dev))
> + return true;
Hell no. This is a detail of the platform DMA direct implementation.
Drivers have no business looking at this flag, and virtio finally needs
to be fixed to use the DMA API properly for everything but legacy devices.
No amount of desparate hacks is going to fix that fundamental problem,
and I'm starting to get really sick and tired of all the crap patches
published in this area.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH 39/52] drm/stm: Drop explicit drm_mode_config_cleanup call
From: Daniel Vetter @ 2020-02-20 16:12 UTC (permalink / raw)
To: Philippe CORNU
Cc: Maxime Coquelin, Intel Graphics Development, DRI Development,
Yannick FERTRE, Benjamin Gaignard, Daniel Vetter, Vincent ABRIOU,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Alexandre TORGUE
In-Reply-To: <30ed80c9-8b18-8e23-a26b-2c406d43c90d@st.com>
On Thu, Feb 20, 2020 at 3:19 PM Philippe CORNU <philippe.cornu@st.com> wrote:
>
> Hi Daniel,
>
> On 2/19/20 11:21 AM, Daniel Vetter wrote:
> > It's right above the drm_dev_put().
> >
> > Aside: Another driver with a bit much devm_kzalloc, which should
> > probably use drmm_kzalloc instead ...
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Yannick Fertre <yannick.fertre@st.com>
> > Cc: Philippe Cornu <philippe.cornu@st.com>
> > Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> > Cc: Vincent Abriou <vincent.abriou@st.com>
> > Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> > Cc: Alexandre Torgue <alexandre.torgue@st.com>
> > Cc: linux-stm32@st-md-mailman.stormreply.com
> > Cc: linux-arm-kernel@lists.infradead.org
> > ---
> > drivers/gpu/drm/stm/drv.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> > index ea9fcbdc68b3..5b374531dd8c 100644
> > --- a/drivers/gpu/drm/stm/drv.c
> > +++ b/drivers/gpu/drm/stm/drv.c
> > @@ -88,7 +88,9 @@ static int drv_load(struct drm_device *ddev)
> >
> > ddev->dev_private = (void *)ldev;
> >
> > - drm_mode_config_init(ddev);
> > + ret = drm_mode_config_init(ddev);
> > + if (ret)
> > + return ret;
> >
> > /*
> > * set max width and height as default value.
> > @@ -103,7 +105,7 @@ static int drv_load(struct drm_device *ddev)
> >
> > ret = ltdc_load(ddev);
> > if (ret)
> > - goto err;
> > + return ret;
> >
> > drm_mode_config_reset(ddev);
> > drm_kms_helper_poll_init(ddev);
> > @@ -111,9 +113,6 @@ static int drv_load(struct drm_device *ddev)
> > platform_set_drvdata(pdev, ddev);
> >
> > return 0;
> > -err:
> > - drm_mode_config_cleanup(ddev);
> > - return ret;
> > }
> >
> > static void drv_unload(struct drm_device *ddev)
> > @@ -122,7 +121,6 @@ static void drv_unload(struct drm_device *ddev)
> >
> > drm_kms_helper_poll_fini(ddev);
> > ltdc_unload(ddev);
> > - drm_mode_config_cleanup(ddev);
> > }
> >
> > static __maybe_unused int drv_suspend(struct device *dev)
> >
>
> Thank you for your patch,
> For this stm part,
> Acked-by: Philippe Cornu <philippe.cornu@st.com>
>
> note: we will handle devm_kzalloc() asap, thanks.
Note that as-is you can't just blindly switch devm_kzalloc over to
drmm_kzalloc for the structures containing a drm_* object, or you'll
just replace one type of use-after free with another one (and probably
worse, since the new one will hit you on normal driver unload too).
There's a bit more work needed in this area, this here is just the
first steps and a heads up. And removing the devm_kzalloc would result
in lots of code added for a bunch of kfree() all over, not so great
option either.
I'd say wait for the next round :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 12/18] file-posix: Drop hdev_co_create_opts()
From: Max Reitz @ 2020-02-20 16:07 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
The generic fallback implementation effectively does the same.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200122164532.178040-4-mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
block/file-posix.c | 67 ----------------------------------------------
1 file changed, 67 deletions(-)
diff --git a/block/file-posix.c b/block/file-posix.c
index ab82ee1a67..6345477112 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -3477,67 +3477,6 @@ static coroutine_fn int hdev_co_pwrite_zeroes(BlockDriverState *bs,
return raw_do_pwrite_zeroes(bs, offset, bytes, flags, true);
}
-static int coroutine_fn hdev_co_create_opts(const char *filename, QemuOpts *opts,
- Error **errp)
-{
- int fd;
- int ret = 0;
- struct stat stat_buf;
- int64_t total_size = 0;
- bool has_prefix;
-
- /* This function is used by both protocol block drivers and therefore either
- * of these prefixes may be given.
- * The return value has to be stored somewhere, otherwise this is an error
- * due to -Werror=unused-value. */
- has_prefix =
- strstart(filename, "host_device:", &filename) ||
- strstart(filename, "host_cdrom:" , &filename);
-
- (void)has_prefix;
-
- ret = raw_normalize_devicepath(&filename, errp);
- if (ret < 0) {
- return ret;
- }
-
- /* Read out options */
- total_size = ROUND_UP(qemu_opt_get_size_del(opts, BLOCK_OPT_SIZE, 0),
- BDRV_SECTOR_SIZE);
-
- fd = qemu_open(filename, O_WRONLY | O_BINARY);
- if (fd < 0) {
- ret = -errno;
- error_setg_errno(errp, -ret, "Could not open device");
- return ret;
- }
-
- if (fstat(fd, &stat_buf) < 0) {
- ret = -errno;
- error_setg_errno(errp, -ret, "Could not stat device");
- } else if (!S_ISBLK(stat_buf.st_mode) && !S_ISCHR(stat_buf.st_mode)) {
- error_setg(errp,
- "The given file is neither a block nor a character device");
- ret = -ENODEV;
- } else if (lseek(fd, 0, SEEK_END) < total_size) {
- error_setg(errp, "Device is too small");
- ret = -ENOSPC;
- }
-
- if (!ret && total_size) {
- uint8_t buf[BDRV_SECTOR_SIZE] = { 0 };
- int64_t zero_size = MIN(BDRV_SECTOR_SIZE, total_size);
- if (lseek(fd, 0, SEEK_SET) == -1) {
- ret = -errno;
- } else {
- ret = qemu_write_full(fd, buf, zero_size);
- ret = ret == zero_size ? 0 : -errno;
- }
- }
- qemu_close(fd);
- return ret;
-}
-
static BlockDriver bdrv_host_device = {
.format_name = "host_device",
.protocol_name = "host_device",
@@ -3550,8 +3489,6 @@ static BlockDriver bdrv_host_device = {
.bdrv_reopen_prepare = raw_reopen_prepare,
.bdrv_reopen_commit = raw_reopen_commit,
.bdrv_reopen_abort = raw_reopen_abort,
- .bdrv_co_create_opts = hdev_co_create_opts,
- .create_opts = &raw_create_opts,
.mutable_opts = mutable_opts,
.bdrv_co_invalidate_cache = raw_co_invalidate_cache,
.bdrv_co_pwrite_zeroes = hdev_co_pwrite_zeroes,
@@ -3678,8 +3615,6 @@ static BlockDriver bdrv_host_cdrom = {
.bdrv_reopen_prepare = raw_reopen_prepare,
.bdrv_reopen_commit = raw_reopen_commit,
.bdrv_reopen_abort = raw_reopen_abort,
- .bdrv_co_create_opts = hdev_co_create_opts,
- .create_opts = &raw_create_opts,
.mutable_opts = mutable_opts,
.bdrv_co_invalidate_cache = raw_co_invalidate_cache,
@@ -3812,8 +3747,6 @@ static BlockDriver bdrv_host_cdrom = {
.bdrv_reopen_prepare = raw_reopen_prepare,
.bdrv_reopen_commit = raw_reopen_commit,
.bdrv_reopen_abort = raw_reopen_abort,
- .bdrv_co_create_opts = hdev_co_create_opts,
- .create_opts = &raw_create_opts,
.mutable_opts = mutable_opts,
.bdrv_co_preadv = raw_co_preadv,
--
2.24.1
^ permalink raw reply related
* Re: [PATCH AUTOSEL 5.5 096/542] powerpc/powernv/ioda: Fix ref count for devices with their own PE
From: Sasha Levin @ 2020-02-20 16:12 UTC (permalink / raw)
To: Frederic Barrat; +Cc: linuxppc-dev, linux-kernel, stable, Andrew Donnellan
In-Reply-To: <0867167a-73b8-0735-78ce-0d984f7a80b5@linux.ibm.com>
On Mon, Feb 17, 2020 at 09:49:41AM +0100, Frederic Barrat wrote:
>
>
>Le 14/02/2020 à 16:41, Sasha Levin a écrit :
>>From: Frederic Barrat <fbarrat@linux.ibm.com>
>>
>>[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
>
>
>Hi,
>
>Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 doesn't
>really need to go to stable (any of 4.19, 5.4 and 5.5). While it's
>probably safe, the patch replaces a refcount leak by another one,
>which makes sense as part of the full series merged in 5.6-rc1, but
>isn't terribly useful standalone on the current stable branches.
I'll drop it, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature
From: Alberto Garcia @ 2020-02-20 16:10 UTC (permalink / raw)
To: Eric Blake, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <e559107b-b0c1-a2be-4fc2-29f050cced34@redhat.com>
On Thu 20 Feb 2020 03:33:57 PM CET, Eric Blake wrote:
>> Given an offset into the virtual disk, the offset into the image file can be
>> obtained as follows:
>>
>> - l2_entries = (cluster_size / sizeof(uint64_t))
>> + l2_entries = (cluster_size / sizeof(uint64_t)) [*]
>>
>> l2_index = (offset / cluster_size) % l2_entries
>> l1_index = (offset / cluster_size) / l2_entries
>> @@ -447,6 +455,8 @@ obtained as follows:
>>
>> return cluster_offset + (offset % cluster_size)
>>
>> + [*] this changes if Extended L2 Entries are enabled, see next section
>
>> +The size of an extended L2 entry is 128 bits so the number of entries per table
>> +is calculated using this formula:
>> +
>> + l2_entries = (cluster_size / (2 * sizeof(uint64_t)))
>
> Is it worth unifying these statements by writing:
>
> l2_entries = (cluster_size / ((1 + extended_l2) * sizeof(uint64_t)))
>
> or is that too confusing?
I think it's too confusing...
Berto
^ permalink raw reply
* [PULL 05/18] qapi: Allow getting flat output from 'query-named-block-nodes'
From: Max Reitz @ 2020-02-20 16:06 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
From: Peter Krempa <pkrempa@redhat.com>
When a management application manages node names there's no reason to
recurse into backing images in the output of query-named-block-nodes.
Add a parameter to the command which will return just the top level
structs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Message-Id: <4470f8c779abc404dcf65e375db195cd91a80651.1579509782.git.pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[mreitz: Fixed coding style]
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
block.c | 5 +++--
block/qapi.c | 11 +++++++++--
blockdev.c | 8 ++++++--
include/block/block.h | 2 +-
include/block/qapi.h | 4 +++-
monitor/hmp-cmds.c | 2 +-
qapi/block-core.json | 7 ++++++-
7 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/block.c b/block.c
index 946e3c896e..08372ced26 100644
--- a/block.c
+++ b/block.c
@@ -4807,14 +4807,15 @@ BlockDriverState *bdrv_find_node(const char *node_name)
}
/* Put this QMP function here so it can access the static graph_bdrv_states. */
-BlockDeviceInfoList *bdrv_named_nodes_list(Error **errp)
+BlockDeviceInfoList *bdrv_named_nodes_list(bool flat,
+ Error **errp)
{
BlockDeviceInfoList *list, *entry;
BlockDriverState *bs;
list = NULL;
QTAILQ_FOREACH(bs, &graph_bdrv_states, node_list) {
- BlockDeviceInfo *info = bdrv_block_device_info(NULL, bs, errp);
+ BlockDeviceInfo *info = bdrv_block_device_info(NULL, bs, flat, errp);
if (!info) {
qapi_free_BlockDeviceInfoList(list);
return NULL;
diff --git a/block/qapi.c b/block/qapi.c
index 9a5d0c9b27..3f09477cc5 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -42,7 +42,9 @@
#include "qemu/cutils.h"
BlockDeviceInfo *bdrv_block_device_info(BlockBackend *blk,
- BlockDriverState *bs, Error **errp)
+ BlockDriverState *bs,
+ bool flat,
+ Error **errp)
{
ImageInfo **p_image_info;
BlockDriverState *bs0;
@@ -156,6 +158,11 @@ BlockDeviceInfo *bdrv_block_device_info(BlockBackend *blk,
return NULL;
}
+ /* stop gathering data for flat output */
+ if (flat) {
+ break;
+ }
+
if (bs0->drv && bs0->backing) {
info->backing_file_depth++;
bs0 = bs0->backing->bs;
@@ -389,7 +396,7 @@ static void bdrv_query_info(BlockBackend *blk, BlockInfo **p_info,
if (bs && bs->drv) {
info->has_inserted = true;
- info->inserted = bdrv_block_device_info(blk, bs, errp);
+ info->inserted = bdrv_block_device_info(blk, bs, false, errp);
if (info->inserted == NULL) {
goto err;
}
diff --git a/blockdev.c b/blockdev.c
index 45de0ba37e..011dcfec27 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3734,9 +3734,13 @@ void qmp_drive_backup(DriveBackup *backup, Error **errp)
blockdev_do_action(&action, errp);
}
-BlockDeviceInfoList *qmp_query_named_block_nodes(Error **errp)
+BlockDeviceInfoList *qmp_query_named_block_nodes(bool has_flat,
+ bool flat,
+ Error **errp)
{
- return bdrv_named_nodes_list(errp);
+ bool return_flat = has_flat && flat;
+
+ return bdrv_named_nodes_list(return_flat, errp);
}
XDbgBlockGraph *qmp_x_debug_query_block_graph(Error **errp)
diff --git a/include/block/block.h b/include/block/block.h
index 314ce63ed9..cd6b5b95aa 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -454,7 +454,7 @@ void bdrv_lock_medium(BlockDriverState *bs, bool locked);
void bdrv_eject(BlockDriverState *bs, bool eject_flag);
const char *bdrv_get_format_name(BlockDriverState *bs);
BlockDriverState *bdrv_find_node(const char *node_name);
-BlockDeviceInfoList *bdrv_named_nodes_list(Error **errp);
+BlockDeviceInfoList *bdrv_named_nodes_list(bool flat, Error **errp);
XDbgBlockGraph *bdrv_get_xdbg_block_graph(Error **errp);
BlockDriverState *bdrv_lookup_bs(const char *device,
const char *node_name,
diff --git a/include/block/qapi.h b/include/block/qapi.h
index cd9410dee3..22c7807c89 100644
--- a/include/block/qapi.h
+++ b/include/block/qapi.h
@@ -29,7 +29,9 @@
#include "block/snapshot.h"
BlockDeviceInfo *bdrv_block_device_info(BlockBackend *blk,
- BlockDriverState *bs, Error **errp);
+ BlockDriverState *bs,
+ bool flat,
+ Error **errp);
int bdrv_query_snapshot_info_list(BlockDriverState *bs,
SnapshotInfoList **p_list,
Error **errp);
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index b237613e0d..53bc3f76c4 100644
--- a/monitor/hmp-cmds.c
+++ b/monitor/hmp-cmds.c
@@ -620,7 +620,7 @@ void hmp_info_block(Monitor *mon, const QDict *qdict)
}
/* Print node information */
- blockdev_list = qmp_query_named_block_nodes(NULL);
+ blockdev_list = qmp_query_named_block_nodes(false, false, NULL);
for (blockdev = blockdev_list; blockdev; blockdev = blockdev->next) {
assert(blockdev->value->has_node_name);
if (device && strcmp(device, blockdev->value->node_name)) {
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 37d7ea7295..85e27bb61f 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1758,6 +1758,9 @@
#
# Get the named block driver list
#
+# @flat: Omit the nested data about backing image ("backing-image" key) if true.
+# Default is false (Since 5.0)
+#
# Returns: the list of BlockDeviceInfo
#
# Since: 2.0
@@ -1811,7 +1814,9 @@
# } } ] }
#
##
-{ 'command': 'query-named-block-nodes', 'returns': [ 'BlockDeviceInfo' ] }
+{ 'command': 'query-named-block-nodes',
+ 'returns': [ 'BlockDeviceInfo' ],
+ 'data': { '*flat': 'bool' } }
##
# @XDbgBlockGraphNodeType:
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v2 2/8] blk-mq: Keep set->nr_hw_queues and set->map[].nr_queues in sync
From: Bart Van Assche @ 2020-02-20 16:14 UTC (permalink / raw)
To: Ming Lei
Cc: Jens Axboe, linux-block, Christoph Hellwig, Christoph Hellwig,
Hannes Reinecke, Johannes Thumshirn, syzbot+d44e1b26ce5c3e77458d
In-Reply-To: <20200220100524.GA31206@ming.t460p>
On 2/20/20 2:05 AM, Ming Lei wrote:
> On Wed, Feb 19, 2020 at 06:44:35PM -0800, Bart Van Assche wrote:
>> blk_mq_map_queues() and multiple .map_queues() implementations expect that
>> set->map[HCTX_TYPE_DEFAULT].nr_queues is set to the number of hardware
>
> Only single queue mapping expects set->map[HCTX_TYPE_DEFAULT].nr_queues
> to be set->nr_hw_queues. For multiple mapping, set->nr_hw_queues should
> be sum of each mapping's nr_queue.
That's how it should work but that doesn't match what I found in the
kernel tree. Here is an example of a .map_queues() implementation that
depends on .nr_queues being set before it is called:
static int scsi_map_queues(struct blk_mq_tag_set *set)
{
struct Scsi_Host *shost = container_of(set, struct Scsi_Host,
tag_set);
if (shost->hostt->map_queues)
return shost->hostt->map_queues(shost);
return blk_mq_map_queues(&set->map[HCTX_TYPE_DEFAULT]);
}
If shost->hostt->map_queues == NULL, the above function only works
correctly if .nr_queues is set before this function is called.
Additionally, scsi_map_queues() may call e.g. the following function:
static int qla2xxx_map_queues(struct Scsi_Host *shost)
{
int rc;
scsi_qla_host_t *vha = (scsi_qla_host_t *)shost->hostdata;
struct blk_mq_queue_map *qmap =
&shost->tag_set.map[HCTX_TYPE_DEFAULT];
if (USER_CTRL_IRQ(vha->hw) || !vha->hw->mqiobase)
rc = blk_mq_map_queues(qmap);
else
rc = blk_mq_pci_map_queues(qmap, vha->hw->pdev,
vha->irq_offset);
return rc;
}
Both blk_mq_map_queues() and blk_mq_pci_map_queues() assume that
blk_mq_queue_map.nr_queues is set before these functions are called.
Bart.
^ permalink raw reply
* Re: [PATCH 4/5] perf metricgroup: Support metric constraint
From: Liang, Kan @ 2020-02-20 16:14 UTC (permalink / raw)
To: Jiri Olsa
Cc: acme, mingo, peterz, linux-kernel, mark.rutland, namhyung,
ravi.bangoria, yao.jin, ak
In-Reply-To: <20200220113530.GA565976@krava>
On 2/20/2020 6:35 AM, Jiri Olsa wrote:
> On Wed, Feb 19, 2020 at 11:08:39AM -0800, kan.liang@linux.intel.com wrote:
>
> SNIP
>
>> +static bool violate_nmi_constraint;
>> +
>> +static bool metricgroup__has_constraint(struct pmu_event *pe)
>> +{
>> + if (!pe->metric_constraint)
>> + return false;
>> +
>> + if (!strcmp(pe->metric_constraint, "NO_NMI_WATCHDOG") &&
>> + sysctl__nmi_watchdog_enabled()) {
>> + pr_warning("Splitting metric group %s into standalone metrics.\n",
>> + pe->metric_name);
>> + violate_nmi_constraint = true;
>
> no static flags plz.. can't you just print that rest of the warning in here?
>
Because we only want to print the NMI watchdog warning once.
If there are more than one metric groups with constraint, the warning
may be printed several times. For example,
$ perf stat -M Page_Walks_Utilization,Page_Walks_Utilization
Splitting metric group Page_Walks_Utilization into standalone metrics.
Try disabling the NMI watchdog to comply NO_NMI_WATCHDOG metric
constraint:
echo 0 > /proc/sys/kernel/nmi_watchdog
perf stat ...
echo 1 > /proc/sys/kernel/nmi_watchdog
Splitting metric group Page_Walks_Utilization into standalone metrics.
Try disabling the NMI watchdog to comply NO_NMI_WATCHDOG metric
constraint:
echo 0 > /proc/sys/kernel/nmi_watchdog
perf stat ...
echo 1 > /proc/sys/kernel/nmi_watchdog
Is it OK?
If it's OK, I think we can remove the flag.
Thanks,
Kan
> jirka
>
>> + return true;
>> + }
>> +
>> + return false;
>> +}
>> +
>> static int metricgroup__add_metric(const char *metric, struct strbuf *events,
>> struct list_head *group_list)
>> {
>> @@ -460,7 +490,10 @@ static int metricgroup__add_metric(const char *metric, struct strbuf *events,
>> if (events->len > 0)
>> strbuf_addf(events, ",");
>>
>> - metricgroup__add_metric_weak_group(events, ids, idnum);
>> + if (metricgroup__has_constraint(pe))
>> + metricgroup__add_metric_non_group(events, ids, idnum);
>> + else
>> + metricgroup__add_metric_weak_group(events, ids, idnum);
>>
>> eg = malloc(sizeof(struct egroup));
>> if (!eg) {
>> @@ -544,6 +577,13 @@ int metricgroup__parse_groups(const struct option *opt,
>> strbuf_release(&extra_events);
>> ret = metricgroup__setup_events(&group_list, perf_evlist,
>> metric_events);
>> +
>> + if (violate_nmi_constraint) {
>> + pr_warning("Try disabling the NMI watchdog to comply NO_NMI_WATCHDOG metric constraint:\n"
>> + " echo 0 > /proc/sys/kernel/nmi_watchdog\n"
>> + " perf stat ...\n"
>> + " echo 1 > /proc/sys/kernel/nmi_watchdog\n");
>> + }
>> out:
>> metricgroup__free_egroups(&group_list);
>> return ret;
>> --
>> 2.7.4
>>
>
^ permalink raw reply
* Re: Filesystem corruption after unreachable storage
From: Jean-Louis Dupond @ 2020-02-20 16:14 UTC (permalink / raw)
To: Theodore Y. Ts'o; +Cc: linux-ext4
In-Reply-To: <20200220155022.GA532518@mit.edu>
On 20/02/2020 16:50, Theodore Y. Ts'o wrote:
> On Thu, Feb 20, 2020 at 10:08:44AM +0100, Jean-Louis Dupond wrote:
>> dumpe2fs -> see attachment
> Looking at the dumpe2fs output, it's interesting that it was "clean
> with errors", without any error information being logged in the
> superblock. What version of the kernel are you using? I'm guessing
> it's a fairly old one?
Debian 10 (Buster), with kernel 4.19.67-2+deb10u1
>> Fsck:
>> # e2fsck -fy /dev/mapper/vg01-root
>> e2fsck 1.44.5 (15-Dec-2018)
> And that's a old version of e2fsck as well. Is this some kind of
> stable/enterprise linux distro?
Debian 10 indeed.
>> Pass 1: Checking inodes, blocks, and sizes
>> Inodes that were part of a corrupted orphan linked list found. Fix? yes
>>
>> Inode 165708 was part of the orphaned inode list. FIXED.
> OK, this and the rest looks like it's relating to a file truncation or
> deletion at the time of the disconnection.
>
> > > > On KVM for example there is a unlimited timeout (afaik) until the
>>>> storage is
>>>> back, and the VM just continues running after storage recovery.
>>> Well, you can adjust the SCSI timeout, if you want to give that a try....
>> It has some other disadvantages? Or is it quite safe to increment the SCSI
>> timeout?
> It should be pretty safe.
>
> Can you reliably reproduce the problem by disconnecting the machine
> from the SAN?
Yep, can be reproduced by killing the connection to the SAN while the VM
is running, and then after the scsi timeout passed, re-enabled the SAN
connection.
Then reset the machine, and then you need to run an fsck to have it back
online.
> - Ted
^ permalink raw reply
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add support for HDCP 1.4 over MST connectors (rev4)
From: Patchwork @ 2020-02-20 16:14 UTC (permalink / raw)
To: Sean Paul; +Cc: intel-gfx
In-Reply-To: <20200218220242.107265-1-sean@poorly.run>
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST connectors (rev4)
URL : https://patchwork.freedesktop.org/series/70393/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16610_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
New tests
---------
New tests have been introduced between CI_DRM_7963_full and Patchwork_16610_full:
### New IGT tests (58) ###
* igt@i915_pm_backlight@bad-brightness:
- Statuses : 3 pass(s) 3 skip(s)
- Exec time: [0.0, 0.01] s
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 0.23] s
* igt@i915_pm_backlight@fade:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 2.59] s
* igt@i915_pm_backlight@fade_with_dpms:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.99] s
* igt@i915_pm_backlight@fade_with_suspend:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.45] s
* igt@i915_pm_lpsp@edp-native:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.04] s
* igt@i915_pm_lpsp@edp-panel-fitter:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.04] s
* igt@i915_pm_lpsp@non-edp:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.11] s
* igt@i915_pm_lpsp@screens-disabled:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.04] s
* igt@i915_pm_rc6_residency@media-rc6-accuracy:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rc6_residency@rc6-accuracy:
- Statuses : 8 pass(s)
- Exec time: [3.00] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 7 pass(s)
- Exec time: [0.17, 5.03] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [1.32, 11.52] s
* igt@i915_pm_rpm@cursor:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 41.20] s
* igt@i915_pm_rpm@cursor-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 36.77] s
* igt@i915_pm_rpm@debugfs-forcewake-user:
- Statuses : 6 pass(s)
- Exec time: [10.31, 14.15] s
* igt@i915_pm_rpm@debugfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 81.00] s
* igt@i915_pm_rpm@dpms-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 0.82] s
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 13.42] s
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 4.15] s
* igt@i915_pm_rpm@dpms-non-lpsp:
- Statuses : 4 pass(s) 3 skip(s)
- Exec time: [0.0, 0.19] s
* igt@i915_pm_rpm@drm-resources-equal:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.59] s
* igt@i915_pm_rpm@fences:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 14.76] s
* igt@i915_pm_rpm@fences-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 16.75] s
* igt@i915_pm_rpm@gem-evict-pwrite:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 3.97] s
* igt@i915_pm_rpm@gem-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 15.28] s
* igt@i915_pm_rpm@gem-execbuf-stress:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 42.81] s
* igt@i915_pm_rpm@gem-execbuf-stress-pc8:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.00] s
* igt@i915_pm_rpm@gem-idle:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.16] s
* igt@i915_pm_rpm@gem-pread:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 6.40] s
* igt@i915_pm_rpm@i2c:
- Statuses : 7 pass(s)
- Exec time: [0.94, 11.16] s
* igt@i915_pm_rpm@legacy-planes:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 169.67] s
* igt@i915_pm_rpm@legacy-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 169.80] s
* igt@i915_pm_rpm@modeset-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.93] s
* igt@i915_pm_rpm@modeset-lpsp-stress:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 55.03] s
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 18.49] s
* igt@i915_pm_rpm@modeset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 3.94] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 9.13] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 7.06] s
* igt@i915_pm_rpm@modeset-pc8-residency-stress:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 72.02] s
* igt@i915_pm_rpm@pc8-residency:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@pm-caching:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 19.44] s
* igt@i915_pm_rpm@pm-tiling:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 16.66] s
* igt@i915_pm_rpm@reg-read-ioctl:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 8.11] s
* igt@i915_pm_rpm@sysfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 3.98] s
* igt@i915_pm_rpm@system-suspend:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.04] s
* igt@i915_pm_rpm@system-suspend-devices:
- Statuses : 6 pass(s) 1 skip(s)
- Exec time: [0.0, 13.20] s
* igt@i915_pm_rpm@system-suspend-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 85.97] s
* igt@i915_pm_rpm@system-suspend-modeset:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 14.58] s
* igt@i915_pm_rpm@universal-planes:
- Statuses : 7 pass(s)
- Exec time: [2.90, 226.04] s
* igt@i915_pm_rpm@universal-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 195.19] s
* igt@i915_pm_rps@basic-api:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.03] s
* igt@i915_pm_rps@min-max-config-idle:
- Statuses : 8 pass(s)
- Exec time: [0.11, 1.05] s
* igt@i915_pm_rps@min-max-config-loaded:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [0.31, 3.02] s
* igt@i915_pm_rps@reset:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [3.52, 3.66] s
* igt@i915_pm_rps@waitboost:
- Statuses : 8 pass(s)
- Exec time: [2.52, 2.63] s
* igt@i915_pm_sseu@full-enable:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 0.01] s
Known issues
------------
Here are the changes found in Patchwork_16610_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +12 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_busy@busy-vcs1.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb8/igt@gem_busy@busy-vcs1.html
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_ctx_shared@exec-single-timeline-bsd.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html
* igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb8/igt@gem_exec_schedule@pi-shared-iova-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb4/igt@gem_exec_schedule@pi-shared-iova-bsd.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +3 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_exec_schedule@preempt-other-chain-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb4/igt@gem_exec_schedule@preempt-other-chain-bsd.html
* igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +17 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_exec_schedule@preempt-queue-bsd1.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb3/igt@gem_exec_schedule@preempt-queue-bsd1.html
* igt@gem_partial_pwrite_pread@write-uncached:
- shard-hsw: [PASS][11] -> [FAIL][12] ([i915#694]) +2 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw1/igt@gem_partial_pwrite_pread@write-uncached.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-hsw1/igt@gem_partial_pwrite_pread@write-uncached.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#644])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb7/igt@gem_ppgtt@flink-and-close-vma-leak.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-tglb3/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@i915_selftest@live_gt_lrc:
- shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#1233])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb8/igt@i915_selftest@live_gt_lrc.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-tglb7/igt@i915_selftest@live_gt_lrc.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl3/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-kbl7/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
* igt@kms_flip@flip-vs-absolute-wf_vblank:
- shard-tglb: [PASS][19] -> [FAIL][20] ([i915#488])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-tglb1/igt@kms_flip@flip-vs-absolute-wf_vblank.html
* igt@kms_flip@flip-vs-suspend:
- shard-kbl: [PASS][21] -> [INCOMPLETE][22] ([fdo#103665] / [i915#600])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl3/igt@kms_flip@flip-vs-suspend.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-kbl7/igt@kms_flip@flip-vs-suspend.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-skl: [PASS][23] -> [FAIL][24] ([i915#49])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-skl3/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][25] -> [FAIL][26] ([fdo#108145])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-skl3/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][27] -> [FAIL][28] ([fdo#108145] / [i915#265])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-skl9/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][29] -> [SKIP][30] ([fdo#109441]) +2 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb7/igt@kms_psr@psr2_cursor_mmap_cpu.html
* igt@perf@short-reads:
- shard-apl: [PASS][31] -> [TIMEOUT][32] ([fdo#112271] / [i915#51])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@perf@short-reads.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-apl8/igt@perf@short-reads.html
#### Possible fixes ####
* {igt@gem_ctx_persistence@close-replace-race}:
- shard-iclb: [FAIL][33] ([i915#1241]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_ctx_persistence@close-replace-race.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb2/igt@gem_ctx_persistence@close-replace-race.html
- shard-apl: [FAIL][35] ([i915#1241]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl4/igt@gem_ctx_persistence@close-replace-race.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-apl2/igt@gem_ctx_persistence@close-replace-race.html
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox}:
- shard-skl: [FAIL][37] ([i915#679]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-skl1/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
* {igt@gem_exec_schedule@implicit-both-bsd2}:
- shard-iclb: [SKIP][39] ([fdo#109276] / [i915#677]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb8/igt@gem_exec_schedule@implicit-both-bsd2.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb1/igt@gem_exec_schedule@implicit-both-bsd2.html
* {igt@gem_exec_schedule@implicit-read-write-bsd}:
- shard-iclb: [SKIP][41] ([i915#677]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@gem_exec_schedule@implicit-read-write-bsd.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb7/igt@gem_exec_schedule@implicit-read-write-bsd.html
* igt@gem_exec_schedule@pi-ringfull-bsd:
- shard-iclb: [SKIP][43] ([fdo#112146]) -> [PASS][44] +2 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_exec_schedule@pi-ringfull-bsd.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb7/igt@gem_exec_schedule@pi-ringfull-bsd.html
* igt@gem_exec_store@cachelines-vcs1:
- shard-iclb: [SKIP][45] ([fdo#112080]) -> [PASS][46] +9 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_exec_store@cachelines-vcs1.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb2/igt@gem_exec_store@cachelines-vcs1.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [FAIL][47] ([i915#644]) -> [PASS][48]
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk8/igt@gem_ppgtt@flink-and-close-vma-leak.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-glk1/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@i915_pm_rps@waitboost (NEW):
- shard-tglb: [FAIL][49] ([i915#413]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@i915_pm_rps@waitboost.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-tglb8/igt@i915_pm_rps@waitboost.html
* igt@kms_cursor_crc@pipe-a-cursor-size-change:
- shard-snb: [SKIP][51] ([fdo#109271]) -> [PASS][52] +1 similar issue
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-snb4/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-snb1/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [FAIL][53] ([i915#96]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw8/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-hsw1/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [DMESG-WARN][55] ([i915#180]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-kbl4/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [FAIL][57] ([i915#79]) -> [PASS][58]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw: [INCOMPLETE][59] ([i915#61]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@kms_flip@flip-vs-suspend-interruptible.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-hsw6/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_frontbuffer_tracking@psr-1p-rte:
- shard-tglb: [SKIP][61] ([i915#668]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-tglb1/igt@kms_frontbuffer_tracking@psr-1p-rte.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [DMESG-WARN][63] ([i915#180]) -> [PASS][64] +2 similar issues
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [FAIL][65] ([fdo#108145]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-skl4/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_psr@no_drrs:
- shard-iclb: [FAIL][67] ([i915#173]) -> [PASS][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@kms_psr@no_drrs.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb2/igt@kms_psr@no_drrs.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [SKIP][69] ([fdo#109441]) -> [PASS][70] +3 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@kms_psr@psr2_primary_page_flip.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_setmode@basic:
- shard-apl: [FAIL][71] ([i915#31]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl2/igt@kms_setmode@basic.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-apl7/igt@kms_setmode@basic.html
- shard-skl: [FAIL][73] ([i915#31]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_setmode@basic.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-skl4/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl: [INCOMPLETE][75] ([i915#69]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-skl5/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@perf@short-reads:
- shard-kbl: [TIMEOUT][77] ([fdo#112271] / [i915#51]) -> [PASS][78]
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@perf@short-reads.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-kbl7/igt@perf@short-reads.html
* igt@prime_mmap_coherency@ioctl-errors:
- shard-hsw: [FAIL][79] ([i915#831]) -> [PASS][80]
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@prime_mmap_coherency@ioctl-errors.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-hsw8/igt@prime_mmap_coherency@ioctl-errors.html
* igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: [SKIP][81] ([fdo#109276]) -> [PASS][82] +21 similar issues
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb8/igt@prime_vgem@fence-wait-bsd2.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb1/igt@prime_vgem@fence-wait-bsd2.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [SKIP][83] ([fdo#112080]) -> [FAIL][84] ([IGT#28])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@gem_tiled_blits@interruptible:
- shard-hsw: [FAIL][85] ([i915#818]) -> [FAIL][86] ([i915#694])
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw1/igt@gem_tiled_blits@interruptible.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-hsw4/igt@gem_tiled_blits@interruptible.html
* igt@gen7_exec_parse@basic-allocation:
- shard-hsw: [FAIL][87] ([i915#694]) -> [INCOMPLETE][88] ([i915#61])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw8/igt@gen7_exec_parse@basic-allocation.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-hsw7/igt@gen7_exec_parse@basic-allocation.html
* igt@i915_pm_dc@dc6-psr:
- shard-tglb: [FAIL][89] ([i915#454]) -> [SKIP][90] ([i915#468])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb6/igt@i915_pm_dc@dc6-psr.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-tglb2/igt@i915_pm_dc@dc6-psr.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [SKIP][91] ([fdo#109349]) -> [DMESG-WARN][92] ([i915#1226])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@kms_dp_dsc@basic-dsc-enable-edp.html
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#1241]: https://gitlab.freedesktop.org/drm/intel/issues/1241
[i915#173]: https://gitlab.freedesktop.org/drm/intel/issues/173
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#413]: https://gitlab.freedesktop.org/drm/intel/issues/413
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#468]: https://gitlab.freedesktop.org/drm/intel/issues/468
[i915#488]: https://gitlab.freedesktop.org/drm/intel/issues/488
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#51]: https://gitlab.freedesktop.org/drm/intel/issues/51
[i915#600]: https://gitlab.freedesktop.org/drm/intel/issues/600
[i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#831]: https://gitlab.freedesktop.org/drm/intel/issues/831
[i915#96]: https://gitlab.freedesktop.org/drm/intel/issues/96
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7963 -> Patchwork_16610
CI-20190529: 20190529
CI_DRM_7963: e0d737598eb749378a5dc4ed3dfafc6f79d512cb @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5448: 116020b1f83c1b3994c76882df7f77b6731d78ba @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16610: 1b69e08389bd2a60c87d99bbb75687c781368d24 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16610/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2] net: WireGuard secure network tunnel]
From: Dmitry Vyukov @ 2020-02-20 16:14 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: netdev, syzbot, WireGuard mailing list
In-Reply-To: <CAHmME9pr4=cn5ijSNs05=fjdfQon49kyEzymkUREJ=xzTZ7Q7w@mail.gmail.com>
On Wed, Feb 19, 2020 at 11:23 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Tue, Feb 18, 2020 at 11:00 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > I've added descriptions for wireguard packets:
> > https://github.com/google/syzkaller/commit/012fbc3229ebef871a201ea431b16610e6e0d345
> > It gives all reachable coverage (without breaking crypto).
>
> Oh, great, that looks really good. It now fails at the index match,
> which is basically trying to brute force a 32-bit integer that's
> changing every 3 minutes, which syzkaller is probably too slow to do
> on it's own. But that's fine.
>
> Your commit has some questions in it, like "# Not clear if these
> indexes are also generated randomly and we need to guess them or
> not.". Here's what's up with those indices:
>
> Message message_handshake_initiation: the sender picks a random 32-bit
> number, and places it in the "sender_index" field.
> Message message_handshake_response: the sender picks a random 32-bit
> number, and places it in the "sender_index" field. It places the
> 32-bit number that it received from message_handshake_initiation into
> the "receiver_index" field.
> Message message_handshake_cookie: the sender places the 32-bit number
> that it received from message_handshake_initiation or
> message_handshake_response into the "receive_index" field.
> Message message_data: the sender places the 32-bit number that it
> picked for the message_handshake_initiation or
> message_handshake_response into the "key_idx" field.
>
> I'm not sure it'll be too feasible to correlate these relations via
> fuzzing. And either way, I think we've got decent enough non-crypto
> coverage now on the receive path.
>
> I noticed a small seemingly insignificant function with low coverage
> that's on the rtnl path that might benefit from some attention and
> also help find bugs in other devices: wg_netdevice_notification. This
> triggers on various things, but the only case it really cares about is
> NETDEV_REGISTER, which happens when the interface changes network
> namespaces. WireGuard holds a reference to its underlying creating
> namespace, and in order to avoid circular reference counting or UaF it
> needs to either relinquish or get a reference. There are other drivers
> with similar type of reference counting management, I would assume.
> This sort of thing seems up the ally of the types of bugs and races
> syzkaller likes to find. The way to trigger it is with `ip link set
> dev wg0 netns blah`, and then back to its original netns. That's this
> code in net/core/rtnetlink.c:
>
> if (tb[IFLA_NET_NS_PID] || tb[IFLA_NET_NS_FD] ||
> tb[IFLA_TARGET_NETNSID]) {
> struct net *net = rtnl_link_get_net_capable(skb, dev_net(dev),
> tb, CAP_NET_ADMIN);
> if (IS_ERR(net)) {
> err = PTR_ERR(net);
> goto errout;
> }
>
> err = dev_change_net_namespace(dev, net, ifname);
> put_net(net);
> if (err)
> goto errout;
> status |= DO_SETLINK_MODIFIED;
> }
>
> That seems to have decent coverage, but not over wireguard. Is that
> just a result of the syzkaller @devname not yet being expanded to
> wg{0,1,2}, and it'll take a few more weeks for it to learn that?
> @netns_id seems probably good, being restricted to 0:4; is it possible
> these weren't created though a priori?
Running an instance aimed at these functions:
"enable_syscalls": [
"socket$nl_generic",
"syz_genetlink_get_family_id$wireguard",
"sendmsg$WG_CMD*",
"ioctl$ifreq_SIOCGIFINDEX_wireguard*",
"socket$nl_route",
"sendmsg$nl_route",
"setsockopt",
"syz_emit_ethernet",
"syz_extract_tcp_res",
"socket$inet*",
"accept4$inet*",
"bind$inet*",
"connect$inet*",
"sendto$inet*",
"recvfrom$inet*",
"syz_genetlink_get_family_id$fou",
"sendmsg$FOU*",
"unshare",
"setns",
"socket",
"socketpair",
"getuid",
"getgid",
"bpf",
"setsockopt",
"getsockopt",
"ioctl",
"accept4",
"connect",
"bind",
"listen",
"sendmsg",
"recvmsg",
"syz_emit_ethernet",
"syz_extract_tcp_res",
"write$tun",
"syz_init_net_socket",
"syz_genetlink_get_family_id",
"syz_open_procfs$namespace",
"ioctl$NS_GET*",
"ioctl$TUN*",
"openat$tun",
"getpid",
"mmap"
]
I got some coverage in wg_netdevice_notification:
https://imgur.com/a/1sJZKtp
Or you mean the parts that are still red?
I think theoretically these parts should be reachable too because
syzkaller can do unshare and obtain net ns fd's.
It's quite hard to test because it just crashes all the time on known bugs.
So maybe the most profitable way to get more coverage throughout the
networking subsystem now is to fix the top layer of crashers ;)
2020/02/20 16:29:08 vm-9: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:32:25 vm-6: crash: kernel BUG at net/core/skbuff.c:LINE!
2020/02/20 16:33:13 vm-16: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:33:46 vm-5: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:34:22 vm-2: crash: WARNING in restore_regulatory_settings
2020/02/20 16:34:27 vm-4: crash: unregister_netdevice: waiting for DEV
to become free
2020/02/20 16:35:04 vm-26: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:35:17 vm-34: crash: no output from test machine
2020/02/20 16:35:20 vm-0: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:36:42 vm-3: crash: WARNING in restore_regulatory_settings
2020/02/20 16:37:47 vm-29: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:38:54 vm-31: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:39:00 vm-9: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:41:41 vm-4: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:43:00 vm-23: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:44:01 vm-2: crash: possible deadlock in htab_lru_map_delete_node
2020/02/20 16:44:06 vm-38: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:47:13 vm-8: crash: unregister_netdevice: waiting for DEV
to become free
2020/02/20 16:47:20 vm-25: crash: unregister_netdevice: waiting for
DEV to become free
2020/02/20 16:47:33 vm-18: crash: BUG: using smp_processor_id() in
preemptible [ADDR] code: syz-executor
2020/02/20 16:49:37 vm-37: crash: unregister_netdevice: waiting for
DEV to become free
2020/02/20 16:51:51 vm-12: crash: WARNING in print_bfs_bug
2020/02/20 16:53:28 vm-4: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:55:24 vm-17: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:56:26 vm-34: crash: BUG: MAX_LOCKDEP_KEYS too low!
2020/02/20 16:57:11 vm-3: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:57:44 vm-31: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:58:13 vm-33: crash: BUG: MAX_LOCKDEP_KEYS too low!
2020/02/20 16:58:35 vm-32: crash: BUG: using smp_processor_id() in
preemptible [ADDR] code: syz-executor
2020/02/20 17:03:12 vm-9: crash: INFO: task hung in raw_release
2020/02/20 17:03:20 vm-3: crash: unregister_netdevice: waiting for DEV
to become free
2020/02/20 17:03:26 vm-6: crash: BUG: using smp_processor_id() in
preemptible [ADDR] code: syz-executor
2020/02/20 17:05:08 vm-31: crash: INFO: task hung in lock_sock_nested
2020/02/20 17:06:01 vm-16: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 17:06:24 vm-26: crash: INFO: task hung in bcm_release
2020/02/20 17:07:20 vm-27: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 17:08:03 vm-11: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 17:08:05 vm-17: crash: WARNING in hsr_addr_subst_dest
2020/02/20 17:09:12 vm-22: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
^ permalink raw reply
* Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2] net: WireGuard secure network tunnel]
From: Dmitry Vyukov @ 2020-02-20 16:14 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: netdev, syzbot, WireGuard mailing list
In-Reply-To: <CAHmME9pr4=cn5ijSNs05=fjdfQon49kyEzymkUREJ=xzTZ7Q7w@mail.gmail.com>
On Wed, Feb 19, 2020 at 11:23 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Tue, Feb 18, 2020 at 11:00 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> > I've added descriptions for wireguard packets:
> > https://github.com/google/syzkaller/commit/012fbc3229ebef871a201ea431b16610e6e0d345
> > It gives all reachable coverage (without breaking crypto).
>
> Oh, great, that looks really good. It now fails at the index match,
> which is basically trying to brute force a 32-bit integer that's
> changing every 3 minutes, which syzkaller is probably too slow to do
> on it's own. But that's fine.
>
> Your commit has some questions in it, like "# Not clear if these
> indexes are also generated randomly and we need to guess them or
> not.". Here's what's up with those indices:
>
> Message message_handshake_initiation: the sender picks a random 32-bit
> number, and places it in the "sender_index" field.
> Message message_handshake_response: the sender picks a random 32-bit
> number, and places it in the "sender_index" field. It places the
> 32-bit number that it received from message_handshake_initiation into
> the "receiver_index" field.
> Message message_handshake_cookie: the sender places the 32-bit number
> that it received from message_handshake_initiation or
> message_handshake_response into the "receive_index" field.
> Message message_data: the sender places the 32-bit number that it
> picked for the message_handshake_initiation or
> message_handshake_response into the "key_idx" field.
>
> I'm not sure it'll be too feasible to correlate these relations via
> fuzzing. And either way, I think we've got decent enough non-crypto
> coverage now on the receive path.
>
> I noticed a small seemingly insignificant function with low coverage
> that's on the rtnl path that might benefit from some attention and
> also help find bugs in other devices: wg_netdevice_notification. This
> triggers on various things, but the only case it really cares about is
> NETDEV_REGISTER, which happens when the interface changes network
> namespaces. WireGuard holds a reference to its underlying creating
> namespace, and in order to avoid circular reference counting or UaF it
> needs to either relinquish or get a reference. There are other drivers
> with similar type of reference counting management, I would assume.
> This sort of thing seems up the ally of the types of bugs and races
> syzkaller likes to find. The way to trigger it is with `ip link set
> dev wg0 netns blah`, and then back to its original netns. That's this
> code in net/core/rtnetlink.c:
>
> if (tb[IFLA_NET_NS_PID] || tb[IFLA_NET_NS_FD] ||
> tb[IFLA_TARGET_NETNSID]) {
> struct net *net = rtnl_link_get_net_capable(skb, dev_net(dev),
> tb, CAP_NET_ADMIN);
> if (IS_ERR(net)) {
> err = PTR_ERR(net);
> goto errout;
> }
>
> err = dev_change_net_namespace(dev, net, ifname);
> put_net(net);
> if (err)
> goto errout;
> status |= DO_SETLINK_MODIFIED;
> }
>
> That seems to have decent coverage, but not over wireguard. Is that
> just a result of the syzkaller @devname not yet being expanded to
> wg{0,1,2}, and it'll take a few more weeks for it to learn that?
> @netns_id seems probably good, being restricted to 0:4; is it possible
> these weren't created though a priori?
Running an instance aimed at these functions:
"enable_syscalls": [
"socket$nl_generic",
"syz_genetlink_get_family_id$wireguard",
"sendmsg$WG_CMD*",
"ioctl$ifreq_SIOCGIFINDEX_wireguard*",
"socket$nl_route",
"sendmsg$nl_route",
"setsockopt",
"syz_emit_ethernet",
"syz_extract_tcp_res",
"socket$inet*",
"accept4$inet*",
"bind$inet*",
"connect$inet*",
"sendto$inet*",
"recvfrom$inet*",
"syz_genetlink_get_family_id$fou",
"sendmsg$FOU*",
"unshare",
"setns",
"socket",
"socketpair",
"getuid",
"getgid",
"bpf",
"setsockopt",
"getsockopt",
"ioctl",
"accept4",
"connect",
"bind",
"listen",
"sendmsg",
"recvmsg",
"syz_emit_ethernet",
"syz_extract_tcp_res",
"write$tun",
"syz_init_net_socket",
"syz_genetlink_get_family_id",
"syz_open_procfs$namespace",
"ioctl$NS_GET*",
"ioctl$TUN*",
"openat$tun",
"getpid",
"mmap"
]
I got some coverage in wg_netdevice_notification:
https://imgur.com/a/1sJZKtp
Or you mean the parts that are still red?
I think theoretically these parts should be reachable too because
syzkaller can do unshare and obtain net ns fd's.
It's quite hard to test because it just crashes all the time on known bugs.
So maybe the most profitable way to get more coverage throughout the
networking subsystem now is to fix the top layer of crashers ;)
2020/02/20 16:29:08 vm-9: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:32:25 vm-6: crash: kernel BUG at net/core/skbuff.c:LINE!
2020/02/20 16:33:13 vm-16: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:33:46 vm-5: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:34:22 vm-2: crash: WARNING in restore_regulatory_settings
2020/02/20 16:34:27 vm-4: crash: unregister_netdevice: waiting for DEV
to become free
2020/02/20 16:35:04 vm-26: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:35:17 vm-34: crash: no output from test machine
2020/02/20 16:35:20 vm-0: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:36:42 vm-3: crash: WARNING in restore_regulatory_settings
2020/02/20 16:37:47 vm-29: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:38:54 vm-31: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:39:00 vm-9: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:41:41 vm-4: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:43:00 vm-23: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:44:01 vm-2: crash: possible deadlock in htab_lru_map_delete_node
2020/02/20 16:44:06 vm-38: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:47:13 vm-8: crash: unregister_netdevice: waiting for DEV
to become free
2020/02/20 16:47:20 vm-25: crash: unregister_netdevice: waiting for
DEV to become free
2020/02/20 16:47:33 vm-18: crash: BUG: using smp_processor_id() in
preemptible [ADDR] code: syz-executor
2020/02/20 16:49:37 vm-37: crash: unregister_netdevice: waiting for
DEV to become free
2020/02/20 16:51:51 vm-12: crash: WARNING in print_bfs_bug
2020/02/20 16:53:28 vm-4: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:55:24 vm-17: crash: INFO: task hung in register_netdevice_notifier
2020/02/20 16:56:26 vm-34: crash: BUG: MAX_LOCKDEP_KEYS too low!
2020/02/20 16:57:11 vm-3: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:57:44 vm-31: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 16:58:13 vm-33: crash: BUG: MAX_LOCKDEP_KEYS too low!
2020/02/20 16:58:35 vm-32: crash: BUG: using smp_processor_id() in
preemptible [ADDR] code: syz-executor
2020/02/20 17:03:12 vm-9: crash: INFO: task hung in raw_release
2020/02/20 17:03:20 vm-3: crash: unregister_netdevice: waiting for DEV
to become free
2020/02/20 17:03:26 vm-6: crash: BUG: using smp_processor_id() in
preemptible [ADDR] code: syz-executor
2020/02/20 17:05:08 vm-31: crash: INFO: task hung in lock_sock_nested
2020/02/20 17:06:01 vm-16: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 17:06:24 vm-26: crash: INFO: task hung in bcm_release
2020/02/20 17:07:20 vm-27: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 17:08:03 vm-11: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/02/20 17:08:05 vm-17: crash: WARNING in hsr_addr_subst_dest
2020/02/20 17:09:12 vm-22: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* [PULL 10/18] block/nbd: Fix hang in .bdrv_close()
From: Max Reitz @ 2020-02-20 16:07 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
When nbd_close() is called from a coroutine, the connection_co never
gets to run, and thus nbd_teardown_connection() hangs.
This is because aio_co_enter() only puts the connection_co into the main
coroutine's wake-up queue, so this main coroutine needs to yield and
wait for connection_co to terminate.
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200122164532.178040-2-mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
block/nbd.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/block/nbd.c b/block/nbd.c
index d085554f21..6d3b22f844 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -70,6 +70,7 @@ typedef struct BDRVNBDState {
CoMutex send_mutex;
CoQueue free_sema;
Coroutine *connection_co;
+ Coroutine *teardown_co;
QemuCoSleepState *connection_co_sleep_ns_state;
bool drained;
bool wait_drained_end;
@@ -203,7 +204,15 @@ static void nbd_teardown_connection(BlockDriverState *bs)
qemu_co_sleep_wake(s->connection_co_sleep_ns_state);
}
}
- BDRV_POLL_WHILE(bs, s->connection_co);
+ if (qemu_in_coroutine()) {
+ s->teardown_co = qemu_coroutine_self();
+ /* connection_co resumes us when it terminates */
+ qemu_coroutine_yield();
+ s->teardown_co = NULL;
+ } else {
+ BDRV_POLL_WHILE(bs, s->connection_co);
+ }
+ assert(!s->connection_co);
}
static bool nbd_client_connecting(BDRVNBDState *s)
@@ -395,6 +404,9 @@ static coroutine_fn void nbd_connection_entry(void *opaque)
s->ioc = NULL;
}
+ if (s->teardown_co) {
+ aio_co_wake(s->teardown_co);
+ }
aio_wait_kick();
}
--
2.24.1
^ permalink raw reply related
* [PULL 16/18] iotests: Test convert -n -B to backing-less target
From: Max Reitz @ 2020-02-20 16:07 UTC (permalink / raw)
To: qemu-block; +Cc: Kevin Wolf, Peter Maydell, qemu-devel, Max Reitz
In-Reply-To: <20200220160710.533297-1-mreitz@redhat.com>
This must not crash.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200121155915.98232-3-mreitz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
tests/qemu-iotests/122 | 14 ++++++++++++++
tests/qemu-iotests/122.out | 5 +++++
2 files changed, 19 insertions(+)
diff --git a/tests/qemu-iotests/122 b/tests/qemu-iotests/122
index dfa350936f..f7a3ae684a 100755
--- a/tests/qemu-iotests/122
+++ b/tests/qemu-iotests/122
@@ -276,6 +276,20 @@ $QEMU_IMG convert -O $IMGFMT -n "$TEST_IMG" "$TEST_IMG".orig
$QEMU_IMG compare "$TEST_IMG" "$TEST_IMG".orig
+echo
+echo '=== -n -B to an image without a backing file ==='
+echo
+
+# Base for the output
+TEST_IMG="$TEST_IMG".base _make_test_img 64M
+
+# Output that does have $TEST_IMG.base set as its (implicit) backing file
+TEST_IMG="$TEST_IMG".orig _make_test_img 64M
+
+# Convert with -n, which should not confuse -B with "target BDS has a
+# backing file"
+$QEMU_IMG convert -O $IMGFMT -B "$TEST_IMG".base -n "$TEST_IMG" "$TEST_IMG".orig
+
# success, all done
echo '*** done'
rm -f $seq.full
diff --git a/tests/qemu-iotests/122.out b/tests/qemu-iotests/122.out
index 849b6cc2ef..1a35951a80 100644
--- a/tests/qemu-iotests/122.out
+++ b/tests/qemu-iotests/122.out
@@ -228,4 +228,9 @@ Formatting 'TEST_DIR/t.IMGFMT.orig', fmt=IMGFMT size=67108864
wrote 65536/65536 bytes at offset 0
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
Images are identical.
+
+=== -n -B to an image without a backing file ===
+
+Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=67108864
+Formatting 'TEST_DIR/t.IMGFMT.orig', fmt=IMGFMT size=67108864
*** done
--
2.24.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.