2021-02-22 12:29:07

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 00/29] 5.10.18-rc1 review

This is the start of the stable review cycle for the 5.10.18 release.
There are 29 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.10.18-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.10.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.10.18-rc1

Matwey V. Kornilov <[email protected]>
media: pwc: Use correct device for DMA

Filipe Manana <[email protected]>
btrfs: fix crash after non-aligned direct IO write with O_DSYNC

David Sterba <[email protected]>
btrfs: fix backport of 2175bf57dc952 in 5.10.13

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()

Yonatan Linik <[email protected]>
net: fix proc_fs init handling in af_packet and tls

Wang Hai <[email protected]>
net: bridge: Fix a warning when del bridge sysfs

Eelco Chaudron <[email protected]>
net: openvswitch: fix TTL decrement exception action execution

Pablo Neira Ayuso <[email protected]>
net: sched: incorrect Kconfig dependencies on Netfilter modules

Lorenzo Bianconi <[email protected]>
mt76: mt7615: fix rdd mcu cmd endianness

Felix Fietkau <[email protected]>
mt76: mt7915: fix endian issues

wenxu <[email protected]>
net/sched: fix miss init the mru in qdisc_skb_cb

Florian Westphal <[email protected]>
mptcp: skip to next candidate if subflow has unacked data

Loic Poulain <[email protected]>
net: qrtr: Fix port ID for control messages

Max Gurtovoy <[email protected]>
IB/isert: add module param to set sg_tablesize for IO cmd

Stefano Garzarella <[email protected]>
vdpa_sim: add get_config callback in vdpasim_dev_attr

Stefano Garzarella <[email protected]>
vdpa_sim: make 'config' generic and usable for any device type

Stefano Garzarella <[email protected]>
vdpa_sim: store parsed MAC address in a buffer

Stefano Garzarella <[email protected]>
vdpa_sim: add struct vdpasim_dev_attr for device attributes

Max Gurtovoy <[email protected]>
vdpa_sim: remove hard-coded virtq count


-------------

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/infiniband/ulp/isert/ib_isert.c | 27 +++++++-
drivers/infiniband/ulp/isert/ib_isert.h | 6 ++
drivers/media/usb/pwc/pwc-if.c | 22 +++---
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 89 ++++++++++++++++++-------
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 87 ++++++++++++++++++------
drivers/net/xen-netback/netback.c | 4 +-
drivers/tty/tty_io.c | 5 +-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 83 ++++++++++++++++-------
drivers/xen/gntdev.c | 37 +++++-----
drivers/xen/xen-scsiback.c | 4 +-
fs/btrfs/ctree.h | 6 +-
fs/btrfs/inode.c | 6 +-
include/xen/grant_table.h | 1 +
net/bridge/br.c | 5 +-
net/core/dev.c | 2 +
net/mptcp/protocol.c | 5 +-
net/openvswitch/actions.c | 15 ++---
net/packet/af_packet.c | 2 +
net/qrtr/qrtr.c | 2 +-
net/sched/Kconfig | 6 +-
net/tls/tls_proc.c | 3 +
26 files changed, 337 insertions(+), 157 deletions(-)



2021-02-22 12:29:14

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 19/29] Xen/gntdev: correct error checking in gntdev_map_grant_pages()

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


2021-02-22 12:29:38

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 26/29] Bluetooth: btusb: Always fallback to alt 1 for WBS

From: Trent Piepho <[email protected]>

commit 517b693351a2d04f3af1fc0e506ac7e1346094de upstream.

When alt mode 6 is not available, fallback to the kernel <= 5.7 behavior
of always using alt mode 1.

Prior to kernel 5.8, btusb would always use alt mode 1 for WBS (Wide
Band Speech aka mSBC aka transparent SCO). In commit baac6276c0a9
("Bluetooth: btusb: handle mSBC audio over USB Endpoints") this
was changed to use alt mode 6, which is the recommended mode in the
Bluetooth spec (Specifications of the Bluetooth System, v5.0, Vol 4.B
§2.2.1). However, many if not most BT USB adapters do not support alt
mode 6. In fact, I have been unable to find any which do.

