This is the start of the stable review cycle for the 4.14.331 release. There are 53 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 Mon, 27 Nov 2023 16:30:48 +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.14.331-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.14.331-rc2
Eric Dumazet edumazet@google.com net: sched: fix race condition in qdisc_graft()
Dongli Zhang dongli.zhang@oracle.com scsi: virtio_scsi: limit number of hw queues by nr_cpu_ids
Kemeng Shi shikemeng@huaweicloud.com ext4: remove gdb backup copy for meta bg in setup_new_flex_group_blocks
Kemeng Shi shikemeng@huaweicloud.com ext4: correct return value of ext4_convert_meta_bg
Kemeng Shi shikemeng@huaweicloud.com ext4: correct offset of gdb backup in non meta_bg group to update_backups
Max Kellermann max.kellermann@ionos.com ext4: apply umask if ACL support is disabled
Vikash Garodia quic_vgarodia@quicinc.com media: venus: hfi: fix the check to handle session buffer requirement
Sean Young sean@mess.org media: sharp: fix sharp encoding
Heiner Kallweit hkallweit1@gmail.com i2c: i801: fix potential race in i801_block_transaction_byte_by_byte
Alexander Sverdlin alexander.sverdlin@siemens.com net: dsa: lan9303: consequently nested-lock physical MDIO
Takashi Iwai tiwai@suse.de ALSA: info: Fix potential deadlock at disconnection
Helge Deller deller@gmx.de parisc/pgtable: Do not drop upper 5 address bits of physical address
Helge Deller deller@gmx.de parisc: Prevent booting 64-bit kernels on PA1.x machines
Sanjuán García, Jorge Jorge.SanjuanGarcia@duagon.com mcb: fix error handling for different scenarios when parsing
Zhihao Cheng chengzhihao1@huawei.com jbd2: fix potential data lost in recovering journal raced with synchronizing fs bdev
Herve Codina herve.codina@bootlin.com genirq/generic_chip: Make irq_remove_generic_chip() irqdomain aware
Rong Chen rong.chen@amlogic.com mmc: meson-gx: Remove setting of CMD_CFG_ERROR
Brian Geffon bgeffon@google.com PM: hibernate: Clean up sync_read handling in snapshot_write_next()
Brian Geffon bgeffon@google.com PM: hibernate: Use __get_safe_page() rather than touching the list
Dan Carpenter dan.carpenter@linaro.org mmc: vub300: fix an error code
Lukas Wunner lukas@wunner.de PCI/sysfs: Protect driver's D3cold preference from user space
David Woodhouse dwmw@amazon.co.uk hvc/xen: fix error path in xen_hvc_init() to always register frontend driver
Paul Moore paul@paul-moore.com audit: don't WARN_ON_ONCE(!current->mm) in audit_exe_compare()
Paul Moore paul@paul-moore.com audit: don't take task_lock() in audit_exe_compare() code path
Maciej S. Szmigiero maciej.szmigiero@oracle.com KVM: x86: Ignore MSR_AMD64_TW_CFG access
Kees Cook keescook@chromium.org randstruct: Fix gcc-plugin performance mode to stay in group
Vikash Garodia quic_vgarodia@quicinc.com media: venus: hfi: add checks to perform sanity on queue pointers
Dan Carpenter dan.carpenter@linaro.org pwm: Fix double shift bug
Bob Peterson rpeterso@redhat.com gfs2: ignore negated quota changes
Hans Verkuil hverkuil-cisco@xs4all.nl media: vivid: avoid integer overflow
Rajeshwar R Shinde coolrrsh@gmail.com media: gspca: cpia1: shift-out-of-bounds in set_flicker
Axel Lin axel.lin@ingics.com i2c: sun6i-p2wi: Prevent potential division by zero
Yi Yang yiyang13@huawei.com tty: vcc: Add check for kstrdup() in vcc_probe()
Wenchao Hao haowenchao2@huawei.com scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()
Ilpo Järvinen ilpo.jarvinen@linux.intel.com atm: iphase: Do PCI error checks on own line
Cezary Rojewski cezary.rojewski@intel.com ALSA: hda: Fix possible null-ptr-deref when assigning a stream
Manas Ghandat ghandatmanas@gmail.com jfs: fix array-index-out-of-bounds in diAlloc
Manas Ghandat ghandatmanas@gmail.com jfs: fix array-index-out-of-bounds in dbFindLeaf
Juntong Deng juntong.deng@outlook.com fs/jfs: Add validity check for db_maxag and db_agpref
Juntong Deng juntong.deng@outlook.com fs/jfs: Add check for negative db_l2nbperpage
Ilpo Järvinen ilpo.jarvinen@linux.intel.com RDMA/hfi1: Use FIELD_GET() to extract Link Width
Lu Jialin lujialin4@huawei.com crypto: pcrypt - Fix hungtask for PADATA_RESET
zhujun2 zhujun2@cmss.chinamobile.com selftests/efivarfs: create-read: fix a resource leak
Mario Limonciello mario.limonciello@amd.com drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
Mario Limonciello mario.limonciello@amd.com drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
Eric Dumazet edumazet@google.com net: annotate data-races around sk->sk_dst_pending_confirm
Dmitry Antipov dmantipov@yandex.ru wifi: ath10k: fix clang-specific fortify warning
Dmitry Antipov dmantipov@yandex.ru wifi: ath9k: fix clang-specific fortify warnings
Ping-Ke Shih pkshih@realtek.com wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
Mike Rapoport (IBM) rppt@kernel.org x86/mm: Drop the 4 MB restriction on minimal NUMA node memory size
Ronald Wahl ronald.wahl@raritan.com clocksource/drivers/timer-atmel-tcb: Fix initialization on SAM9 hardware
Jacky Bai ping.bai@nxp.com clocksource/drivers/timer-imx-gpt: Fix potential memory leak
John Stultz jstultz@google.com locking/ww_mutex/test: Fix potential workqueue corruption
-------------
Diffstat:
Makefile | 4 ++-- arch/parisc/kernel/entry.S | 7 +++--- arch/parisc/kernel/head.S | 5 ++--- arch/x86/include/asm/msr-index.h | 1 + arch/x86/include/asm/numa.h | 7 ------ arch/x86/kvm/x86.c | 2 ++ arch/x86/mm/numa.c | 7 ------ crypto/pcrypt.c | 4 ++++ drivers/atm/iphase.c | 20 +++++++++-------- drivers/clocksource/tcb_clksrc.c | 1 + drivers/clocksource/timer-imx-gpt.c | 18 +++++++++++----- drivers/gpu/drm/amd/include/pptable.h | 4 ++-- drivers/gpu/drm/amd/powerplay/hwmgr/pptable_v1_0.h | 16 +++++++------- drivers/i2c/busses/i2c-i801.c | 19 ++++++++-------- drivers/i2c/busses/i2c-sun6i-p2wi.c | 5 +++++ drivers/infiniband/hw/hfi1/pcie.c | 9 ++------ drivers/mcb/mcb-core.c | 1 + drivers/mcb/mcb-parse.c | 2 +- drivers/media/platform/qcom/venus/hfi_msgs.c | 2 +- drivers/media/platform/qcom/venus/hfi_venus.c | 10 +++++++++ drivers/media/platform/vivid/vivid-rds-gen.c | 2 +- drivers/media/rc/ir-sharp-decoder.c | 8 ++++--- drivers/media/usb/gspca/cpia1.c | 3 +++ drivers/mmc/host/meson-gx-mmc.c | 1 - drivers/mmc/host/vub300.c | 1 + drivers/net/dsa/lan9303_mdio.c | 4 ++-- drivers/net/wireless/ath/ath10k/debug.c | 2 +- drivers/net/wireless/ath/ath9k/debug.c | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 2 +- drivers/pci/pci-acpi.c | 2 +- drivers/pci/pci-sysfs.c | 5 +---- drivers/scsi/libfc/fc_lport.c | 6 ++++++ drivers/scsi/virtio_scsi.c | 1 + drivers/tty/hvc/hvc_xen.c | 5 +++-- drivers/tty/vcc.c | 16 +++++++++++--- fs/ext4/acl.h | 5 +++++ fs/ext4/resize.c | 19 ++++++---------- fs/gfs2/quota.c | 11 ++++++++++ fs/jbd2/recovery.c | 8 +++++++ fs/jfs/jfs_dmap.c | 23 +++++++++++++++----- fs/jfs/jfs_imap.c | 5 ++++- include/linux/pwm.h | 4 ++-- include/net/sock.h | 6 +++--- kernel/audit_watch.c | 9 +++++++- kernel/irq/generic-chip.c | 25 ++++++++++++++++------ kernel/locking/test-ww_mutex.c | 20 ++++++++++------- kernel/padata.c | 2 +- kernel/power/snapshot.c | 16 ++++++-------- net/core/sock.c | 2 +- net/ipv4/tcp_output.c | 2 +- net/mac80211/cfg.c | 4 ++++ net/sched/sch_api.c | 5 +++-- scripts/gcc-plugins/randomize_layout_plugin.c | 11 +++++++--- sound/core/info.c | 21 +++++++++++------- sound/hda/hdac_stream.c | 6 ++++-- tools/testing/selftests/efivarfs/create-read.c | 2 ++ 56 files changed, 259 insertions(+), 151 deletions(-)
Hi!
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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-4...
Tested-by: Pavel Machek (CIP) pavel@denx.de
Best regards, Pavel
On 11/25/23 08:32, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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 Mon, 27 Nov 2023 16:30:48 +0000. Anything received after that time might be too late.
Building parisc64:generic-64bit_defconfig ... failed -------------- Error log: hppa64-linux-ld: arch/parisc/kernel/head.o: in function `$iodc_panic': (.head.text+0x64): undefined reference to `init_stack' hppa64-linux-ld: (.head.text+0x68): undefined reference to `init_stack' make[1]: *** [Makefile:1049: vmlinux] Error 1 make: *** [Makefile:153: sub-make] Error 2
Bisect log:
# bad: [39ca2c4cec46e5ef545815f62be91cba998b8927] Linux 4.14.331-rc2 # good: [bfa43eeca4797e58975ba8c54057c1f29bf20534] Linux 4.14.330 git bisect start 'HEAD' 'v4.14.330' # good: [5bc5bf29b42fb16faa4407f9c01f05dadb397f2f] media: venus: hfi: add checks to perform sanity on queue pointers git bisect good 5bc5bf29b42fb16faa4407f9c01f05dadb397f2f # good: [2e1d20a37188fbca246de24800f3fb0e9ab8d233] mcb: fix error handling for different scenarios when parsing git bisect good 2e1d20a37188fbca246de24800f3fb0e9ab8d233 # bad: [6c59b6c8a0be15fa1db3d07ffcad481aa507f8be] media: venus: hfi: fix the check to handle session buffer requirement git bisect bad 6c59b6c8a0be15fa1db3d07ffcad481aa507f8be # bad: [581615c5d0e31e0033e3458e248c6e3646b5ab13] ALSA: info: Fix potential deadlock at disconnection git bisect bad 581615c5d0e31e0033e3458e248c6e3646b5ab13 # bad: [af3526c44f86f56af5963e8ed6dc77fc1e76ccc5] parisc/pgtable: Do not drop upper 5 address bits of physical address git bisect bad af3526c44f86f56af5963e8ed6dc77fc1e76ccc5 # bad: [6eddd5699c407a706d8e914e0c88934c4e1b6e27] parisc: Prevent booting 64-bit kernels on PA1.x machines git bisect bad 6eddd5699c407a706d8e914e0c88934c4e1b6e27 # first bad commit: [6eddd5699c407a706d8e914e0c88934c4e1b6e27] parisc: Prevent booting 64-bit kernels on PA1.x machines
FWIW, the offending patch is tagged "Cc: stable@vger.kernel.org # v6.0+"
Guenter
* Guenter Roeck linux@roeck-us.net:
On 11/25/23 08:32, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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 Mon, 27 Nov 2023 16:30:48 +0000. Anything received after that time might be too late.
Building parisc64:generic-64bit_defconfig ... failed
Error log: hppa64-linux-ld: arch/parisc/kernel/head.o: in function `$iodc_panic': (.head.text+0x64): undefined reference to `init_stack' hppa64-linux-ld: (.head.text+0x68): undefined reference to `init_stack' make[1]: *** [Makefile:1049: vmlinux] Error 1 make: *** [Makefile:153: sub-make] Error 2
Indeed. Thanks for testing, Guenter!
Greg, could you please replace the patch in queue/4.14 with the one below? It simply uses another stack start, which is ok since the machine will stop anyway.
No changes needed for your other stable-queues. I tested 4.19 and it's ok as-is.
Thanks! Helge
From 29e10df694b70b4283e2d6f6852afc0ea7823e5b Mon Sep 17 00:00:00 2001 From: Helge Deller deller@gmx.de Date: Fri, 10 Nov 2023 16:13:15 +0100 Subject: [PATCH] parisc: Prevent booting 64-bit kernels on PA1.x machines
commit a406b8b424fa01f244c1aab02ba186258448c36b upstream.
Bail out early with error message when trying to boot a 64-bit kernel on 32-bit machines. This fixes the previous commit to include the check for true 64-bit kernels as well.
Patch modified for 4.14 to use __bss_stop for stack. This is OK, since the machine will halt after printing the warning.
Signed-off-by: Helge Deller deller@gmx.de Fixes: 591d2108f3abc ("parisc: Add runtime check to prevent PA2.0 kernels on PA1.x machines") Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
diff --git a/arch/parisc/kernel/head.S b/arch/parisc/kernel/head.S index 2f570a520586..2f552ff3a75f 100644 --- a/arch/parisc/kernel/head.S +++ b/arch/parisc/kernel/head.S @@ -69,9 +69,8 @@ $bss_loop: stw,ma %arg2,4(%r1) stw,ma %arg3,4(%r1)
-#if !defined(CONFIG_64BIT) && defined(CONFIG_PA20) - /* This 32-bit kernel was compiled for PA2.0 CPUs. Check current CPU - * and halt kernel if we detect a PA1.x CPU. */ +#if defined(CONFIG_PA20) + /* check for 64-bit capable CPU as required by current kernel */ ldi 32,%r10 mtctl %r10,%cr11 .level 2.0 @@ -84,7 +83,7 @@ $bss_loop: $iodc_panic: copy %arg0, %r10 copy %arg1, %r11 - load32 PA(init_stack),%sp + load32 PA(__bss_stop),%sp #define MEM_CONS 0x3A0 ldw MEM_CONS+32(%r0),%arg0 // HPA ldi ENTRY_IO_COUT,%arg1
On Sun, Nov 26, 2023 at 09:39:06PM +0100, Helge Deller wrote:
- Guenter Roeck linux@roeck-us.net:
On 11/25/23 08:32, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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 Mon, 27 Nov 2023 16:30:48 +0000. Anything received after that time might be too late.
Building parisc64:generic-64bit_defconfig ... failed
Error log: hppa64-linux-ld: arch/parisc/kernel/head.o: in function `$iodc_panic': (.head.text+0x64): undefined reference to `init_stack' hppa64-linux-ld: (.head.text+0x68): undefined reference to `init_stack' make[1]: *** [Makefile:1049: vmlinux] Error 1 make: *** [Makefile:153: sub-make] Error 2
Indeed. Thanks for testing, Guenter!
Greg, could you please replace the patch in queue/4.14 with the one below? It simply uses another stack start, which is ok since the machine will stop anyway.
No changes needed for your other stable-queues. I tested 4.19 and it's ok as-is.
Now replaced, thanks.
greg k-h
On 25/11/23 10:02 pm, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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 Mon, 27 Nov 2023 16:30:48 +0000. Anything received after that time might be too late.
No problems seen on x86_64 and aarch64 with our testing.
Tested-by: Harshit Mogalapalli harshit.m.mogalapalli@oracle.com
Thanks, Harshit
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.331-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
On Sat, 25 Nov 2023 at 22:02, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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 Mon, 27 Nov 2023 16:30:48 +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.14.331-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.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
## Build * kernel: 4.14.331-rc2 * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc * git branch: linux-4.14.y * git commit: 39ca2c4cec46e5ef545815f62be91cba998b8927 * git describe: v4.14.330-54-g39ca2c4cec46 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14....
## Test Regressions (compared to v4.14.330)
## Metric Regressions (compared to v4.14.330)
## Test Fixes (compared to v4.14.330)
## Metric Fixes (compared to v4.14.330)
## Test result summary total: 54577, pass: 45662, fail: 1547, skip: 7326, xfail: 42
## Build Summary * arc: 10 total, 10 passed, 0 failed * arm: 108 total, 103 passed, 5 failed * arm64: 35 total, 31 passed, 4 failed * i386: 21 total, 18 passed, 3 failed * mips: 19 total, 19 passed, 0 failed * parisc: 3 total, 0 passed, 3 failed * powerpc: 8 total, 7 passed, 1 failed * s390: 6 total, 5 passed, 1 failed * sh: 10 total, 10 passed, 0 failed * sparc: 6 total, 6 passed, 0 failed * x86_64: 27 total, 23 passed, 4 failed
## Test suites summary * boot * 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-filesystems-epoll * kselftest-firmware * kselftest-fpu * kselftest-ftrace * kselftest-futex * kselftest-gpio * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-membarrier * kselftest-memfd * kselftest-memory-hotplug * kselftest-mincore * kselftest-mount * kselftest-mqueue * kselftest-net * kselftest-net-forwarding * kselftest-net-mptcp * 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 * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-user_events * kselftest-vDSO * kselftest-vm * kselftest-watchdog * kselftest-zram * kunit * log-parser-boot * log-parser-test * ltp-cap_bounds * ltp-commands * ltp-containers * ltp-controllers * ltp-crypto * ltp-cve * 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-pty * ltp-sched * ltp-securebits * ltp-smoke * ltp-syscalls * ltp-tracing * rcutorture
-- Linaro LKFT https://lkft.linaro.org
Hi!
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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.
Mario Limonciello mario.limonciello@amd.com drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga Mario Limonciello mario.limonciello@amd.com drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
I believed that the agreement with maintarner was that these are not suitable for stable? There's no actual bug, but UBSAN warns anyway...
zhujun2 zhujun2@cmss.chinamobile.com selftests/efivarfs: create-read: fix a resource leak
This is wrong. It is patching userland code, there's no memory leak, kernel closes file descriptors upon task exit.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com RDMA/hfi1: Use FIELD_GET() to extract Link Width
This is a good cleanup, but not a bugfix.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com atm: iphase: Do PCI error checks on own line
Just a cleanup, not sure why it was picked for stable.
Best regards, Pavel
On Mon, 27 Nov 2023, Pavel Machek wrote:
Hi!
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com RDMA/hfi1: Use FIELD_GET() to extract Link Width
This is a good cleanup, but not a bugfix.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com atm: iphase: Do PCI error checks on own line
Just a cleanup, not sure why it was picked for stable.
Just an additional bit of information, there have been quite many cleanups from me which have recently gotten the stable notification for some mysterious reason. When I had tens of them in my inbox and for various kernel versions, I immediately stopped caring to stop it from happening.
AFAIK, I've not marked those for stable inclusion so I've no idea what got them included.
Hi!
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com RDMA/hfi1: Use FIELD_GET() to extract Link Width
This is a good cleanup, but not a bugfix.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com atm: iphase: Do PCI error checks on own line
Just a cleanup, not sure why it was picked for stable.
Just an additional bit of information, there have been quite many cleanups from me which have recently gotten the stable notification for some mysterious reason. When I had tens of them in my inbox and for various kernel versions, I immediately stopped caring to stop it from happening.
AFAIK, I've not marked those for stable inclusion so I've no idea what got them included.
Fixes tag can do it. Plus, "AUTOSEL" robot does it randomly, with no human oversight :-(.
Best regards, Pavel
On Tue, Nov 28, 2023 at 09:39:36PM +0100, Pavel Machek wrote:
Hi!
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com RDMA/hfi1: Use FIELD_GET() to extract Link Width
This is a good cleanup, but not a bugfix.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com atm: iphase: Do PCI error checks on own line
Just a cleanup, not sure why it was picked for stable.
Just an additional bit of information, there have been quite many cleanups from me which have recently gotten the stable notification for some mysterious reason. When I had tens of them in my inbox and for various kernel versions, I immediately stopped caring to stop it from happening.
AFAIK, I've not marked those for stable inclusion so I've no idea what got them included.
Fixes tag can do it. Plus, "AUTOSEL" robot does it randomly, with no human oversight :-(.
the autosel bot has lots of oversight.
Hi!
Ilpo Järvinen ilpo.jarvinen@linux.intel.com RDMA/hfi1: Use FIELD_GET() to extract Link Width
This is a good cleanup, but not a bugfix.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com atm: iphase: Do PCI error checks on own line
Just a cleanup, not sure why it was picked for stable.
Just an additional bit of information, there have been quite many cleanups from me which have recently gotten the stable notification for some mysterious reason. When I had tens of them in my inbox and for various kernel versions, I immediately stopped caring to stop it from happening.
AFAIK, I've not marked those for stable inclusion so I've no idea what got them included.
Fixes tag can do it. Plus, "AUTOSEL" robot does it randomly, with no human oversight :-(.
the autosel bot has lots of oversight.
Can you describe how that oversight works?
Best regards, Pavel
On Tue, Nov 28, 2023 at 09:48:42PM +0100, Pavel Machek wrote:
Hi!
Ilpo Järvinen ilpo.jarvinen@linux.intel.com RDMA/hfi1: Use FIELD_GET() to extract Link Width
This is a good cleanup, but not a bugfix.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com atm: iphase: Do PCI error checks on own line
Just a cleanup, not sure why it was picked for stable.
Just an additional bit of information, there have been quite many cleanups from me which have recently gotten the stable notification for some mysterious reason. When I had tens of them in my inbox and for various kernel versions, I immediately stopped caring to stop it from happening.
AFAIK, I've not marked those for stable inclusion so I've no idea what got them included.
Fixes tag can do it. Plus, "AUTOSEL" robot does it randomly, with no human oversight :-(.
the autosel bot has lots of oversight.
Can you describe how that oversight works?
There have been many papers and presentations about it, no need for me to say it all here again...
On Tue 2023-11-28 21:10:03, Greg Kroah-Hartman wrote:
On Tue, Nov 28, 2023 at 09:48:42PM +0100, Pavel Machek wrote:
Hi!
> Ilpo Järvinen ilpo.jarvinen@linux.intel.com > RDMA/hfi1: Use FIELD_GET() to extract Link Width
This is a good cleanup, but not a bugfix.
> Ilpo Järvinen ilpo.jarvinen@linux.intel.com > atm: iphase: Do PCI error checks on own line
Just a cleanup, not sure why it was picked for stable.
Just an additional bit of information, there have been quite many cleanups from me which have recently gotten the stable notification for some mysterious reason. When I had tens of them in my inbox and for various kernel versions, I immediately stopped caring to stop it from happening.
AFAIK, I've not marked those for stable inclusion so I've no idea what got them included.
Fixes tag can do it. Plus, "AUTOSEL" robot does it randomly, with no human oversight :-(.
the autosel bot has lots of oversight.
Can you describe how that oversight works?
There have been many papers and presentations about it, no need for me to say it all here again...
Give a pointer.
And explain why AUTOSEL is full of cleanups, as noticed by Ilpo, me and others. AFAICT Sasha does not hand-check patches picked by AUTOSEL, simply spams the mailing lists, and hopes that maintainers will react. And they won't, because they don't understand the implications, and simply ignore the spam. Or they will, and Sasha simply ignores the reply.
If the process is something else, give me a pointer to explanation.
Thanks, Pavel
On Wed, Nov 29, 2023 at 10:00:44AM +0100, Pavel Machek wrote:
On Tue 2023-11-28 21:10:03, Greg Kroah-Hartman wrote:
On Tue, Nov 28, 2023 at 09:48:42PM +0100, Pavel Machek wrote:
Hi!
> > Ilpo Järvinen ilpo.jarvinen@linux.intel.com > > RDMA/hfi1: Use FIELD_GET() to extract Link Width > > This is a good cleanup, but not a bugfix. > > > Ilpo Järvinen ilpo.jarvinen@linux.intel.com > > atm: iphase: Do PCI error checks on own line > > Just a cleanup, not sure why it was picked for stable.
Just an additional bit of information, there have been quite many cleanups from me which have recently gotten the stable notification for some mysterious reason. When I had tens of them in my inbox and for various kernel versions, I immediately stopped caring to stop it from happening.
AFAIK, I've not marked those for stable inclusion so I've no idea what got them included.
Fixes tag can do it. Plus, "AUTOSEL" robot does it randomly, with no human oversight :-(.
the autosel bot has lots of oversight.
Can you describe how that oversight works?
There have been many papers and presentations about it, no need for me to say it all here again...
Give a pointer.
And explain why AUTOSEL is full of cleanups, as noticed by Ilpo, me and others. AFAICT Sasha does not hand-check patches picked by AUTOSEL, simply spams the mailing lists, and hopes that maintainers will react. And they won't, because they don't understand the
Awesome feedback, thanks.
implications, and simply ignore the spam. Or they will, and Sasha simply ignores the reply.
Incorrect, I just gotten tired of litigating this with *you*.
How about this: instead of complaining about work you get for free, try doing it yourself and send us a list of patches that should go into the -stable tree during the next merge window. Deal?
On Tue, 28 Nov 2023, Pavel Machek wrote:
Hi!
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com RDMA/hfi1: Use FIELD_GET() to extract Link Width
This is a good cleanup, but not a bugfix.
Ilpo Järvinen ilpo.jarvinen@linux.intel.com atm: iphase: Do PCI error checks on own line
Just a cleanup, not sure why it was picked for stable.
Just an additional bit of information, there have been quite many cleanups from me which have recently gotten the stable notification for some mysterious reason. When I had tens of them in my inbox and for various kernel versions, I immediately stopped caring to stop it from happening.
AFAIK, I've not marked those for stable inclusion so I've no idea what got them included.
Fixes tag can do it. Plus, "AUTOSEL" robot does it randomly, with no human oversight :-(.
I know Fixes tag will surely do it. However, the two above mentioned patches were in series that were sent without any Fixes tags nor cc stables for any of the patches within the same series.
On Sat, 25 Nov 2023 16:32:43 +0000, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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 Mon, 27 Nov 2023 16:30:48 +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.14.331-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.14: 10 builds: 10 pass, 0 fail 16 boots: 16 pass, 0 fail 32 tests: 32 pass, 0 fail
Linux version: 4.14.331-rc2-g0957336c00be Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Tested-by: Jon Hunter jonathanh@nvidia.com
Jon
On Sat, Nov 25, 2023 at 04:32:43PM +0000, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.331 release. There are 53 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 Mon, 27 Nov 2023 16:30:48 +0000. Anything received after that time might be too late.
For v4.14.330-54-g0957336c00be:
Build results: total: 139 pass: 139 fail: 0 Qemu test results: total: 440 pass: 440 fail: 0
Tested-by: Guenter Roeck linux@roeck-us.net
Guenter
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Guenter Roeck -
Harshit Mogalapalli -
Helge Deller -
Ilpo Järvinen -
Jon Hunter -
Naresh Kamboju -
Pavel Machek -
Sasha Levin