Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Commit: 987a6da5152c Linux 4.19.7-rc1
The results of these automated tests are provided below.
Overall result: PASSED
Patch merge: OK
Compile: OK
Kernel tests: OK
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Compile testing
---------------
We compiled the kernel for 2 architectures:
aarch64:
make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg
configuration: https://artifacts.cki-project.org/builds/aarch64/987a6da5152c29e37cc11de9a2…
x86_64:
make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg
configuration: https://artifacts.cki-project.org/builds/x86_64/987a6da5152c29e37cc11de9a2d…
Hardware testing
----------------
We booted each kernel and ran the following tests:
arm64:
/distribution/kpkginstall (boot test)
LTP lite - release 20180515
xfstests: ext4
xfstests: xfs
/kernel/misc/amtu
x86_64:
/distribution/kpkginstall (boot test)
LTP lite - release 20180515
xfstests: ext4
xfstests: xfs
/kernel/misc/amtu
[BUG]
A completely valid btrfs will refuse to mount, with error message like:
BTRFS critical (device sdb2): corrupt leaf: root=2 block=239681536 slot=172 \
bg_start=12018974720 bg_len=10888413184, invalid block group size, \
have 10888413184 expect (0, 10737418240]
Btrfs check returns no error, and all kernels used on this fs is later
than 2011, which should all have the 10G size limit commit.
[CAUSE]
For a 12 devices btrfs, we could allocate a chunk larger than 10G due to
stripe stripe bump up.
__btrfs_alloc_chunk()
|- max_stripe_size = 1G
|- max_chunk_size = 10G
|- data_stripe = 11
|- if (1G * 11 > 10G) {
stripe_size = 976128930;
stripe_size = round_up(976128930, SZ_16M) = 989855744
However the final stripe_size (989855744) * 11 = 10888413184, which is
still larger than 10G.
[FIX]
For the comprehensive check, we need to do the full check at chunk
read time, and rely on bg <-> chunk mapping to do the check.
We could just skip the length check for now.
Fixes: fce466eab7ac ("btrfs: tree-checker: Verify block_group_item")
Cc: stable(a)vger.kernel.org # v4.19+
Reported-by: Wang Yugui <wangyugui(a)e16-tech.com>
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
---
fs/btrfs/tree-checker.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index cab0b1f1f741..d8bd5340fbbc 100644
--- a/fs/btrfs/tree-checker.c
+++ b/fs/btrfs/tree-checker.c
@@ -389,13 +389,11 @@ static int check_block_group_item(struct btrfs_fs_info *fs_info,
/*
* Here we don't really care about alignment since extent allocator can
- * handle it. We care more about the size, as if one block group is
- * larger than maximum size, it's must be some obvious corruption.
+ * handle it. We care more about the size.
*/
- if (key->offset > BTRFS_MAX_DATA_CHUNK_SIZE || key->offset == 0) {
+ if (key->offset == 0) {
block_group_err(fs_info, leaf, slot,
- "invalid block group size, have %llu expect (0, %llu]",
- key->offset, BTRFS_MAX_DATA_CHUNK_SIZE);
+ "invalid block group size 0");
return -EUCLEAN;
}
--
2.19.1
Currently kernel might allocate different connector ids
for the same outputs in case of DP MST, which seems to
confuse userspace. There are can be different connector
ids in the list, which could be assigned to the same
output, while being in different states.
This results in issues, like external displays staying
blank after quick unplugging and plugging back(bug #106250).
Returning only active DP connectors fixes the issue.
v2: Removed caps from the title
v3: Refactored initial condition to look more compact.
Thanks to Chris Wilson for giving a hint.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106250
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy(a)intel.com>
---
drivers/gpu/drm/drm_mode_config.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index ee80788f2c40..3e2cd959a66a 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -143,22 +143,28 @@ int drm_mode_getresources(struct drm_device *dev, void *data,
drm_connector_list_iter_begin(dev, &conn_iter);
count = 0;
connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
+ DRM_DEBUG_KMS("GetResources: writing connectors start");
drm_for_each_connector_iter(connector, &conn_iter) {
/* only expose writeback connectors if userspace understands them */
if (!file_priv->writeback_connectors &&
(connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
continue;
+ if (READ_ONCE(connector->registration_state) != DRM_CONNECTOR_REGISTERED)
+ continue;
+
if (drm_lease_held(file_priv, connector->base.id)) {
if (count < card_res->count_connectors &&
put_user(connector->base.id, connector_id + count)) {
drm_connector_list_iter_end(&conn_iter);
return -EFAULT;
}
+ DRM_DEBUG_KMS("GetResources: connector %s", connector->name);
count++;
}
}
card_res->count_connectors = count;
+ DRM_DEBUG_KMS("GetResources: writing connectors end - count %d", count);
drm_connector_list_iter_end(&conn_iter);
return ret;
--
2.17.1