In kernel 5.8, this was changed to use alt mode 6, and if not available,
use alt mode 0. But mode 0 has a zero byte max packet length and can
not possibly work. It is just there as a zero-bandwidth dummy mode to
work around a USB flaw that would prevent device enumeration if
insufficient bandwidth were available for the lowest isoc mode
supported.

In effect, WBS was broken for all USB-BT adapters that do not support
alt 6, which appears to nearly all of them.

Then in commit 461f95f04f19 ("Bluetooth: btusb: USB alternate setting 1 for
WBS") the 5.7 behavior was restored, but only for Realtek adapters.

I've tested a Broadcom BRCM20702A and CSR 8510 adapter, both work with
the 5.7 behavior and do not with the 5.8.

So get rid of the Realtek specific flag and use the 5.7 behavior for all
adapters as a fallback when alt 6 is not available. This was the
kernel's behavior prior to 5.8 and I can find no adapters for which it
is not correct. And even if there is an adapter for which this does not
work, the current behavior would be to fall back to alt 0, which can not
possibly work either, and so is no better.

Signed-off-by: Trent Piepho <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Cc: Salvatore Bonaccorso <[email protected]>
Cc: Sjoerd Simons <[email protected]>
Cc: Sebastian Reichel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/bluetooth/btusb.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)

--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -480,7 +480,6 @@ static const struct dmi_system_id btusb_
#define BTUSB_HW_RESET_ACTIVE 12
#define BTUSB_TX_WAIT_VND_EVT 13
#define BTUSB_WAKEUP_DISABLE 14
-#define BTUSB_USE_ALT1_FOR_WBS 15

struct btusb_data {
struct hci_dev *hdev;
@@ -1710,15 +1709,12 @@ static void btusb_work(struct work_struc
new_alts = data->sco_num;
}
} else if (data->air_mode == HCI_NOTIFY_ENABLE_SCO_TRANSP) {
- /* Check if Alt 6 is supported for Transparent audio */
- if (btusb_find_altsetting(data, 6)) {
- data->usb_alt6_packet_flow = true;
- new_alts = 6;
- } else if (test_bit(BTUSB_USE_ALT1_FOR_WBS, &data->flags)) {
- new_alts = 1;
- } else {
- bt_dev_err(hdev, "Device does not support ALT setting 6");
- }
+ /* Bluetooth USB spec recommends alt 6 (63 bytes), but
+ * many adapters do not support it. Alt 1 appears to
+ * work for all adapters that do not have alt 6, and
+ * which work with WBS at all.
+ */
+ new_alts = btusb_find_altsetting(data, 6) ? 6 : 1;
}

if (btusb_switch_alt_setting(hdev, new_alts) < 0)
@@ -4149,10 +4145,6 @@ static int btusb_probe(struct usb_interf
* (DEVICE_REMOTE_WAKEUP)
*/
set_bit(BTUSB_WAKEUP_DISABLE, &data->flags);
- if (btusb_find_altsetting(data, 1))
- set_bit(BTUSB_USE_ALT1_FOR_WBS, &data->flags);
- else
- bt_dev_err(hdev, "Device does not support ALT setting 1");
}

if (!reset)


2021-02-22 12:29:40

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 23/29] xen-scsiback: dont "handle" error by BUG()

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]);
}


2021-02-22 12:30:05

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 24/29] xen-blkback: fix error handling in xen_blkbk_map()

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)


2021-02-22 12:30:53

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 16/29] Xen/x86: dont bail early from clear_foreign_p2m_mapping()

From: Jan Beulich <[email protected]>

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 <[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 | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)

--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -750,17 +750,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);


