* [PATCH 5.4 01/13] KVM: SEV: fix double locking due to incorrect backport
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 02/13] net: qrtr: Fix port ID for control messages Greg Kroah-Hartman
` (17 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dov Murik, Paolo Bonzini, Sasha Levin
From: Paolo Bonzini <pbonzini@redhat.com>
Fix an incorrect line in the 5.4.y and 4.19.y backports of commit
19a23da53932bc ("Fix unsynchronized access to sev members through
svm_register_enc_region"), first applied to 5.4.98 and 4.19.176.
Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active")
Reported-by: Dov Murik <dovmurik@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # 5.4.x
Cc: stable@vger.kernel.org # 4.19.x
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/kvm/svm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 296b0d7570d06..1da558f28aa57 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -7104,7 +7104,6 @@ static int svm_register_enc_region(struct kvm *kvm,
region->uaddr = range->addr;
region->size = range->size;
- mutex_lock(&kvm->lock);
list_add_tail(®ion->list, &sev->regions_list);
mutex_unlock(&kvm->lock);
--
2.27.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 5.4 02/13] net: qrtr: Fix port ID for control messages
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 01/13] KVM: SEV: fix double locking due to incorrect backport Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 03/13] net: bridge: Fix a warning when del bridge sysfs Greg Kroah-Hartman
` (16 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Loic Poulain, Jakub Kicinski, Sasha Levin
From: Loic Poulain <loic.poulain@linaro.org>
[ Upstream commit ae068f561baa003d260475c3e441ca454b186726 ]
The port ID for control messages was uncorrectly set with broadcast
node ID value, causing message to be dropped on remote side since
not passing packet filtering (cb->dst_port != QRTR_PORT_CTRL).
Fixes: d27e77a3de28 ("net: qrtr: Reset the node and port ID of broadcast messages")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/qrtr/qrtr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index d6d2736ec9273..ef602976bb2c8 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -187,7 +187,7 @@ static int qrtr_node_enqueue(struct qrtr_node *node, struct sk_buff *skb,
hdr->src_port_id = cpu_to_le32(from->sq_port);
if (to->sq_port == QRTR_PORT_CTRL) {
hdr->dst_node_id = cpu_to_le32(node->nid);
- hdr->dst_port_id = cpu_to_le32(QRTR_NODE_BCAST);
+ hdr->dst_port_id = cpu_to_le32(QRTR_PORT_CTRL);
} else {
hdr->dst_node_id = cpu_to_le32(to->sq_node);
hdr->dst_port_id = cpu_to_le32(to->sq_port);
--
2.27.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 5.4 03/13] net: bridge: Fix a warning when del bridge sysfs
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 01/13] KVM: SEV: fix double locking due to incorrect backport Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 02/13] net: qrtr: Fix port ID for control messages Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 04/13] Xen/x86: dont bail early from clear_foreign_p2m_mapping() Greg Kroah-Hartman
` (15 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hulk Robot, Wang Hai,
Nikolay Aleksandrov, Jakub Kicinski, Sasha Levin
From: Wang Hai <wanghai38@huawei.com>
[ Upstream commit 989a1db06eb18ff605377eec87e18d795e0ec74b ]
I got a warining report:
br_sysfs_addbr: can't create group bridge4/bridge
------------[ cut here ]------------
sysfs group 'bridge' not found for kobject 'bridge4'
WARNING: CPU: 2 PID: 9004 at fs/sysfs/group.c:279 sysfs_remove_group fs/sysfs/group.c:279 [inline]
WARNING: CPU: 2 PID: 9004 at fs/sysfs/group.c:279 sysfs_remove_group+0x153/0x1b0 fs/sysfs/group.c:270
Modules linked in: iptable_nat
...
Call Trace:
br_dev_delete+0x112/0x190 net/bridge/br_if.c:384
br_dev_newlink net/bridge/br_netlink.c:1381 [inline]
br_dev_newlink+0xdb/0x100 net/bridge/br_netlink.c:1362
__rtnl_newlink+0xe11/0x13f0 net/core/rtnetlink.c:3441
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500
rtnetlink_rcv_msg+0x385/0x980 net/core/rtnetlink.c:5562
netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2494
netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1330
netlink_sendmsg+0x793/0xc80 net/netlink/af_netlink.c:1919
sock_sendmsg_nosec net/socket.c:651 [inline]
sock_sendmsg+0x139/0x170 net/socket.c:671
____sys_sendmsg+0x658/0x7d0 net/socket.c:2353
___sys_sendmsg+0xf8/0x170 net/socket.c:2407
__sys_sendmsg+0xd3/0x190 net/socket.c:2440
do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
In br_device_event(), if the bridge sysfs fails to be added,
br_device_event() should return error. This can prevent warining
when removing bridge sysfs that do not exist.
Fixes: bb900b27a2f4 ("bridge: allow creating bridge devices with netlink")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Tested-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Link: https://lore.kernel.org/r/20201211122921.40386-1-wanghai38@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bridge/br.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br.c b/net/bridge/br.c
index 8a8f9e5f264f2..cccbb9bf3ca4e 100644
--- a/net/bridge/br.c
+++ b/net/bridge/br.c
@@ -43,7 +43,10 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
if (event == NETDEV_REGISTER) {
/* register of bridge completed, add sysfs entries */
- br_sysfs_addbr(dev);
+ err = br_sysfs_addbr(dev);
+ if (err)
+ return notifier_from_errno(err);
+
return NOTIFY_DONE;
}
}
--
2.27.0
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH 5.4 04/13] Xen/x86: dont bail early from clear_foreign_p2m_mapping()
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 03/13] net: bridge: Fix a warning when del bridge sysfs Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 05/13] Xen/x86: also check kernel mapping in set_foreign_p2m_mapping() Greg Kroah-Hartman
` (14 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jan Beulich, Juergen Gross
From: Jan Beulich <jbeulich@suse.com>
commit a35f2ef3b7376bfd0a57f7844bd7454389aae1fc upstream.
Its sibling (set_foreign_p2m_mapping()) as well as the sibling of its
only caller (gnttab_map_refs()) don't clean up after themselves in case
of error. Higher level callers are expected to do so. However, in order
for that to really clean up any partially set up state, the operation
should not terminate upon encountering an entry in unexpected state. It
is particularly relevant to notice here that set_foreign_p2m_mapping()
would skip setting up a p2m entry if its grant mapping failed, but it
would continue to set up further p2m entries as long as their mappings
succeeded.
Arguably down the road set_foreign_p2m_mapping() may want its page state
related WARN_ON() also converted to an error return.
This is part of XSA-361.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/xen/p2m.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -754,17 +754,15 @@ int clear_foreign_p2m_mapping(struct gnt
unsigned long mfn = __pfn_to_mfn(page_to_pfn(pages[i]));
unsigned long pfn = page_to_pfn(pages[i]);
- if (mfn == INVALID_P2M_ENTRY || !(mfn & FOREIGN_FRAME_BIT)) {
+ if (mfn != INVALID_P2M_ENTRY && (mfn & FOREIGN_FRAME_BIT))
+ set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+ else
ret = -EINVAL;
- goto out;
- }
-
- set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
}
if (kunmap_ops)
ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
- kunmap_ops, count);
-out:
+ kunmap_ops, count) ?: ret;
+
return ret;
}
EXPORT_SYMBOL_GPL(clear_foreign_p2m_mapping);
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.4 05/13] Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 04/13] Xen/x86: dont bail early from clear_foreign_p2m_mapping() Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 06/13] Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages() Greg Kroah-Hartman
` (13 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jan Beulich, Juergen Gross
From: Jan Beulich <jbeulich@suse.com>
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 <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
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
@@ -716,7 +716,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) {
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.4 06/13] Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 05/13] Xen/x86: also check kernel mapping in set_foreign_p2m_mapping() Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 07/13] Xen/gntdev: correct error checking " Greg Kroah-Hartman
` (12 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jan Beulich, Stefano Stabellini,
Juergen Gross
From: Jan Beulich <jbeulich@suse.com>
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 <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/xen/gntdev.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -319,18 +319,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);
}
}
@@ -346,17 +353,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;
}
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.4 07/13] Xen/gntdev: correct error checking in gntdev_map_grant_pages()
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 06/13] Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages() Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 08/13] xen/arm: dont ignore return errors from set_phys_to_machine Greg Kroah-Hartman
` (11 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jan Beulich, Juergen Gross
From: Jan Beulich <jbeulich@suse.com>
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 <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
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
@@ -344,21 +344,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
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.4 08/13] xen/arm: dont ignore return errors from set_phys_to_machine
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 07/13] Xen/gntdev: correct error checking " Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 09/13] xen-blkback: dont "handle" error by BUG() Greg Kroah-Hartman
` (10 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefano Stabellini, Julien Grall,
Juergen Gross
From: Stefano Stabellini <stefano.stabellini@xilinx.com>
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 <stefano.stabellini@xilinx.com>
Cc: stable@vger.kernel.org
Reviewed-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
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;
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.4 09/13] xen-blkback: dont "handle" error by BUG()
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 08/13] xen/arm: dont ignore return errors from set_phys_to_machine Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 10/13] xen-netback: " Greg Kroah-Hartman
` (9 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jan Beulich, Juergen Gross
From: Jan Beulich <jbeulich@suse.com>
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 <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
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
@@ -867,10 +867,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
@@ -885,7 +883,7 @@ again:
pr_debug("invalid buffer -- could not remap it\n");
put_free_pages(ring, &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;
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.4 10/13] xen-netback: dont "handle" error by BUG()
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 09/13] xen-blkback: dont "handle" error by BUG() Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 11/13] xen-scsiback: " Greg Kroah-Hartman
` (8 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jan Beulich, Juergen Gross
From: Jan Beulich <jbeulich@suse.com>
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 <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
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
@@ -1335,13 +1335,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);
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.4 11/13] xen-scsiback: dont "handle" error by BUG()
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 10/13] xen-netback: " Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 12/13] xen-blkback: fix error handling in xen_blkbk_map() Greg Kroah-Hartman
` (7 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jan Beulich, Juergen Gross
From: Jan Beulich <jbeulich@suse.com>
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 <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
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
@@ -422,12 +422,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]);
}
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.4 12/13] xen-blkback: fix error handling in xen_blkbk_map()
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 11/13] xen-scsiback: " Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 12:13 ` [PATCH 5.4 13/13] media: pwc: Use correct device for DMA Greg Kroah-Hartman
` (6 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jan Beulich, Juergen Gross, Julien Grall
From: Jan Beulich <jbeulich@suse.com>
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 <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Julien Grall <julien@xen.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/xen-blkback/blkback.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -850,8 +850,11 @@ again:
pages[i]->page = persistent_gnt->page;
pages[i]->persistent_gnt = persistent_gnt;
} else {
- if (get_free_page(ring, &pages[i]->page))
- goto out_of_memory;
+ if (get_free_page(ring, &pages[i]->page)) {
+ put_free_pages(ring, 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;
@@ -935,17 +938,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__);
- put_free_pages(ring, 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)
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.4 13/13] media: pwc: Use correct device for DMA
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 12/13] xen-blkback: fix error handling in xen_blkbk_map() Greg Kroah-Hartman
@ 2021-02-22 12:13 ` Greg Kroah-Hartman
2021-02-22 18:10 ` [PATCH 5.4 00/13] 5.4.100-rc1 review Florian Fainelli
` (5 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-22 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matwey V. Kornilov, Hans Verkuil,
Mauro Carvalho Chehab
From: Matwey V. Kornilov <matwey@sai.msu.ru>
commit 69c9e825e812ec6d663e64ebf14bd3bc7f37e2c7 upstream.
This fixes the following newly introduced warning:
[ 15.518253] ------------[ cut here ]------------
[ 15.518941] WARNING: CPU: 0 PID: 246 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x1a8/0x1d0
[ 15.520634] Modules linked in: pwc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc efivarfs
[ 15.522335] CPU: 0 PID: 246 Comm: v4l2-test Not tainted 5.11.0-rc1+ #1
[ 15.523281] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[ 15.524438] RIP: 0010:dma_map_page_attrs+0x1a8/0x1d0
[ 15.525135] Code: 10 5b 5d 41 5c 41 5d c3 4d 89 d0 eb d7 4d 89 c8 89 e9 48 89 da e8 68 29 00 00 eb d1 48 89 f2 48 2b 50 18 48 89 d0 eb 83 0f 0b <0f> 0b 48 c7 c0 ff ff ff ff eb b8 48 89 d9 48 8b 40 40 e8 61 69 d2
[ 15.527938] RSP: 0018:ffffa2694047bca8 EFLAGS: 00010246
[ 15.528716] RAX: 0000000000000000 RBX: 0000000000002580 RCX: 0000000000000000
[ 15.529782] RDX: 0000000000000000 RSI: ffffcdce000ecc00 RDI: ffffa0b4bdb888a0
[ 15.530849] RBP: 0000000000000002 R08: 0000000000000002 R09: 0000000000000000
[ 15.531881] R10: 0000000000000004 R11: 000000000002d8c0 R12: 0000000000000000
[ 15.532911] R13: ffffa0b4bdb88800 R14: ffffa0b483820000 R15: ffffa0b4bdb888a0
[ 15.533942] FS: 00007fc5fbb5e4c0(0000) GS:ffffa0b4fc000000(0000) knlGS:0000000000000000
[ 15.535141] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 15.535988] CR2: 00007fc5fb6ea138 CR3: 0000000003812000 CR4: 00000000001506f0
[ 15.537025] Call Trace:
[ 15.537425] start_streaming+0x2e9/0x4b0 [pwc]
[ 15.538143] vb2_start_streaming+0x5e/0x110 [videobuf2_common]
[ 15.538989] vb2_core_streamon+0x107/0x140 [videobuf2_common]
[ 15.539831] __video_do_ioctl+0x18f/0x4a0 [videodev]
[ 15.540670] video_usercopy+0x13a/0x5b0 [videodev]
[ 15.541349] ? video_put_user+0x230/0x230 [videodev]
[ 15.542096] ? selinux_file_ioctl+0x143/0x200
[ 15.542752] v4l2_ioctl+0x40/0x50 [videodev]
[ 15.543360] __x64_sys_ioctl+0x89/0xc0
[ 15.543930] do_syscall_64+0x33/0x40
[ 15.544448] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 15.545236] RIP: 0033:0x7fc5fb671587
[ 15.545780] Code: b3 66 90 48 8b 05 11 49 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 48 2c 00 f7 d8 64 89 01 48
[ 15.548486] RSP: 002b:00007fff0f71f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 15.549578] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc5fb671587
[ 15.550664] RDX: 00007fff0f71f060 RSI: 0000000040045612 RDI: 0000000000000003
[ 15.551706] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 15.552738] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff0f71f060
[ 15.553817] R13: 00007fff0f71f1d0 R14: 0000000000de1270 R15: 0000000000000000
[ 15.554914] ---[ end trace 7be03122966c2486 ]---
Fixes: 1161db6776bd ("media: usb: pwc: Don't use coherent DMA buffers for ISO transfer")
Signed-off-by: Matwey V. Kornilov <matwey@sai.msu.ru>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/pwc/pwc-if.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -147,16 +147,17 @@ static const struct video_device pwc_tem
/***************************************************************************/
/* Private functions */
-static void *pwc_alloc_urb_buffer(struct device *dev,
+static void *pwc_alloc_urb_buffer(struct usb_device *dev,
size_t size, dma_addr_t *dma_handle)
{
+ struct device *dmadev = dev->bus->sysdev;
void *buffer = kmalloc(size, GFP_KERNEL);
if (!buffer)
return NULL;
- *dma_handle = dma_map_single(dev, buffer, size, DMA_FROM_DEVICE);
- if (dma_mapping_error(dev, *dma_handle)) {
+ *dma_handle = dma_map_single(dmadev, buffer, size, DMA_FROM_DEVICE);
+ if (dma_mapping_error(dmadev, *dma_handle)) {
kfree(buffer);
return NULL;
}
@@ -164,12 +165,14 @@ static void *pwc_alloc_urb_buffer(struct
return buffer;
}
-static void pwc_free_urb_buffer(struct device *dev,
+static void pwc_free_urb_buffer(struct usb_device *dev,
size_t size,
void *buffer,
dma_addr_t dma_handle)
{
- dma_unmap_single(dev, dma_handle, size, DMA_FROM_DEVICE);
+ struct device *dmadev = dev->bus->sysdev;
+
+ dma_unmap_single(dmadev, dma_handle, size, DMA_FROM_DEVICE);
kfree(buffer);
}
@@ -274,6 +277,7 @@ static void pwc_frame_complete(struct pw
static void pwc_isoc_handler(struct urb *urb)
{
struct pwc_device *pdev = (struct pwc_device *)urb->context;
+ struct device *dmadev = urb->dev->bus->sysdev;
int i, fst, flen;
unsigned char *iso_buf = NULL;
@@ -320,7 +324,7 @@ static void pwc_isoc_handler(struct urb
/* Reset ISOC error counter. We did get here, after all. */
pdev->visoc_errors = 0;
- dma_sync_single_for_cpu(&urb->dev->dev,
+ dma_sync_single_for_cpu(dmadev,
urb->transfer_dma,
urb->transfer_buffer_length,
DMA_FROM_DEVICE);
@@ -371,7 +375,7 @@ static void pwc_isoc_handler(struct urb
pdev->vlast_packet_size = flen;
}
- dma_sync_single_for_device(&urb->dev->dev,
+ dma_sync_single_for_device(dmadev,
urb->transfer_dma,
urb->transfer_buffer_length,
DMA_FROM_DEVICE);
@@ -453,7 +457,7 @@ retry:
urb->pipe = usb_rcvisocpipe(udev, pdev->vendpoint);
urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
urb->transfer_buffer_length = ISO_BUFFER_SIZE;
- urb->transfer_buffer = pwc_alloc_urb_buffer(&udev->dev,
+ urb->transfer_buffer = pwc_alloc_urb_buffer(udev,
urb->transfer_buffer_length,
&urb->transfer_dma);
if (urb->transfer_buffer == NULL) {
@@ -516,7 +520,7 @@ static void pwc_iso_free(struct pwc_devi
if (urb) {
PWC_DEBUG_MEMORY("Freeing URB\n");
if (urb->transfer_buffer)
- pwc_free_urb_buffer(&urb->dev->dev,
+ pwc_free_urb_buffer(urb->dev,
urb->transfer_buffer_length,
urb->transfer_buffer,
urb->transfer_dma);
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.4 00/13] 5.4.100-rc1 review
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2021-02-22 12:13 ` [PATCH 5.4 13/13] media: pwc: Use correct device for DMA Greg Kroah-Hartman
@ 2021-02-22 18:10 ` Florian Fainelli
2021-02-22 21:28 ` Guenter Roeck
` (4 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Florian Fainelli @ 2021-02-22 18:10 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, stable
On 2/22/2021 4:13 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.100 release.
> There are 13 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.4.100-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.4.y
> and the diffstat can be found below.
On ARCH_BRCMSTB with 32-bit ARM and 64-bit ARM kernels:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.4 00/13] 5.4.100-rc1 review
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2021-02-22 18:10 ` [PATCH 5.4 00/13] 5.4.100-rc1 review Florian Fainelli
@ 2021-02-22 21:28 ` Guenter Roeck
2021-02-22 21:35 ` Igor
` (3 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Guenter Roeck @ 2021-02-22 21:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, lkft-triage, pavel,
jonathanh, stable
On Mon, Feb 22, 2021 at 01:13:17PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.100 release.
> There are 13 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: 157 pass: 157 fail: 0
Qemu test results:
total: 429 pass: 429 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.4 00/13] 5.4.100-rc1 review
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2021-02-22 21:28 ` Guenter Roeck
@ 2021-02-22 21:35 ` Igor
2021-02-23 7:16 ` Naresh Kamboju
` (2 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: Igor @ 2021-02-22 21:35 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, stable, skhan
On Mon, Feb 22, 2021 at 01:13:17PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.100 release.
> There are 13 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.4.100-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my machine(x86_64) without any dmesg regression.
My compilation uses the default Debian 10 .config(From kernel
4.19.0-14-amd64), followed by olddefconfig.
Tested-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Best regards,
---
Igor Matheus Andrade Torrente
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Linux 5.4.100-rc1
>
> Matwey V. Kornilov <matwey@sai.msu.ru>
> media: pwc: Use correct device for DMA
>
> Jan Beulich <jbeulich@suse.com>
> xen-blkback: fix error handling in xen_blkbk_map()
>
> Jan Beulich <jbeulich@suse.com>
> xen-scsiback: don't "handle" error by BUG()
>
> Jan Beulich <jbeulich@suse.com>
> xen-netback: don't "handle" error by BUG()
>
> Jan Beulich <jbeulich@suse.com>
> xen-blkback: don't "handle" error by BUG()
>
> Stefano Stabellini <stefano.stabellini@xilinx.com>
> xen/arm: don't ignore return errors from set_phys_to_machine
>
> Jan Beulich <jbeulich@suse.com>
> Xen/gntdev: correct error checking in gntdev_map_grant_pages()
>
> Jan Beulich <jbeulich@suse.com>
> Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
>
> Jan Beulich <jbeulich@suse.com>
> Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
>
> Jan Beulich <jbeulich@suse.com>
> Xen/x86: don't bail early from clear_foreign_p2m_mapping()
>
> Wang Hai <wanghai38@huawei.com>
> net: bridge: Fix a warning when del bridge sysfs
>
> Loic Poulain <loic.poulain@linaro.org>
> net: qrtr: Fix port ID for control messages
>
> Paolo Bonzini <pbonzini@redhat.com>
> KVM: SEV: fix double locking due to incorrect backport
>
>
> -------------
>
> Diffstat:
>
> Makefile | 4 ++--
> arch/arm/xen/p2m.c | 6 ++++--
> arch/x86/kvm/svm.c | 1 -
> arch/x86/xen/p2m.c | 15 +++++++--------
> drivers/block/xen-blkback/blkback.c | 30 ++++++++++++++++--------------
> drivers/media/usb/pwc/pwc-if.c | 22 +++++++++++++---------
> drivers/net/xen-netback/netback.c | 4 +---
> drivers/xen/gntdev.c | 37 ++++++++++++++++++++-----------------
> drivers/xen/xen-scsiback.c | 4 ++--
> include/xen/grant_table.h | 1 +
> net/bridge/br.c | 5 ++++-
> net/qrtr/qrtr.c | 2 +-
> 12 files changed, 71 insertions(+), 60 deletions(-)
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.4 00/13] 5.4.100-rc1 review
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2021-02-22 21:35 ` Igor
@ 2021-02-23 7:16 ` Naresh Kamboju
2021-02-23 14:47 ` Jon Hunter
2021-02-23 21:12 ` Shuah Khan
18 siblings, 0 replies; 22+ messages in thread
From: Naresh Kamboju @ 2021-02-23 7:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Shuah Khan, patches, lkft-triage, Jon Hunter,
linux-stable, pavel, Andrew Morton, Linus Torvalds,
Guenter Roeck
On Mon, 22 Feb 2021 at 17:46, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.4.100 release.
> There are 13 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.4.100-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.4.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 <lkft@linaro.org>
Summary
------------------------------------------------------------------------
kernel: 5.4.100-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: b467dd44a81c97f9d99fbab61ef081f35e824773
git describe: v5.4.99-15-gb467dd44a81c
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.99-15-gb467dd44a81c
No regressions (compared to build v5.4.99)
No fixes (compared to build v5.4.99)
Ran 50146 total tests in the following environments and test suites.
Environments
--------------
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- 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
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* perf
* v4l2-compliance
* fwts
* ltp-commands-tests
* ltp-controllers-tests
* ltp-math-tests
* ltp-sched-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* kselftest-kexec
* kselftest-vm
* kselftest-x86
* ltp-open-posix-tests
* kvm-unit-tests
* rcutorture
* ssuite
* timesync-off
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.4 00/13] 5.4.100-rc1 review
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2021-02-23 7:16 ` Naresh Kamboju
@ 2021-02-23 14:47 ` Jon Hunter
2021-02-23 15:06 ` Jon Hunter
2021-02-23 21:12 ` Shuah Khan
18 siblings, 1 reply; 22+ messages in thread
From: Jon Hunter @ 2021-02-23 14:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, stable, linux-tegra
On Mon, 22 Feb 2021 13:13:17 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.100 release.
> There are 13 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.4.100-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Failures detected for Tegra ...
Test results for stable-v5.4:
12 builds: 12 pass, 0 fail
26 boots: 26 pass, 0 fail
57 tests: 56 pass, 1 fail
Linux version: 5.4.100-rc1-gb467dd44a81c
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Test failures: tegra210-p2371-2180: tegra-audio-hda-playback.sh
Jon
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.4 00/13] 5.4.100-rc1 review
2021-02-23 14:47 ` Jon Hunter
@ 2021-02-23 15:06 ` Jon Hunter
2021-02-25 8:20 ` Greg Kroah-Hartman
0 siblings, 1 reply; 22+ messages in thread
From: Jon Hunter @ 2021-02-23 15:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
stable, linux-tegra
On 23/02/2021 14:47, Jon Hunter wrote:
> On Mon, 22 Feb 2021 13:13:17 +0100, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 5.4.100 release.
>> There are 13 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.4.100-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.4.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>
> Failures detected for Tegra ...
>
> Test results for stable-v5.4:
> 12 builds: 12 pass, 0 fail
> 26 boots: 26 pass, 0 fail
> 57 tests: 56 pass, 1 fail
>
> Linux version: 5.4.100-rc1-gb467dd44a81c
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra210-p3450-0000,
> tegra30-cardhu-a04
>
> Test failures: tegra210-p2371-2180: tegra-audio-hda-playback.sh
You can ignore the above failure. This is an intermittent failure we
have been observing on this board and is not new to this -rc. This has
been fixed by the following mainline and has been tagged for stable.
commit 1e0ca5467445bc1f41a9e403d6161a22f313dae7
Author: Sameer Pujar <spujar@nvidia.com>
Date: Thu Jan 7 10:36:10 2021 +0530
arm64: tegra: Add power-domain for Tegra210 HDA
Usually, I try to filter out these known issues, but missed this one.
Anyway, for Tegra ...
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.4 00/13] 5.4.100-rc1 review
2021-02-23 15:06 ` Jon Hunter
@ 2021-02-25 8:20 ` Greg Kroah-Hartman
0 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-25 8:20 UTC (permalink / raw)
To: Jon Hunter
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
stable, linux-tegra
On Tue, Feb 23, 2021 at 03:06:31PM +0000, Jon Hunter wrote:
>
> On 23/02/2021 14:47, Jon Hunter wrote:
> > On Mon, 22 Feb 2021 13:13:17 +0100, Greg Kroah-Hartman wrote:
> >> This is the start of the stable review cycle for the 5.4.100 release.
> >> There are 13 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.4.100-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.4.y
> >> and the diffstat can be found below.
> >>
> >> thanks,
> >>
> >> greg k-h
> >
> > Failures detected for Tegra ...
> >
> > Test results for stable-v5.4:
> > 12 builds: 12 pass, 0 fail
> > 26 boots: 26 pass, 0 fail
> > 57 tests: 56 pass, 1 fail
> >
> > Linux version: 5.4.100-rc1-gb467dd44a81c
> > Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> > tegra194-p2972-0000, tegra20-ventana,
> > tegra210-p2371-2180, tegra210-p3450-0000,
> > tegra30-cardhu-a04
> >
> > Test failures: tegra210-p2371-2180: tegra-audio-hda-playback.sh
>
>
> You can ignore the above failure. This is an intermittent failure we
> have been observing on this board and is not new to this -rc. This has
> been fixed by the following mainline and has been tagged for stable.
>
> commit 1e0ca5467445bc1f41a9e403d6161a22f313dae7
> Author: Sameer Pujar <spujar@nvidia.com>
> Date: Thu Jan 7 10:36:10 2021 +0530
>
> arm64: tegra: Add power-domain for Tegra210 HDA
>
> Usually, I try to filter out these known issues, but missed this one.
> Anyway, for Tegra ...
Now queued that patch up, thanks.
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 5.4 00/13] 5.4.100-rc1 review
2021-02-22 12:13 [PATCH 5.4 00/13] 5.4.100-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2021-02-23 14:47 ` Jon Hunter
@ 2021-02-23 21:12 ` Shuah Khan
18 siblings, 0 replies; 22+ messages in thread
From: Shuah Khan @ 2021-02-23 21:12 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, stable, Shuah Khan
On 2/22/21 5:13 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.100 release.
> There are 13 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.4.100-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 22+ messages in thread