This is the start of the stable review cycle for the 5.11.1 release.
There are 12 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 24 Feb 2021 12:07:46 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.1-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.11.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.11.1-rc1
Matwey V. Kornilov <[email protected]>
media: pwc: Use correct device for DMA
Trent Piepho <[email protected]>
Bluetooth: btusb: Always fallback to alt 1 for WBS
Linus Torvalds <[email protected]>
tty: protect tty_write from odd low-level tty disciplines
Jan Beulich <[email protected]>
xen-blkback: fix error handling in xen_blkbk_map()
Jan Beulich <[email protected]>
xen-scsiback: don't "handle" error by BUG()
Jan Beulich <[email protected]>
xen-netback: don't "handle" error by BUG()
Jan Beulich <[email protected]>
xen-blkback: don't "handle" error by BUG()
Stefano Stabellini <[email protected]>
xen/arm: don't ignore return errors from set_phys_to_machine
Jan Beulich <[email protected]>
Xen/gntdev: correct error checking in gntdev_map_grant_pages()
Jan Beulich <[email protected]>
Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
Jan Beulich <[email protected]>
Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
Jan Beulich <[email protected]>
Xen/x86: don't bail early from clear_foreign_p2m_mapping()
-------------
Diffstat:
Makefile | 4 ++--
arch/arm/xen/p2m.c | 6 ++++--
arch/x86/xen/p2m.c | 15 +++++++--------
drivers/block/xen-blkback/blkback.c | 32 ++++++++++++++++++--------------
drivers/bluetooth/btusb.c | 20 ++++++--------------
drivers/media/usb/pwc/pwc-if.c | 22 +++++++++++++---------
drivers/net/xen-netback/netback.c | 4 +---
drivers/tty/tty_io.c | 5 ++++-
drivers/xen/gntdev.c | 37 ++++++++++++++++++++-----------------
drivers/xen/xen-scsiback.c | 4 ++--
include/xen/grant_table.h | 1 +
11 files changed, 78 insertions(+), 72 deletions(-)
From: Jan Beulich <[email protected]>
commit dbe5283605b3bc12ca45def09cc721a0a5c853a2 upstream.
We may not skip setting the field in the unmap structure when
GNTMAP_device_map is in use - such an unmap would fail to release the
respective resources (a page ref in the hypervisor). Otoh the field
doesn't need setting at all when GNTMAP_device_map is not in use.
To record the value for unmapping, we also better don't use our local
p2m: In particular after a subsequent change it may not have got updated
for all the batch elements. Instead it can simply be taken from the
respective map's results.
We can additionally avoid playing this game altogether for the kernel
part of the mappings in (x86) PV mode.
This is part of XSA-361.
Signed-off-by: Jan Beulich <[email protected]>
Cc: [email protected]
Reviewed-by: Stefano Stabellini <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/gntdev.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -309,18 +309,25 @@ int gntdev_map_grant_pages(struct gntdev
* to the kernel linear addresses of the struct pages.
* These ptes are completely different from the user ptes dealt
* with find_grant_ptes.
+ * Note that GNTMAP_device_map isn't needed here: The
+ * dev_bus_addr output field gets consumed only from ->map_ops,
+ * and by not requesting it when mapping we also avoid needing
+ * to mirror dev_bus_addr into ->unmap_ops (and holding an extra
+ * reference to the page in the hypervisor).
*/
+ unsigned int flags = (map->flags & ~GNTMAP_device_map) |
+ GNTMAP_host_map;
+
for (i = 0; i < map->count; i++) {
unsigned long address = (unsigned long)
pfn_to_kaddr(page_to_pfn(map->pages[i]));
BUG_ON(PageHighMem(map->pages[i]));
- gnttab_set_map_op(&map->kmap_ops[i], address,
- map->flags | GNTMAP_host_map,
+ gnttab_set_map_op(&map->kmap_ops[i], address, flags,
map->grants[i].ref,
map->grants[i].domid);
gnttab_set_unmap_op(&map->kunmap_ops[i], address,
- map->flags | GNTMAP_host_map, -1);
+ flags, -1);
}
}
@@ -336,17 +343,12 @@ int gntdev_map_grant_pages(struct gntdev
continue;
}
+ if (map->flags & GNTMAP_device_map)
+ map->unmap_ops[i].dev_bus_addr = map->map_ops[i].dev_bus_addr;
+
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (use_ptemod)
map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
-#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
- else if (map->dma_vaddr) {
- unsigned long bfn;
-
- bfn = pfn_to_bfn(page_to_pfn(map->pages[i]));
- map->unmap_ops[i].dev_bus_addr = __pfn_to_phys(bfn);
- }
-#endif
}
return err;
}
From: Jan Beulich <[email protected]>
commit b512e1b077e5ccdbd6e225b15d934ab12453b70a upstream.
We should not set up further state if either mapping failed; paying
attention to just the user mapping's status isn't enough.
Also use GNTST_okay instead of implying its value (zero).
This is part of XSA-361.
Signed-off-by: Jan Beulich <[email protected]>
Cc: [email protected]
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/xen/p2m.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -712,7 +712,8 @@ int set_foreign_p2m_mapping(struct gntta
unsigned long mfn, pfn;
/* Do not add to override if the map failed. */
- if (map_ops[i].status)
+ if (map_ops[i].status != GNTST_okay ||
+ (kmap_ops && kmap_ops[i].status != GNTST_okay))
continue;
if (map_ops[i].flags & GNTMAP_contains_pte) {
From: Jan Beulich <[email protected]>
commit ebee0eab08594b2bd5db716288a4f1ae5936e9bc upstream.
Failure of the kernel part of the mapping operation should also be
indicated as an error to the caller, or else it may assume the
respective kernel VA is okay to access.
Furthermore gnttab_map_refs() failing still requires recording
successfully mapped handles, so they can be unmapped subsequently. This
in turn requires there to be a way to tell full hypercall failure from
partial success - preset map_op status fields such that they won't
"happen" to look as if the operation succeeded.
Also again use GNTST_okay instead of implying its value (zero).
This is part of XSA-361.
Signed-off-by: Jan Beulich <[email protected]>
Cc: [email protected]
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/gntdev.c | 17 +++++++++--------
include/xen/grant_table.h | 1 +
2 files changed, 10 insertions(+), 8 deletions(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -334,21 +334,22 @@ int gntdev_map_grant_pages(struct gntdev
pr_debug("map %d+%d\n", map->index, map->count);
err = gnttab_map_refs(map->map_ops, use_ptemod ? map->kmap_ops : NULL,
map->pages, map->count);
- if (err)
- return err;
for (i = 0; i < map->count; i++) {
- if (map->map_ops[i].status) {
+ if (map->map_ops[i].status == GNTST_okay)
+ map->unmap_ops[i].handle = map->map_ops[i].handle;
+ else if (!err)
err = -EINVAL;
- continue;
- }
if (map->flags & GNTMAP_device_map)
map->unmap_ops[i].dev_bus_addr = map->map_ops[i].dev_bus_addr;
- map->unmap_ops[i].handle = map->map_ops[i].handle;
- if (use_ptemod)
- map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
+ if (use_ptemod) {
+ if (map->kmap_ops[i].status == GNTST_okay)
+ map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
+ else if (!err)
+ err = -EINVAL;
+ }
}
return err;
}
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -157,6 +157,7 @@ gnttab_set_map_op(struct gnttab_map_gran
map->flags = flags;
map->ref = ref;
map->dom = domid;
+ map->status = 1; /* arbitrary positive value */
}
static inline void
From: Jan Beulich <[email protected]>
commit 7c77474b2d22176d2bfb592ec74e0f2cb71352c9 upstream.
In particular -ENOMEM may come back here, from set_foreign_p2m_mapping().
Don't make problems worse, the more that handling elsewhere (together
with map's status fields now indicating whether a mapping wasn't even
attempted, and hence has to be considered failed) doesn't require this
odd way of dealing with errors.
This is part of XSA-362.
Signed-off-by: Jan Beulich <[email protected]>
Cc: [email protected]
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/xen-scsiback.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -386,12 +386,12 @@ static int scsiback_gnttab_data_map_batc
return 0;
err = gnttab_map_refs(map, NULL, pg, cnt);
- BUG_ON(err);
for (i = 0; i < cnt; i++) {
if (unlikely(map[i].status != GNTST_okay)) {
pr_err("invalid buffer -- could not remap it\n");
map[i].handle = SCSIBACK_INVALID_HANDLE;
- err = -ENOMEM;
+ if (!err)
+ err = -ENOMEM;
} else {
get_page(pg[i]);
}
From: Stefano Stabellini <[email protected]>
commit 36bf1dfb8b266e089afa9b7b984217f17027bf35 upstream.
set_phys_to_machine can fail due to lack of memory, see the kzalloc call
in arch/arm/xen/p2m.c:__set_phys_to_machine_multi.
Don't ignore the potential return error in set_foreign_p2m_mapping,
returning it to the caller instead.
This is part of XSA-361.
Signed-off-by: Stefano Stabellini <[email protected]>
Cc: [email protected]
Reviewed-by: Julien Grall <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/xen/p2m.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -95,8 +95,10 @@ int set_foreign_p2m_mapping(struct gntta
for (i = 0; i < count; i++) {
if (map_ops[i].status)
continue;
- set_phys_to_machine(map_ops[i].host_addr >> XEN_PAGE_SHIFT,
- map_ops[i].dev_bus_addr >> XEN_PAGE_SHIFT);
+ if (unlikely(!set_phys_to_machine(map_ops[i].host_addr >> XEN_PAGE_SHIFT,
+ map_ops[i].dev_bus_addr >> XEN_PAGE_SHIFT))) {
+ return -ENOMEM;
+ }
}
return 0;
From: Jan Beulich <[email protected]>
commit 3194a1746e8aabe86075fd3c5e7cf1f4632d7f16 upstream.
In particular -ENOMEM may come back here, from set_foreign_p2m_mapping().
Don't make problems worse, the more that handling elsewhere (together
with map's status fields now indicating whether a mapping wasn't even
attempted, and hence has to be considered failed) doesn't require this
odd way of dealing with errors.
This is part of XSA-362.
Signed-off-by: Jan Beulich <[email protected]>
Cc: [email protected]
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/xen-netback/netback.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1342,13 +1342,11 @@ int xenvif_tx_action(struct xenvif_queue
return 0;
gnttab_batch_copy(queue->tx_copy_ops, nr_cops);
- if (nr_mops != 0) {
+ if (nr_mops != 0)
ret = gnttab_map_refs(queue->tx_map_ops,
NULL,
queue->pages_to_map,
nr_mops);
- BUG_ON(ret);
- }
work_done = xenvif_tx_submit(queue);
From: Jan Beulich <[email protected]>
commit 5a264285ed1cd32e26d9de4f3c8c6855e467fd63 upstream.
In particular -ENOMEM may come back here, from set_foreign_p2m_mapping().
Don't make problems worse, the more that handling elsewhere (together
with map's status fields now indicating whether a mapping wasn't even
attempted, and hence has to be considered failed) doesn't require this
odd way of dealing with errors.
This is part of XSA-362.
Signed-off-by: Jan Beulich <[email protected]>
Cc: [email protected]
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/block/xen-blkback/blkback.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -811,10 +811,8 @@ again:
break;
}
- if (segs_to_map) {
+ if (segs_to_map)
ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
- BUG_ON(ret);
- }
/*
* Now swizzle the MFN in our domain with the MFN from the other domain
@@ -830,7 +828,7 @@ again:
gnttab_page_cache_put(&ring->free_pages,
&pages[seg_idx]->page, 1);
pages[seg_idx]->handle = BLKBACK_INVALID_HANDLE;
- ret |= 1;
+ ret |= !ret;
goto next;
}
pages[seg_idx]->handle = map[new_map_idx].handle;
From: Jan Beulich <[email protected]>
commit 871997bc9e423f05c7da7c9178e62dde5df2a7f8 upstream.
The function uses a goto-based loop, which may lead to an earlier error
getting discarded by a later iteration. Exit this ad-hoc loop when an
error was encountered.
The out-of-memory error path additionally fails to fill a structure
field looked at by xen_blkbk_unmap_prepare() before inspecting the
handle which does get properly set (to BLKBACK_INVALID_HANDLE).
Since the earlier exiting from the ad-hoc loop requires the same field
filling (invalidation) as that on the out-of-memory path, fold both
paths. While doing so, drop the pr_alert(), as extra log messages aren't
going to help the situation (the kernel will log oom conditions already
anyway).
This is XSA-365.
Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Reviewed-by: Julien Grall <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/block/xen-blkback/blkback.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -794,8 +794,13 @@ again:
pages[i]->persistent_gnt = persistent_gnt;
} else {
if (gnttab_page_cache_get(&ring->free_pages,
- &pages[i]->page))
- goto out_of_memory;
+ &pages[i]->page)) {
+ gnttab_page_cache_put(&ring->free_pages,
+ pages_to_gnt,
+ segs_to_map);
+ ret = -ENOMEM;
+ goto out;
+ }
addr = vaddr(pages[i]->page);
pages_to_gnt[segs_to_map] = pages[i]->page;
pages[i]->persistent_gnt = NULL;
@@ -880,17 +885,18 @@ next:
}
segs_to_map = 0;
last_map = map_until;
- if (map_until != num)
+ if (!ret && map_until != num)
goto again;
- return ret;
-
-out_of_memory:
- pr_alert("%s: out of memory\n", __func__);
- gnttab_page_cache_put(&ring->free_pages, pages_to_gnt, segs_to_map);
- for (i = last_map; i < num; i++)
+out:
+ for (i = last_map; i < num; i++) {
+ /* Don't zap current batch's valid persistent grants. */
+ if(i >= last_map + segs_to_map)
+ pages[i]->persistent_gnt = NULL;
pages[i]->handle = BLKBACK_INVALID_HANDLE;
- return -ENOMEM;
+ }
+
+ return ret;
}
static int xen_blkbk_map_seg(struct pending_req *pending_req)
On Mon, 22 Feb 2021 at 17:43, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.11.1 release.
> There are 12 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.1-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.11.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <[email protected]>
NOTE:
1) We (LKFT) have upgraded clang-10 to clang-12 builds and following
three new configs enabled.
CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_HAVE_KCSAN_COMPILER=y
2) on qemu_x86_64_clang-12 a large number of LTP tests reported failures
on stable-rc 5.4, 5.10, 5.11 and Linux mainline.
reported link,
https://lore.kernel.org/lkml/CA+G9fYuE4ELVDju=LESHnphL4Z2DT5YQjdh9rNgr5D1x5gZxgg@mail.gmail.com/
Summary
------------------------------------------------------------------------
kernel: 5.11.1-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.11.y
git commit: 6380656c9227c27a989f750aa7a0c81039d28607
git describe: v5.11-13-g6380656c9227
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.11.y/build/v5.11-13-g6380656c9227
No regressions (compared to build v5.11)
No fixes (compared to build v5.11)
Ran 52054 total tests in the following environments and test suites.
Environments
--------------
- arc
- arm
- arm64
- dragonboard-410c
- dragonboard-845c
- hi6220-hikey
- i386
- juno-64k_page_size
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- nxp-ls2088-64k_page_size
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan
- x86_64
Test Suites
-----------
* build
* linux-log-parser
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-lkdtm
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-tracing-tests
* perf
* kvm-unit-tests
* libhugetlbfs
* ltp-controllers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-sched-tests
* fwts
* kselftest-intel_pstate
* kselftest-livepatch
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-ptrace
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* ltp-syscalls-tests
* network-basic-tests
* v4l2-compliance
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-vm
* kselftest-x86
* ltp-open-posix-tests
* rcutorture
* kunit
--
Linaro LKFT
https://lkft.linaro.org
On Mon, Feb 22, 2021 at 01:12:52PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.11.1 release.
> There are 12 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 435 pass: 435 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter
On Mon, Feb 22, 2021 at 01:29:17PM -0800, Guenter Roeck wrote:
> On Mon, Feb 22, 2021 at 01:12:52PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.11.1 release.
> > There are 12 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 24 Feb 2021 12:07:46 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 155 pass: 155 fail: 0
> Qemu test results:
> total: 435 pass: 435 fail: 0
>
> Tested-by: Guenter Roeck <[email protected]>
Thanks for testing them all and letting me know.
greg k-h
On Tue, Feb 23, 2021 at 01:10:19AM +0530, Naresh Kamboju wrote:
> On Mon, 22 Feb 2021 at 17:43, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.11.1 release.
> > There are 12 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 24 Feb 2021 12:07:46 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.1-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.11.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
>
> Tested-by: Linux Kernel Functional Testing <[email protected]>
Thanks for testing them all and letting me know.
greg k-h
On 2/22/21 5:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.11.1 release.
> There are 12 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 24 Feb 2021 12:07:46 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.1-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.11.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
I made some progress on the drm/amdgpu display and kepboard
problem.
My system has
amdgpu: ATOM BIOS: 113-RENOIR-026
I narrowed it down to the following as a possible lead to
start looking:
amdgpu 0000:0b:00.0: [drm] Cannot find any crtc or sizes
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
On 2/23/21 2:05 PM, Shuah Khan wrote:
> On 2/22/21 5:12 AM, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 5.11.1 release.
>> There are 12 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Wed, 24 Feb 2021 12:07:46 +0000.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.1-rc1.gz
>>
>> or in the git tree and branch at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> linux-5.11.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>>
>
> Compiled and booted on my test system. No dmesg regressions.
>
> I made some progress on the drm/amdgpu display and kepboard
> problem.
>
> My system has
> amdgpu: ATOM BIOS: 113-RENOIR-026
>
> I narrowed it down to the following as a possible lead to
> start looking:
> amdgpu 0000:0b:00.0: [drm] Cannot find any crtc or sizes
>
It is resolved now. A hot-unplugged/plugged the HDMI cable which
triggered reset sequence. There might be link to AMD_DC_HDCP
support, amdgpu_dm_atomic_commit changes that went into 5.10 and
this behavior.
I am basing this on not seeing the problem on Linux 5.4 and until
Linux 5.10. In any case, I wish I know more, but life is back to
normal now.
When I hot-unplugged/plugged the cable, saw the following dmesg:
amdgpu 0000:0b:00.0: [drm] fb0: amdgpudrmfb frame buffer device
kernel: [ 6704.580326] [drm:drm_atomic_helper_wait_for_flip_done
[drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out
kernel: [ 6773.444316] [drm:drm_atomic_helper_wait_for_dependencies
[drm_kms_helper]] *ERROR* [CRTC:67:crtc-0] flip_done timed out
kernel: [ 6783.684306] [drm:drm_atomic_helper_wait_for_dependencies
[drm_kms_helper]] *ERROR* [PLANE:55:plane-3] flip_done timed out
The following
WARN_ON(acrtc_attach->pflip_status != AMDGPU_FLIP_NONE); fires:
kernel: [ 6783.750035] WARNING: CPU: 7 PID: 190 at
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7754
amdgpu_dm_atomic_commit_tail+0x2542/0x25d0 [amdgpu]
Feb 23 16:20:39 shuah-IC5 kernel: [ 6783.750392] Modules linked in:
btrfs blake2b_generic xor raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos
jfs xfs libcrc32c rfcomm ccm cmac algif_hash algif_skcipher af_alg bnep
intel_rapl_msr intel_rapl_common amdgpu edac_mce_amd
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio nls_iso8859_1
snd_hda_codec_hdmi snd_hda_intel kvm_amd snd_intel_dspcfg snd_hda_codec
kvm snd_hda_core ath10k_pci snd_hwdep snd_pcm crct10dif_pclmul
ath10k_core ghash_clmulni_intel ath iommu_v2 snd_seq_midi gpu_sched
aesni_intel snd_seq_midi_event drm_ttm_helper mac80211 ttm snd_rawmidi
btusb drm_kms_helper crypto_simd btrtl snd_seq cryptd btbcm rtsx_usb_ms
cec glue_helper btintel snd_seq_device snd_timer rapl memstick rc_core
bluetooth cfg80211 i2c_algo_bit snd fb_sys_fops syscopyarea sysfillrect
snd_rn_pci_acp3x ecdh_generic wmi_bmof sysimgblt efi_pstore soundcore
ccp joydev ecc k10temp input_leds snd_pci_acp3x libarc4 mac_hid
sch_fq_codel parport_pc ppdev lp parport drm ip_tables x_tables autofs4
Feb 23 16:20:39 shuah-IC5 kernel: [ 6783.750506] hid_generic usbhid
rtsx_usb_sdmmc hid rtsx_usb nvme crc32_pclmul i2c_piix4 r8169 nvme_core
ahci xhci_pci realtek libahci xhci_pci_renesas wmi video gpio_amdpt
gpio_generic
kernel: [ 6783.750532] CPU: 7 PID: 190 Comm: kworker/7:1 Not tainted
5.11.1 #1
kernel: [ 6783.750537] Hardware name: LENOVO 90Q30008US/3728, BIOS
O4ZKT1CA 09/16/2020
kernel: [ 6783.750541] Workqueue: events dm_irq_work_func [amdgpu]
kernel: [ 6783.750859] RIP:
0010:amdgpu_dm_atomic_commit_tail+0x2542/0x25d0 [amdgpu]
kernel: [ 6783.751159] Code: a0 fd ff ff 01 c7 85 9c fd ff ff 37 00 00
00 c7 85 a4 fd ff ff 20 00 00 00 e8 ca ef 12 00 e9 e9 fa ff ff 0f 0b e9
39 f9 ff ff <0f> 0b e9 88 f9 ff ff 0f 0b 0f 0b e9 9e f9 ff ff 49 8b 06
41 0f b6
kernel: [ 6783.751162] RSP: 0018:ffffac390068fa48 EFLAGS: 00010002
kernel: [ 6783.751167] RAX: 0000000000000002 RBX: 0000000000000004 RCX:
ffff9604442d7918
kernel: [ 6783.751169] RDX: 0000000000000001 RSI: 0000000000000297 RDI:
ffff960444a80188
kernel: [ 6783.751172] RBP: ffffac390068fd48 R08: 0000000000000005 R09:
0000000000000000
kernel: [ 6783.751174] R10: ffffac390068f998 R11: ffffac390068f99c R12:
0000000000000297
kernel: [ 6783.751176] R13: ffff96048d131a00 R14: ffff9604442d7800 R15:
ffff96048da29c00
kernel: [ 6783.751179] FS: 0000000000000000(0000)
GS:ffff96073f1c0000(0000) knlGS:0000000000000000
kernel: [ 6783.751182] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: [ 6783.751185] CR2: 00005612d2a1a000 CR3: 0000000030010000 CR4:
0000000000350ee0
kernel: [ 6783.751188] Call Trace:
kernel: [ 6783.751197] ? irq_work_queue+0x2a/0x40
kernel: [ 6783.751205] ? vprintk_emit+0x139/0x240
kernel: [ 6783.751218] commit_tail+0x99/0x130 [drm_kms_helper]
kernel: [ 6783.751247] drm_atomic_helper_commit+0x123/0x150
[drm_kms_helper]
kernel: [ 6783.751273] drm_atomic_commit+0x4a/0x50 [drm]
kernel: [ 6783.751323] dm_restore_drm_connector_state+0xf3/0x170 [amdgpu]
kernel: [ 6783.751628] handle_hpd_irq+0x11a/0x150 [amdgpu]
kernel: [ 6783.751923] dm_irq_work_func+0x4e/0x60 [amdgpu]
kernel: [ 6783.752018] process_one_work+0x220/0x3c0
kernel: [ 6783.752018] worker_thread+0x53/0x420
kernel: [ 6783.752018] kthread+0x12f/0x150
kernel: [ 6783.752018] ? process_one_work+0x3c0/0x3c0
kernel: [ 6783.752018] ? __kthread_bind_mask+0x70/0x70
kernel: [ 6783.752018] ret_from_fork+0x22/0x30
thanks,
-- Shuah
On Tue, Feb 23, 2021 at 05:12:56PM -0700, Shuah Khan wrote:
> On 2/23/21 2:05 PM, Shuah Khan wrote:
> > On 2/22/21 5:12 AM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.11.1 release.
> > > There are 12 patches in this series, all will be posted as a response
> > > to this one.? If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Wed, 24 Feb 2021 12:07:46 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > ????https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.1-rc1.gz
> > >
> > > or in the git tree and branch at:
> > > ????git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > linux-5.11.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> >
> > Compiled and booted on my test system. No dmesg regressions.
> >
> > I made some progress on the drm/amdgpu display and kepboard
> > problem.
> >
> > My system has
> > ?amdgpu: ATOM BIOS: 113-RENOIR-026
> >
> > I narrowed it down to the following as a possible lead to
> > start looking:
> > amdgpu 0000:0b:00.0: [drm] Cannot find any crtc or sizes
> >
>
> It is resolved now. A hot-unplugged/plugged the HDMI cable which
> triggered reset sequence. There might be link to AMD_DC_HDCP
> support, amdgpu_dm_atomic_commit changes that went into 5.10 and
> this behavior.
>
> I am basing this on not seeing the problem on Linux 5.4 and until
> Linux 5.10. In any case, I wish I know more, but life is back to
> normal now.
Great, thanks for testing and tracking this down.
greg k-h