2021-02-22 12:31:19

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 17/29] Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()

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]use.com>
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) {


2021-02-22 12:31:24

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 18/29] Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()

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;
}


2021-02-22 12:32:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 04/29] vdpa_sim: make config generic and usable for any device type

From: Stefano Garzarella <[email protected]>

commit f37cbbc65178e0a45823d281d290c4c02da9631c upstream.

Add new 'config_size' attribute in 'vdpasim_dev_attr' and allocates
'config' dynamically to support any device types.

Acked-by: Jason Wang <[email protected]>
Signed-off-by: Stefano Garzarella <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Stefano Garzarella <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)

--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -70,6 +70,7 @@ static u64 vdpasim_features = (1ULL << V
(1ULL << VIRTIO_NET_F_MAC);

struct vdpasim_dev_attr {
+ size_t config_size;
int nvqs;
};

@@ -81,7 +82,8 @@ struct vdpasim {
struct vdpasim_dev_attr dev_attr;
/* spinlock to synchronize virtqueue state */
spinlock_t lock;
- struct virtio_net_config config;
+ /* virtio config according to device type */
+ void *config;
struct vhost_iotlb *iommu;
void *buffer;
u32 status;
@@ -380,6 +382,10 @@ static struct vdpasim *vdpasim_create(st
goto err_iommu;
set_dma_ops(dev, &vdpasim_dma_ops);

+ vdpasim->config = kzalloc(dev_attr->config_size, GFP_KERNEL);
+ if (!vdpasim->config)
+ goto err_iommu;
+
vdpasim->vqs = kcalloc(dev_attr->nvqs, sizeof(struct vdpasim_virtqueue),
GFP_KERNEL);
if (!vdpasim->vqs)
@@ -518,7 +524,8 @@ static u64 vdpasim_get_features(struct v
static int vdpasim_set_features(struct vdpa_device *vdpa, u64 features)
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
- struct virtio_net_config *config = &vdpasim->config;
+ struct virtio_net_config *config =
+ (struct virtio_net_config *)vdpasim->config;

/* DMA mapping must be done by driver */
if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
@@ -588,8 +595,8 @@ static void vdpasim_get_config(struct vd
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);

- if (offset + len < sizeof(struct virtio_net_config))
- memcpy(buf, (u8 *)&vdpasim->config + offset, len);
+ if (offset + len < vdpasim->dev_attr.config_size)
+ memcpy(buf, vdpasim->config + offset, len);
}

static void vdpasim_set_config(struct vdpa_device *vdpa, unsigned int offset,
@@ -676,6 +683,7 @@ static void vdpasim_free(struct vdpa_dev
if (vdpasim->iommu)
vhost_iotlb_free(vdpasim->iommu);
kfree(vdpasim->vqs);
+ kfree(vdpasim->config);
}

static const struct vdpa_config_ops vdpasim_net_config_ops = {
@@ -736,6 +744,7 @@ static int __init vdpasim_dev_init(void)
struct vdpasim_dev_attr dev_attr = {};

dev_attr.nvqs = VDPASIM_VQ_NUM;
+ dev_attr.config_size = sizeof(struct virtio_net_config);

vdpasim_dev = vdpasim_create(&dev_attr);



2021-02-22 12:32:42

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 28/29] btrfs: fix crash after non-aligned direct IO write with O_DSYNC

From: Filipe Manana <[email protected]>

Whenever we attempt to do a non-aligned direct IO write with O_DSYNC, we
end up triggering an assertion and crashing. Example reproducer:

$ cat test.sh
#!/bin/bash

DEV=/dev/sdj
MNT=/mnt/sdj

mkfs.btrfs -f $DEV > /dev/null
mount $DEV $MNT

# Do a direct IO write with O_DSYNC into a non-aligned range...
xfs_io -f -d -s -c "pwrite -S 0xab -b 64K 1111 64K" $MNT/foobar

umount $MNT

When running the reproducer an assertion fails and produces the following
trace:

[ 2418.403134] assertion failed: !current->journal_info || flush != BTRFS_RESERVE_FLUSH_DATA, in fs/btrfs/space-info.c:1467
[ 2418.403745] ------------[ cut here ]------------
[ 2418.404306] kernel BUG at fs/btrfs/ctree.h:3286!
[ 2418.404862] invalid opcode: 0000 [#2] PREEMPT SMP DEBUG_PAGEALLOC PTI
[ 2418.405451] CPU: 1 PID: 64705 Comm: xfs_io Tainted: G D 5.10.15-btrfs-next-87 #1
[ 2418.406026] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 2418.407228] RIP: 0010:assertfail.constprop.0+0x18/0x26 [btrfs]
[ 2418.407835] Code: e6 48 c7 (...)
[ 2418.409078] RSP: 0018:ffffb06080d13c98 EFLAGS: 00010246
[ 2418.409696] RAX: 000000000000006c RBX: ffff994c1debbf08 RCX: 0000000000000000
[ 2418.410302] RDX: 0000000000000000 RSI: 0000000000000027 RDI: 00000000ffffffff
[ 2418.410904] RBP: ffff994c21770000 R08: 0000000000000000 R09: 0000000000000000
[ 2418.411504] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000010000
[ 2418.412111] R13: ffff994c22198400 R14: ffff994c21770000 R15: 0000000000000000
[ 2418.412713] FS: 00007f54fd7aff00(0000) GS:ffff994d35200000(0000) knlGS:0000000000000000
[ 2418.413326] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2418.413933] CR2: 000056549596d000 CR3: 000000010b928003 CR4: 0000000000370ee0
[ 2418.414528] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2418.415109] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2418.415669] Call Trace:
[ 2418.416254] btrfs_reserve_data_bytes.cold+0x22/0x22 [btrfs]
[ 2418.416812] btrfs_check_data_free_space+0x4c/0xa0 [btrfs]
[ 2418.417380] btrfs_buffered_write+0x1b0/0x7f0 [btrfs]
[ 2418.418315] btrfs_file_write_iter+0x2a9/0x770 [btrfs]
[ 2418.418920] new_sync_write+0x11f/0x1c0
[ 2418.419430] vfs_write+0x2bb/0x3b0
[ 2418.419972] __x64_sys_pwrite64+0x90/0xc0
[ 2418.420486] do_syscall_64+0x33/0x80
[ 2418.420979] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 2418.421486] RIP: 0033:0x7f54fda0b986
[ 2418.421981] Code: 48 c7 c0 (...)
[ 2418.423019] RSP: 002b:00007ffc40569c38 EFLAGS: 00000246 ORIG_RAX: 0000000000000012
[ 2418.423547] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f54fda0b986
[ 2418.424075] RDX: 0000000000010000 RSI: 000056549595e000 RDI: 0000000000000003
[ 2418.424596] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000400
[ 2418.425119] R10: 0000000000000400 R11: 0000000000000246 R12: 00000000ffffffff
[ 2418.425644] R13: 0000000000000400 R14: 0000000000010000 R15: 0000000000000000
[ 2418.426148] Modules linked in: btrfs blake2b_generic (...)
[ 2418.429540] ---[ end trace ef2aeb44dc0afa34 ]---

