4.19.275-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.19.275-rc1 review
This is the start of the stable review cycle for the 4.19.275 release. There are 9 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 Fri, 03 Mar 2023 18:06:43 +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/v4.x/stable-review/patch-4.19.275-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-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.19.275-rc1
Alan Stern <[email protected]>
USB: core: Don't hold device lock while reading the "descriptors" sysfs file
Florian Zumbiehl <[email protected]>
USB: serial: option: add support for VW/Skoda "Carstick LTE"
Jiasheng Jiang <[email protected]>
dmaengine: sh: rcar-dmac: Check for error num after dma_set_max_seg_size
Thomas Weißschuh <[email protected]>
vc_screen: don't clobber return value in vcs_read
Kuniyuki Iwashima <[email protected]>
net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues().
Dean Luick <[email protected]>
IB/hfi1: Assign npages earlier
David Sterba <[email protected]>
btrfs: send: limit number of clones and allocated memory size
Vishal Verma <[email protected]>
ACPI: NFIT: fix a potential deadlock during NFIT teardown
Johan Jonker <[email protected]>
ARM: dts: rockchip: add power-domains property to dp node on rk3288
-------------
Diffstat:
Makefile | 4 ++-- arch/arm/boot/dts/rk3288.dtsi | 1 + drivers/acpi/nfit/core.c | 2 +- drivers/dma/sh/rcar-dmac.c | 5 ++++- drivers/infiniband/hw/hfi1/user_exp_rcv.c | 9 ++------- drivers/tty/vt/vc_screen.c | 7 ++++--- drivers/usb/core/hub.c | 5 ++--- drivers/usb/core/sysfs.c | 5 ----- drivers/usb/serial/option.c | 4 ++++ fs/btrfs/send.c | 6 +++--- net/caif/caif_socket.c | 1 + net/core/stream.c | 1 - 12 files changed, 24 insertions(+), 26 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/9 ARM: dts: rockchip: add power-domains property to dp node on rk3288
From: Johan Jonker <[email protected]>
[ Upstream commit 80422339a75088322b4d3884bd12fa0fe5d11050 ]
The clocks in the Rockchip rk3288 DisplayPort node are included in the power-domain@RK3288_PD_VIO logic, but the power-domains property in the dp node is missing, so fix it.
--- arch/arm/boot/dts/rk3288.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/rk3288.dtsi +1 -0
@@ -1172,6 +1172,7 @@ edp: dp@ff970000 { clock-names = "dp", "pclk"; phys = <&edp_phy>; phy-names = "dp"; + power-domains = <&power RK3288_PD_VIO>; resets = <&cru SRST_EDP>; reset-names = "dp"; rockchip,grf = <&grf>;
Signature · 1 line
2.39.0
Greg Kroah-Hartman
maintainerPATCH 2/9 ACPI: NFIT: fix a potential deadlock during NFIT teardown
In reply to Greg Kroah-HartmanFrom: Vishal Verma <[email protected]>
[ Upstream commit fb6df4366f86dd252bfa3049edffa52d17e7b895 ]
Lockdep reports that acpi_nfit_shutdown() may deadlock against an opportune acpi_nfit_scrub(). acpi_nfit_scrub () is run from inside a 'work' and therefore has already acquired workqueue-internal locks. It also acquiires acpi_desc->init_mutex. acpi_nfit_shutdown() first acquires init_mutex, and was subsequently attempting to cancel any pending workqueue items. This reversed locking order causes a potential deadlock:
======================================================
WARNING: possible circular locking dependency detected
6.2.0-rc3 #116 Tainted: G O N
------------------------------------------------------
libndctl/1958 is trying to acquire lock:
ffff888129b461c0 ((work_completion)(&(&acpi_desc->dwork)->work)){+.+.}-{0:0}, at: __flush_work+0x43/0x450
but task is already holding lock:
ffff888129b460e8 (&acpi_desc->init_mutex){+.+.}-{3:3}, at: acpi_nfit_shutdown+0x87/0xd0 [nfit]
which lock already depends on the new lock.
...
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&acpi_desc->init_mutex);
lock((work_completion)(&(&acpi_desc->dwork)->work));
lock(&acpi_desc->init_mutex);
lock((work_completion)(&(&acpi_desc->dwork)->work));
*** DEADLOCK ***Since the workqueue manipulation is protected by its own internal locking, the cancellation of pending work doesn't need to be done under acpi_desc->init_mutex. Move cancel_delayed_work_sync() outside the init_mutex to fix the deadlock. Any work that starts after acpi_nfit_shutdown() drops the lock will see ARS_CANCEL, and the cancel_delayed_work_sync() will safely flush it out.
--- drivers/acpi/nfit/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/nfit/core.c +1 -1
@@ -3442,8 +3442,8 @@ void acpi_nfit_shutdown(void *data)mutex_lock (&acpi_desc->init_mutex);set_bit (ARS_CANCEL , &acpi_desc->scrub_flags); -cancel_delayed_work_sync (&acpi_desc->dwork);mutex_unlock (&acpi_desc->init_mutex); +cancel_delayed_work_sync (&acpi_desc->dwork);/* * Bounce the nvdimm bus lock to make sure any in-flight
Signature · 1 line
2.39.0
Greg Kroah-Hartman
maintainerPATCH 3/9 btrfs: send: limit number of clones and allocated memory size
In reply to Greg Kroah-HartmanFrom: David Sterba <[email protected]>
[ Upstream commit 33e17b3f5ab74af12aca58c515bc8424ff69a343 ]
The arg->clone_sources_count is u64 and can trigger a warning when a huge value is passed from user space and a huge array is allocated. Limit the allocated memory to 8MiB (can be increased if needed), which in turn limits the number of clone sources to 8M / sizeof(struct clone_root) = 8M / 40 = 209715. Real world number of clones is from tens to hundreds, so this is future proof.
--- fs/btrfs/send.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/btrfs/send.c +3 -3
@@ -6826,10 +6826,10 @@ long btrfs_ioctl_send(struct file *mnt_file, struct btrfs_ioctl_send_args *arg)/* * Check that we don't overflow at later allocations, we request * clone_sources_count + 1 items, and compare to unsigned long inside -* access_ok. +* access_ok. Also set an upper limit for allocation size so this can't +* easily exhaust memory. Max number of clone sources is about 200K. */ -if (arg->clone_sources_count > -ULONG_MAX /sizeof (struct clone_root ) -1 ) { +if (arg->clone_sources_count >SZ_8M /sizeof (struct clone_root )) { ret = -EINVAL ; goto out; }
Signature · 1 line
2.39.0
Greg Kroah-Hartman
maintainerPATCH 4/9 IB/hfi1: Assign npages earlier
In reply to Greg Kroah-HartmanFrom: Dean Luick <[email protected]>
[ Upstream commit f9c47b2caa7ffc903ec950b454b59c209afe3182 ]
Improve code clarity and enable earlier use oftidbuf->npages by moving its assignment to
structure creation time.
--- drivers/infiniband/hw/hfi1/user_exp_rcv.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-)
drivers/infiniband/hw/hfi1/user_exp_rcv.c +2 -7
@@ -215,16 +215,11 @@ static void unpin_rcv_pages(struct hfi1_filedata *fd,static int pin_rcv_pages (struct hfi1_filedata *fd,struct tid_user_buf *tidbuf) {int pinned; -unsigned int npages; +unsigned int npages = tidbuf->npages;unsigned long vaddr = tidbuf->vaddr;struct page **pages =NULL ;struct hfi1_devdata *dd = fd->uctxt->dd; -/* Get the number of pages the user buffer spans */ - npages =num_user_pages (vaddr, tidbuf->length); -if (!npages) -return -EINVAL ; -if (npages > fd->uctxt->expected_count) {dd_dev_err (dd,"Expected buffer too big\n" );return -EINVAL ;
@@ -258,7 +253,6 @@ static int pin_rcv_pages(struct hfi1_filedata *fd, struct tid_user_buf *tidbuf)return pinned; } tidbuf->pages = pages; - tidbuf->npages = npages; fd->tid_n_pinned += pinned;return pinned; }
@@ -334,6 +328,7 @@ int hfi1_user_exp_rcv_setup(struct hfi1_filedata *fd, tidbuf->vaddr = tinfo->vaddr; tidbuf->length = tinfo->length; + tidbuf->npages =num_user_pages (tidbuf->vaddr, tidbuf->length); tidbuf->psets =kcalloc (uctxt->expected_count,sizeof (*tidbuf->psets),GFP_KERNEL );if (!tidbuf->psets) {
Signature · 1 line
2.39.0
Greg Kroah-Hartman
maintainerPATCH 5/9 net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues().
In reply to Greg Kroah-HartmanFrom: Kuniyuki Iwashima <[email protected]>
commit 62ec33b44e0f7168ff2886520fec6fb62d03b5a3 upstream.
Christoph Paasch reported that commit b5fc29233d28 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().") started triggering WARN_ON_ONCE(sk->sk_forward_alloc) in sk_stream_kill_queues(). [0 - 2] Also, we can reproduce it by a program in [3].
In the commit, we delay freeing ipv6_pinfo.pktoptions from sk->destroy() to sk->sk_destruct(), so sk->sk_forward_alloc is no longer zero in inet_csk_destroy_sock().
The same check has been in inet_sock_destruct() from at least v2.6, we can just remove the WARN_ON_ONCE(). However, among the users of sk_stream_kill_queues(), only CAIF is not calling inet_sock_destruct(). Thus, we add the same WARN_ON_ONCE() to caif_sock_destructor().
[0]: https://lore.kernel.org/netdev/[email protected]/
[1]: https://github.com/multipath-tcp/mptcp_net-next/issues/341
[2]:
WARNING: CPU: 0 PID: 3232 at net/core/stream.c:212 sk_stream_kill_queues+0x2f9/0x3e0 Modules linked in: CPU: 0 PID: 3232 Comm: syz-executor.0 Not tainted 6.2.0-rc5ab24eb4698afbe147b424149c529e2a43ec24eb5 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:sk_stream_kill_queues+0x2f9/0x3e0 Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ec 00 00 00 8b ab 08 01 00 00 e9 60 ff ff ff e8 d0 5f b6 fe 0f 0b eb 97 e8 c7 5f b6 fe <0f> 0b eb a0 e8 be 5f b6 fe 0f 0b e9 6a fe ff ff e8 02 07 e3 fe e9 RSP: 0018:ffff88810570fc68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff888101f38f40 RSI: ffffffff8285e529 RDI: 0000000000000005 RBP: 0000000000000ce0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000ce0 R11: 0000000000000001 R12: ffff8881009e9488 R13: ffffffff84af2cc0 R14: 0000000000000000 R15: ffff8881009e9458 FS: 00007f7fdfbd5800(0000) GS:ffff88811b600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32923000 CR3: 00000001062fc006 CR4: 0000000000170ef0 Call Trace: <TASK> inet_csk_destroy_sock+0x1a1/0x320 __tcp_close+0xab6/0xe90 tcp_close+0x30/0xc0 inet_release+0xe9/0x1f0 inet6_release+0x4c/0x70 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f7fdf7ae28d Code: c1 20 00 00 75 10 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 37 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:00000000007dfbb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f7fdf7ae28d RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 0000000000000003 RBP: 0000000000000000 R08: 000000007f338e0f R09: 0000000000000e0f R10: 000000007f338e13 R11: 0000000000000293 R12: 00007f7fdefff000 R13: 00007f7fdefffcd8 R14: 00007f7fdefffce0 R15: 00007f7fdefffcd8 </TASK>
[3]: https://lore.kernel.org/netdev/[email protected]/
--- net/caif/caif_socket.c | 1 + net/core/stream.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-)
net/caif/caif_socket.c +1 -0
@@ -1022,6 +1022,7 @@ static void caif_sock_destructor(structreturn ; }sk_stream_kill_queues (&cf_sk->sk); +WARN_ON (sk->sk_forward_alloc);caif_free_client (&cf_sk->layer); }
net/core/stream.c +0 -1
@@ -209,7 +209,6 @@ void sk_stream_kill_queues(struct sock *sk_mem_reclaim (sk);WARN_ON (sk->sk_wmem_queued); -WARN_ON (sk->sk_forward_alloc);/* It is _impossible_ for the backlog to contain anything * when we get here. All user references to this socket
Greg Kroah-Hartman
maintainerPATCH 6/9 vc_screen: dont clobber return value in vcs_read
In reply to Greg Kroah-HartmanFrom: Thomas Weißschuh <[email protected]>
commit ae3419fbac845b4d3f3a9fae4cc80c68d82cdf6e upstream.
Commit 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
While doing this it also moved the unconditional assignment of
ret = -ENXIO;
This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret.
To avoid this only assign "ret = -ENXIO" when actually needed.
[ Also, the 'goto unlock_out" needs to be just a "break", so that it
does the right thing when it exits on later iterations when partial success has happened - Linus ]
--- drivers/tty/vt/vc_screen.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/tty/vt/vc_screen.c +4 -3
@@ -266,10 +266,11 @@ vcs_read(struct file *file, char __userssize_t orig_count;long p = pos; - ret = -ENXIO ; vc =vcs_vc (inode, &viewed); -if (!vc) - goto unlock_out; +if (!vc) { + ret = -ENXIO ; +break ; + }/* Check whether we are above size each round, * as copy_to_user at the end of this loop
Greg Kroah-Hartman
maintainerPATCH 7/9 dmaengine: sh: rcar-dmac: Check for error num after dma_set_max_seg_size
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
commit da2ad87fba0891576aadda9161b8505fde81a84d upstream.
As the possible failure of the dma_set_max_seg_size(), it should be better to check the return value of the dma_set_max_seg_size().
--- drivers/dma/sh/rcar-dmac.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/dma/sh/rcar-dmac.c +4 -1
@@ -1816,7 +1816,10 @@ static int rcar_dmac_probe(struct platfo dmac->dev = &pdev->dev;platform_set_drvdata (pdev, dmac); dmac->dev->dma_parms = &dmac->parms; -dma_set_max_seg_size (dmac->dev,RCAR_DMATCR_MASK ); + ret =dma_set_max_seg_size (dmac->dev,RCAR_DMATCR_MASK ); +if (ret) +return ret; + ret =dma_set_mask_and_coherent (dmac->dev,DMA_BIT_MASK (40 ));if (ret)return ret;
Greg Kroah-Hartman
maintainerPATCH 8/9 USB: serial: option: add support for VW/Skoda "Carstick LTE"
In reply to Greg Kroah-HartmanFrom: Florian Zumbiehl <[email protected]>
commit 617c331d91077f896111044628c096802551dc66 upstream.
Add support for VW/Skoda "Carstick LTE"
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1c9e ProdID=7605 Rev=02.00 S: Manufacturer=USB Modem S: Product=USB Modem C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
The stick has AT command interfaces on interfaces 1, 2, and 3, and does PPP on interface 3.
--- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -402,6 +402,8 @@ static void option_instat_callback(struc#define LONGCHEER_VENDOR_ID 0x1c9e/* 4G Systems products */ +/* This one was sold as the VW and Skoda "Carstick LTE" */ +#define FOUR_G_SYSTEMS_PRODUCT_CARSTICK_LTE 0x7605/* This is the 4G XS Stick W14 a.k.a. Mobilcom Debitel Surf-Stick * * It seems to contain a Qualcomm QSC6240/6290 chipset */ #define FOUR_G_SYSTEMS_PRODUCT_W14 0x9603
@@ -1976,6 +1978,8 @@ static const struct usb_device_id option .driver_info = RSVD(2) }, { USB_DEVICE(AIRPLUS_VENDOR_ID, AIRPLUS_PRODUCT_MCD650) }, { USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) }, + { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_CARSTICK_LTE), + .driver_info = RSVD(0) }, { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14), .driver_info = NCTRL(0) | NCTRL(1) }, { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W100),
Greg Kroah-Hartman
maintainerPATCH 9/9 USB: core: Dont hold device lock while reading the "descriptors" sysfs file
In reply to Greg Kroah-HartmanFrom: Alan Stern <[email protected]>
commit 45bf39f8df7f05efb83b302c65ae3b9bc92b7065 upstream.
Ever since commit 83e83ecb79a8 ("usb: core: get config and string descriptors for unauthorized devices") was merged in 2013, there has been no mechanism for reallocating the rawdescriptors buffers in struct usb_device after the initial enumeration. Before that commit, the buffers would be deallocated when a device was deauthorized and reallocated when it was authorized and enumerated.
This means that the locking in the read_descriptors() routine is not needed, since the buffers it reads will never be reallocated while the routine is running. This locking can interfere with user programs trying to read a hub's descriptors via sysfs while new child devices of the hub are being initialized, since the hub is locked during this procedure.
Since the locking in read_descriptors() hasn't been needed for over nine years, we can remove it.
--- drivers/usb/core/hub.c | 5 ++--- drivers/usb/core/sysfs.c | 5 ----- 2 files changed, 2 insertions(+), 8 deletions(-)
drivers/usb/core/hub.c +2 -3
@@ -2345,9 +2345,8 @@ static int usb_enumerate_device_otg(stru* usb_enumerate_device - Read device configs/intfs/otg (usbcore-internal) * @udev: newly addressed device (in ADDRESS state) * -* This is only called by usb_new_device() and usb_authorize_device() -* and FIXME -- all comments that apply to them apply here wrt to -* environment. +* This is only called by usb_new_device() -- all comments that apply there +* apply here wrt to environment. * * If the device is WUSB and not authorized, we don't attempt to read * the string descriptors, as they will be errored out by the device
drivers/usb/core/sysfs.c +0 -5
@@ -888,11 +888,7 @@ read_descriptors(struct file *filp, strusize_t srclen, n;int cfgno;void *src; -int retval; - retval =usb_lock_device_interruptible (udev); -if (retval <0 ) -return -EINTR ;/* The binary attribute begins with the device descriptor. * Following that are the raw descriptor entries for all the * configurations (config plus subsidiary descriptors).
@@ -917,7 +913,6 @@ read_descriptors(struct file *filp, stru off -= srclen; } } -usb_unlock_device (udev);return count - nleft; }
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.275 release. There are 9 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.
Quoted 8 lines
Responses should be made by Fri, 03 Mar 2023 18:06:43 +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/v4.x/stable-review/patch-4.19.275-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.
4.19.275-rc1 compiled and booted on my x86_64 test system. No errors or regressions.
Thanks,
-- Slade
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 4.19.275 release. There are 9 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.275 release. There are 9 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 Fri, 03 Mar 2023 18:06:43 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.275-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.275 release. There are 9 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 Fri, 03 Mar 2023 18:06:43 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.275-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.19:
10 builds: 10 pass, 0 fail
22 boots: 22 pass, 0 fail
40 tests: 40 pass, 0 failLinux version: 4.19.275-rc1-gc17367998a27
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04Jon
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.275 release. There are 9 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 Fri, 03 Mar 2023 18:06:43 +0000. Anything received after that time might be too late.
Build test (gcc version 11.3.1 20230210):
mips: 63 configs -> no failure
arm: 115 configs -> no failure
arm64: 2 configs -> no failurex86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression. [1]
[1]. https://openqa.qa.codethink.co.uk/tests/2971
Signature · 2 lines
Regards Sudip
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.275 release. There are 9 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 Fri, 03 Mar 2023 18:06:43 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.275-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.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.
## Build
* kernel: 4.19.275-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.19.y
* git commit: c17367998a27f5908f6d793274690ef7f91fe0d3
* git describe: v4.19.274-10-gc17367998a27
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.274-10-gc17367998a27
## Test Regressions (compared to v4.19.274)
## Metric Regressions (compared to v4.19.274)
## Test Fixes (compared to v4.19.274)
## Metric Fixes (compared to v4.19.274)
## Test result summary
total: 96256, pass: 72823, fail: 3436, skip: 19617, xfail: 380
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 201 total, 200 passed, 1 failed
* arm64: 42 total, 41 passed, 1 failed
* i386: 29 total, 28 passed, 1 failed
* mips: 42 total, 42 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 51 total, 51 passed, 0 failed
* s390: 15 total, 15 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 37 total, 36 passed, 1 failed
## Test suites summary
* boot
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* 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-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.275 release. There are 9 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 Fri, 03 Mar 2023 18:06:43 +0000. Anything received after that time might be too late.
Build results:
total: 155 pass: 155 fail: 0 Qemu test results: total: 426 pass: 426 fail: 0
Guenter