1) At btrfs_file_write_iter() we set current->journal_info to
BTRFS_DIO_SYNC_STUB;

2) We then call __btrfs_direct_write(), which calls btrfs_direct_IO();

3) We can't do the direct IO write because it starts at a non-aligned
offset (1111). So at btrfs_direct_IO() we return -EINVAL (coming from
check_direct_IO() which does the alignment check), but we leave
current->journal_info set to BTRFS_DIO_SYNC_STUB - we only clear it
at btrfs_dio_iomap_begin(), because we assume we always get there;

4) Then at __btrfs_direct_write() we see that the attempt to do the
direct IO write was not successful, 0 bytes written, so we fallback
to a buffered write by calling btrfs_buffered_write();

5) There we call btrfs_check_data_free_space() which in turn calls
btrfs_alloc_data_chunk_ondemand() and that calls
btrfs_reserve_data_bytes() with flush == BTRFS_RESERVE_FLUSH_DATA;

6) Then at btrfs_reserve_data_bytes() we have current->journal_info set to
BTRFS_DIO_SYNC_STUB, therefore not NULL, and flush has the value
BTRFS_RESERVE_FLUSH_DATA, triggering the second assertion:

int btrfs_reserve_data_bytes(struct btrfs_fs_info *fs_info, u64 bytes,
enum btrfs_reserve_flush_enum flush)
{
struct btrfs_space_info *data_sinfo = fs_info->data_sinfo;
int ret;

ASSERT(flush == BTRFS_RESERVE_FLUSH_DATA ||
flush == BTRFS_RESERVE_FLUSH_FREE_SPACE_INODE);
ASSERT(!current->journal_info || flush != BTRFS_RESERVE_FLUSH_DATA);
(...)

So fix that by setting the journal to NULL whenever check_direct_IO()
returns a failure.

This bug only affects 5.10 kernels, and the regression was introduced in
5.10-rc1 by commit 0eb79294dbe328 ("btrfs: dio iomap DSYNC workaround").
The bug does not exist in 5.11 kernels due to commit ecfdc08b8cc65d
("btrfs: remove dio iomap DSYNC workaround"), which depends on a large
patchset that went into the merge window for 5.11. So this is a fix only
for 5.10.x stable kernels, as there are people hitting this bug.

Fixes: 0eb79294dbe328 ("btrfs: dio iomap DSYNC workaround")
CC: [email protected] # 5.10 (and only 5.10)
Acked-by: David Sterba <[email protected]>
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1181605
Signed-off-by: Filipe Manana <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/inode.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8026,8 +8026,12 @@ ssize_t btrfs_direct_IO(struct kiocb *io
bool relock = false;
ssize_t ret;

- if (check_direct_IO(fs_info, iter, offset))
+ if (check_direct_IO(fs_info, iter, offset)) {
+ ASSERT(current->journal_info == NULL ||
+ current->journal_info == BTRFS_DIO_SYNC_STUB);
+ current->journal_info = NULL;
return 0;
+ }

count = iov_iter_count(iter);
if (iov_iter_rw(iter) == WRITE) {


2021-02-22 12:33:22

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 12/29] net: sched: incorrect Kconfig dependencies on Netfilter modules

From: Pablo Neira Ayuso <[email protected]>

[ Upstream commit 102e2c07239c07144d9c7338ec09b9d47f2e5f79 ]

- NET_ACT_CONNMARK and NET_ACT_CTINFO only require conntrack support.
- NET_ACT_IPT only requires NETFILTER_XTABLES symbols, not
IP_NF_IPTABLES. After this patch, NET_ACT_IPT becomes consistent
with NET_EMATCH_IPT. NET_ACT_IPT dependency on IP_NF_IPTABLES predates
Linux-2.6.12-rc2 (initial git repository build).

Fixes: 22a5dc0e5e3e ("net: sched: Introduce connmark action")
Fixes: 24ec483cec98 ("net: sched: Introduce act_ctinfo action")
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/sched/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index a3b37d88800eb..d762e89ab74f7 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -813,7 +813,7 @@ config NET_ACT_SAMPLE

config NET_ACT_IPT
tristate "IPtables targets"
- depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
+ depends on NET_CLS_ACT && NETFILTER && NETFILTER_XTABLES
help
Say Y here to be able to invoke iptables targets after successful
classification.
@@ -912,7 +912,7 @@ config NET_ACT_BPF

config NET_ACT_CONNMARK
tristate "Netfilter Connection Mark Retriever"
- depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
+ depends on NET_CLS_ACT && NETFILTER
depends on NF_CONNTRACK && NF_CONNTRACK_MARK
help
Say Y here to allow retrieving of conn mark
@@ -924,7 +924,7 @@ config NET_ACT_CONNMARK

config NET_ACT_CTINFO
tristate "Netfilter Connection Mark Actions"
- depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
+ depends on NET_CLS_ACT && NETFILTER
depends on NF_CONNTRACK && NF_CONNTRACK_MARK
help
Say Y here to allow transfer of a connmark stored information.
--
2.27.0



2021-02-22 17:19:36

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/29] 5.10.18-rc1 review



On 2/22/2021 4:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.18 release.
> There are 29 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.10.18-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.10.y
> and the diffstat can be found below.

On ARCH_BRCMSTB using 32-bit ARM and 64-bit ARM kernels:

Tested-by: Florian Fainelli <[email protected]>

Thanks!
--
Florian

2021-02-22 18:46:49

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/29] 5.10.18-rc1 review

Hi!

> This is the start of the stable review cycle for the 5.10.18 release.
> There are 29 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.

Two runs are marked as failed, but details show "no available board",
so it is not a kernel problem.

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Tested-by: Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel


--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (722.00 B)
signature.asc (201.00 B)
Download all attachments

2021-02-22 21:38:56

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/29] 5.10.18-rc1 review

On Mon, Feb 22, 2021 at 01:12:54PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.18 release.
> There are 29 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: 156 pass: 156 fail: 0
Qemu test results:
total: 430 pass: 430 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter

2021-02-22 21:39:01

by Igor

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/29] 5.10.18-rc1 review

On Mon, Feb 22, 2021 at 01:12:54PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.18 release.
> There are 29 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.10.18-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.10.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 <[email protected]>

Best regards
---
Igor Matheus Andrade Torrente

> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 5.10.18-rc1
>
> Matwey V. Kornilov <[email protected]>
> media: pwc: Use correct device for DMA
>
> Filipe Manana <[email protected]>
> btrfs: fix crash after non-aligned direct IO write with O_DSYNC
>
> David Sterba <[email protected]>
> btrfs: fix backport of 2175bf57dc952 in 5.10.13
>
> 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()
>
> Yonatan Linik <[email protected]>
> net: fix proc_fs init handling in af_packet and tls
>
> Wang Hai <[email protected]>
> net: bridge: Fix a warning when del bridge sysfs
>
> Eelco Chaudron <[email protected]>
> net: openvswitch: fix TTL decrement exception action execution
>
> Pablo Neira Ayuso <[email protected]>
> net: sched: incorrect Kconfig dependencies on Netfilter modules
>
> Lorenzo Bianconi <[email protected]>
> mt76: mt7615: fix rdd mcu cmd endianness
>
> Felix Fietkau <[email protected]>
> mt76: mt7915: fix endian issues
>
> wenxu <[email protected]>
> net/sched: fix miss init the mru in qdisc_skb_cb
>
> Florian Westphal <[email protected]>
> mptcp: skip to next candidate if subflow has unacked data
>
> Loic Poulain <[email protected]>
> net: qrtr: Fix port ID for control messages
>
> Max Gurtovoy <[email protected]>
> IB/isert: add module param to set sg_tablesize for IO cmd
>
> Stefano Garzarella <[email protected]>
> vdpa_sim: add get_config callback in vdpasim_dev_attr
>
> Stefano Garzarella <[email protected]>
> vdpa_sim: make 'config' generic and usable for any device type
>
> Stefano Garzarella <[email protected]>
> vdpa_sim: store parsed MAC address in a buffer
>
> Stefano Garzarella <[email protected]>
> vdpa_sim: add struct vdpasim_dev_attr for device attributes
>
> Max Gurtovoy <[email protected]>
> vdpa_sim: remove hard-coded virtq count
>
>
> -------------
>
> 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/infiniband/ulp/isert/ib_isert.c | 27 +++++++-
> drivers/infiniband/ulp/isert/ib_isert.h | 6 ++
> drivers/media/usb/pwc/pwc-if.c | 22 +++---
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 89 ++++++++++++++++++-------
> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 87 ++++++++++++++++++------
> drivers/net/xen-netback/netback.c | 4 +-
> drivers/tty/tty_io.c | 5 +-
> drivers/vdpa/vdpa_sim/vdpa_sim.c | 83 ++++++++++++++++-------
> drivers/xen/gntdev.c | 37 +++++-----
> drivers/xen/xen-scsiback.c | 4 +-
> fs/btrfs/ctree.h | 6 +-
> fs/btrfs/inode.c | 6 +-
> include/xen/grant_table.h | 1 +
> net/bridge/br.c | 5 +-
> net/core/dev.c | 2 +
> net/mptcp/protocol.c | 5 +-
> net/openvswitch/actions.c | 15 ++---
> net/packet/af_packet.c | 2 +
> net/qrtr/qrtr.c | 2 +-
> net/sched/Kconfig | 6 +-
> net/tls/tls_proc.c | 3 +
> 26 files changed, 337 insertions(+), 157 deletions(-)
>
>

2021-02-23 02:51:27

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/29] 5.10.18-rc1 review

On Mon, 22 Feb 2021 at 17:44, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.10.18 release.
> There are 29 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.10.18-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.10.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]>

Summary
------------------------------------------------------------------------

kernel: 5.10.18-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.10.y
git commit: 905cc0ddef721db27341d7ca4f85bbcd82bbb6e1
git describe: v5.10.17-30-g905cc0ddef72
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.17-30-g905cc0ddef72

No regressions (compared to build v5.10.17)


No fixes (compared to build v5.10.17)


Ran 54290 total tests in the following environments and test suites.

Environments
--------------
- arc
- arm
- arm64
- dragonboard-410c
- dragonboard-845c
- 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
* install-android-platform-tools-r2600
* kselftest-
* kselftest-bpf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-lkdtm
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* kselftest-android
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-intel_pstate
* kselftest-kvm
* kselftest-livepatch
* kselftest-ptrace
* ltp-dio-tests
* ltp-fs-tests
* ltp-io-tests
* network-basic-tests
* perf
* kselftest-kexec
* kselftest-lib
* 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-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* ltp-open-posix-tests
* v4l2-compliance
* kvm-unit-tests
* ltp-controllers-tests
* kunit
* rcutorture
* kselftest-vm
* ssuite
* fwts

--
Linaro LKFT
https://lkft.linaro.org

2021-02-23 21:18:57

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/29] 5.10.18-rc1 review

On 2/22/21 5:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.18 release.
> There are 29 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.10.18-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.10.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 <[email protected]>

thanks,
-- Shuah

2021-02-24 18:44:55

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/29] 5.10.18-rc1 review

On Mon, Feb 22, 2021 at 07:42:23PM +0100, Pavel Machek wrote:
> Hi!
>
> > This is the start of the stable review cycle for the 5.10.18 release.
> > There are 29 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.
>
> Two runs are marked as failed, but details show "no available board",
> so it is not a kernel problem.
>
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
>
> Tested-by: Pavel Machek (CIP) <[email protected]>

Thanks for testing some of these.

greg k-h

2021-02-24 18:46:20

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/29] 5.10.18-rc1 review

On Mon, Feb 22, 2021 at 09:17:44AM -0800, Florian Fainelli wrote:
>
>
> On 2/22/2021 4:12 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.18 release.
> > There are 29 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.10.18-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.10.y
> > and the diffstat can be found below.
>
> On ARCH_BRCMSTB using 32-bit ARM and 64-bit ARM kernels:
>
> Tested-by: Florian Fainelli <[email protected]>

Thanks for testing!