This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/p... 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, Sasha
------------- Pseudo-Shortlog of commits:
Andrea Parri (Microsoft) (1): Drivers: hv: vmbus: Drop error message when 'No request id available'
Andres Beltran (2): Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening hv_netvsc: Use vmbus_requestor to generate transaction IDs for VMBus hardening
Andy Shevchenko (4): serial: max310x: Use devm_clk_get_optional() to get the input clock serial: max310x: Try to get crystal clock rate from property serial: max310x: Make use of device properties serial: max310x: Unprepare and disable clock in error path
Ansuel Smith (1): regmap: allow to define reg_update_bits for no bus configuration
Baokun Li (1): ext4: make ext4_es_insert_extent() return void
Christophe Kerello (1): mmc: mmci: stm32: fix DMA API overlapping mappings warning
Cosmin Tanislav (4): serial: max310x: use regmap methods for SPI batch operations serial: max310x: use a separate regmap for each port serial: max310x: make accessing revision id interface-agnostic serial: max310x: implement I2C support
Dexuan Cui (1): hv_netvsc: Make netvsc/VF binding check both MAC and serial number
Edward Adam Davis (1): net/rds: fix WARNING in rds_conn_connect_if_down
Eric Dumazet (2): geneve: make sure to pull inner header in geneve_rx() net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
Florian Westphal (1): netfilter: nft_ct: fix l3num expectations with inet pseudo family
Hugo Villeneuve (2): serial: max310x: fail probe if clock crystal is unstable serial: max310x: prevent infinite while() loop in port startup
Ingo Molnar (1): exit: Fix typo in comment: s/sub-theads/sub-threads
Jan Kundrát (1): serial: max310x: fix IO data corruption in batched operations
Jason Xing (12): netrom: Fix a data-race around sysctl_netrom_default_path_quality netrom: Fix a data-race around sysctl_netrom_obsolescence_count_initialiser netrom: Fix data-races around sysctl_netrom_network_ttl_initialiser netrom: Fix a data-race around sysctl_netrom_transport_timeout netrom: Fix a data-race around sysctl_netrom_transport_maximum_tries netrom: Fix a data-race around sysctl_netrom_transport_acknowledge_delay netrom: Fix a data-race around sysctl_netrom_transport_busy_delay netrom: Fix a data-race around sysctl_netrom_transport_requested_window_size netrom: Fix a data-race around sysctl_netrom_transport_no_activity_timeout netrom: Fix a data-race around sysctl_netrom_routing_control netrom: Fix a data-race around sysctl_netrom_link_fails_count netrom: Fix data-races around sysctl_net_busy_read
Johannes Berg (1): um: allow not setting extra rpaths in the linux binary
John Efstathiades (4): lan78xx: Fix white space and style issues lan78xx: Add missing return code checks lan78xx: Fix partial packet errors on suspend/resume lan78xx: Fix race conditions in suspend/resume handling
Juhee Kang (1): hv_netvsc: use netif_is_bond_master() instead of open code
Lena Wang (1): netfilter: nf_conntrack_h323: Add protection for bmp length out of range
Long Li (2): hv_netvsc: Wait for completion on request SWITCH_DATA_PATH hv_netvsc: Process NETDEV_GOING_DOWN on VF hot remove
Maciej Fijalkowski (2): ixgbe: {dis, en}able irqs in ixgbe_txrx_ring_{dis, en}able i40e: disable NAPI right after disabling irqs when handling xsk_pool
Marek Vasut (1): regmap: Add bulk read/write callbacks into regmap_config
Martin KaFai Lau (2): net: Change sock_getsockopt() to take the sk ptr instead of the sock ptr bpf: net: Change sk_getsockopt() to take the sockptr_t argument
Mathias Nyman (3): xhci: remove extra loop in interrupt context xhci: prevent double-fetch of transfer and transfer event TRBs xhci: process isoc TD properly when there was a transaction error mid TD.
Michal Pecio (1): xhci: handle isoc Babble and Buffer Overrun events properly
Mike Kravetz (1): mm/hugetlb: change hugetlb_reserve_pages() to type bool
Muhammad Usama Anjum (1): selftests/mm: switch to bash from sh
Nico Pache (1): selftests: mm: fix map_hugetlb failure on 64K page size systems
Oleg Nesterov (5): getrusage: add the "signal_struct *sig" local variable getrusage: move thread_group_cputime_adjusted() outside of lock_task_sighand() getrusage: use __for_each_thread() getrusage: use sig->stats_lock rather than lock_task_sighand() exit: wait_task_zombie: kill the no longer necessary spin_lock_irq(siglock)
Oleksij Rempel (1): net: lan78xx: fix runtime PM count underflow on link stop
Ondrej Mosnacek (1): lsm: fix default return value of the socket_getpeersec_*() hooks
Paul Moore (1): lsm: make security_socket_getpeersec_stream() sockptr_t safe
Prakash Sangappa (1): mm: hugetlb pages should not be reserved by shmat() if SHM_NORESERVE
Rand Deeb (1): net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()
Sasha Levin (1): Linux 5.10.213-rc1
Shradha Gupta (1): hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed
Steven Rostedt (Google) (1): tracing/net_sched: Fix tracepoints that save qdisc_dev() as a string
Toke Høiland-Jørgensen (1): cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
Yann Gautier (1): mmc: mmci: stm32: use a buffer for unaligned DMA requests
Zhang Yi (2): ext4: refactor ext4_da_map_blocks() ext4: convert to exclusive lock while inserting delalloc extents
Makefile | 4 +- arch/um/Kconfig | 13 + arch/um/Makefile | 3 +- arch/x86/Makefile.um | 2 +- drivers/base/regmap/internal.h | 4 + drivers/base/regmap/regmap.c | 77 +- drivers/hv/channel.c | 174 +++- drivers/hv/hyperv_vmbus.h | 3 +- drivers/hv/ring_buffer.c | 28 +- drivers/mmc/host/mmci_stm32_sdmmc.c | 112 ++- drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +- drivers/net/ethernet/intel/ice/ice_main.c | 2 + drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 56 +- drivers/net/geneve.c | 18 +- drivers/net/hyperv/hyperv_net.h | 13 + drivers/net/hyperv/netvsc.c | 55 +- drivers/net/hyperv/netvsc_drv.c | 107 +- drivers/net/hyperv/rndis_filter.c | 1 + drivers/net/usb/lan78xx.c | 910 ++++++++++++++---- drivers/tty/serial/Kconfig | 1 + drivers/tty/serial/max310x.c | 378 ++++++-- drivers/usb/host/xhci-ring.c | 143 ++- drivers/usb/host/xhci.h | 3 + fs/ext4/extents.c | 5 +- fs/ext4/extents_status.c | 14 +- fs/ext4/extents_status.h | 6 +- fs/ext4/inode.c | 65 +- fs/hugetlbfs/inode.c | 17 +- include/linux/filter.h | 3 +- include/linux/hugetlb.h | 2 +- include/linux/hyperv.h | 23 + include/linux/lsm_hook_defs.h | 6 +- include/linux/lsm_hooks.h | 4 +- include/linux/regmap.h | 19 + include/linux/security.h | 11 +- include/linux/sockptr.h | 5 + include/trace/events/qdisc.h | 20 +- kernel/bpf/cpumap.c | 2 +- kernel/exit.c | 12 +- kernel/sys.c | 91 +- mm/hugetlb.c | 37 +- net/core/filter.c | 5 +- net/core/sock.c | 52 +- net/ipv6/route.c | 21 +- net/netfilter/nf_conntrack_h323_asn1.c | 4 + net/netfilter/nft_ct.c | 11 +- net/netrom/af_netrom.c | 14 +- net/netrom/nr_dev.c | 2 +- net/netrom/nr_in.c | 6 +- net/netrom/nr_out.c | 2 +- net/netrom/nr_route.c | 8 +- net/netrom/nr_subr.c | 5 +- net/rds/rdma.c | 3 + net/rds/send.c | 6 +- security/apparmor/lsm.c | 29 +- security/security.c | 35 +- security/selinux/hooks.c | 13 +- security/smack/smack_lsm.c | 19 +- .../selftests/vm/charge_reserved_hugetlb.sh | 2 +- tools/testing/selftests/vm/map_hugetlb.c | 7 + .../selftests/vm/write_hugetlb_memory.sh | 2 +- 61 files changed, 1986 insertions(+), 711 deletions(-)
Hi!
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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...
Tested-by: Pavel Machek (CIP) pavel@denx.de
Best regards, Pavel
Sasha Levin wrote on Wed, Mar 13, 2024 at 12:45:27PM -0400:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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.
Thanks Sasha for submitting a stable rc review!
If it's not too much trouble, would it be possible to have a different header in the 00 patch from the other patches for my mailbox? The mails Greg sends have the X-KernelTest-* headers (patch, tree, branch etc) only in the cover letter, while all the patches themselves only have 'X-stable: review' and 'X-Patchwork-Hint: ignore'
I don't really care much what actual tags are on which as long as there's a way to differentiate that cover letter from the rest so I can redirect it to a mailbox I actually read to notice there's a new rc to test, without having all the patches unless I explicitly look for them.
If it's difficult I'll add a regex on the subject for ' 00/' or something, I'd prefer matching only headers for robustness but just let me know.
Didn't run into any problem with the patches themselves:
The whole patch series can be found in one patch at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/p... 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.
Tested 0a70dd1e1aa9 ("Linux 5.10.213-rc1") on: - arm i.MX6ULL (Armadillo 640) - arm64 i.MX8MP (Armadillo G4)
No obvious regression in dmesg or basic tests: Tested-by: Dominique Martinet dominique.martinet@atmark-techno.com
Hello!
On Thu, 14 Mar 2024 at 01:03, Dominique Martinet asmadeus@codewreck.org wrote:
Sasha Levin wrote on Wed, Mar 13, 2024 at 12:45:27PM -0400:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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.
Thanks Sasha for submitting a stable rc review!
If it's not too much trouble, would it be possible to have a different header in the 00 patch from the other patches for my mailbox? The mails Greg sends have the X-KernelTest-* headers (patch, tree, branch etc) only in the cover letter, while all the patches themselves only have 'X-stable: review' and 'X-Patchwork-Hint: ignore'
I don't really care much what actual tags are on which as long as there's a way to differentiate that cover letter from the rest so I can redirect it to a mailbox I actually read to notice there's a new rc to test, without having all the patches unless I explicitly look for them.
I subscribe to this request. We ran into unexpected issues because all the emails in the series included the same headers as the cover.
If it's difficult I'll add a regex on the subject for ' 00/' or something, I'd prefer matching only headers for robustness but just let me know.
That's what I ended up doing, and you know the saying: I had this problem and solved it via regexes, now I have two problems. :) FWIW, here's my "problem": '^Subject: [PATCH\ [456].[0-9]+\ 0[0]*/'
Greetings!
Daniel Díaz daniel.diaz@linaro.org
On Thu, Mar 14, 2024 at 04:03:25PM +0900, Dominique Martinet wrote:
Sasha Levin wrote on Wed, Mar 13, 2024 at 12:45:27PM -0400:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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.
Thanks Sasha for submitting a stable rc review!
If it's not too much trouble, would it be possible to have a different header in the 00 patch from the other patches for my mailbox? The mails Greg sends have the X-KernelTest-* headers (patch, tree, branch etc) only in the cover letter, while all the patches themselves only have 'X-stable: review' and 'X-Patchwork-Hint: ignore'
I don't really care much what actual tags are on which as long as there's a way to differentiate that cover letter from the rest so I can redirect it to a mailbox I actually read to notice there's a new rc to test, without having all the patches unless I explicitly look for them.
If it's difficult I'll add a regex on the subject for ' 00/' or something, I'd prefer matching only headers for robustness but just let me know.
I should be able to adjust my scripts to match what Greg does. Thanks for pointing it out!
On Wed, 13 Mar 2024 at 22:16, Sasha Levin sashal@kernel.org wrote:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/p... 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, Sasha
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: 5.10.213-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc * git branch: linux-5.10.y * git commit: 0a70dd1e1aa9dfe25d4647f86675dc6dac41631e * git describe: v5.10.212-73-g0a70dd1e1aa9 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10....
## Test Regressions (compared to v5.10.212)
## Metric Regressions (compared to v5.10.212)
## Test Fixes (compared to v5.10.212)
## Metric Fixes (compared to v5.10.212)
## Test result summary total: 73104, pass: 57812, fail: 1619, skip: 13626, xfail: 47
## Build Summary * arc: 5 total, 5 passed, 0 failed * arm: 107 total, 107 passed, 0 failed * arm64: 33 total, 33 passed, 0 failed * i386: 28 total, 28 passed, 0 failed * mips: 24 total, 24 passed, 0 failed * parisc: 3 total, 0 passed, 3 failed * powerpc: 25 total, 25 passed, 0 failed * riscv: 11 total, 11 passed, 0 failed * s390: 12 total, 12 passed, 0 failed * sh: 10 total, 10 passed, 0 failed * sparc: 8 total, 8 passed, 0 failed * x86_64: 30 total, 30 passed, 0 failed
## Test suites summary * boot * kselftest-arm64 * kselftest-breakpoints * kselftest-capabilities * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-exec * kselftest-fpu * kselftest-ftrace * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-kcmp * kselftest-membarrier * kselftest-memfd * kselftest-mincore * kselftest-mqueue * kselftest-net * kselftest-net-mptcp * kselftest-openat2 * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-sigaltstack * kselftest-size * kselftest-tc-testing * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user_events * kselftest-vDSO * kselftest-x86 * kunit * kvm-unit-tests * libgpiod * 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-hugetlb * ltp-io * ltp-ipc * ltp-math * ltp-mm * ltp-nptl * ltp-pty * ltp-sched * ltp-securebits * ltp-smoke * ltp-smoketest * ltp-syscalls * ltp-tracing * perf * rcutorture
-- Linaro LKFT https://lkft.linaro.org
On 3/13/24 09:45, Sasha Levin wrote:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/p... 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, Sasha
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Tested-by: Florian Fainelli florian.fainelli@broadcom.com
Hi Sasha,
On Wed, Mar 13, 2024 at 12:45:27PM -0400, Sasha Levin wrote:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
This one still has the problem with the documentation build and does not yet include:
https://lore.kernel.org/regressions/ZeZAHnzlmZoAhkqW@eldamar.lan/
Can you pick it up as well?
Regards, Salvatore
On Thu, Mar 14, 2024 at 10:47:19PM +0100, Salvatore Bonaccorso wrote:
Hi Sasha,
On Wed, Mar 13, 2024 at 12:45:27PM -0400, Sasha Levin wrote:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
This one still has the problem with the documentation build and does not yet include:
https://lore.kernel.org/regressions/ZeZAHnzlmZoAhkqW@eldamar.lan/
Can you pick it up as well?
I'll pick it up for the next release cycle, thanks!
Hi Sasha,
On Fri, Mar 15, 2024 at 02:39:37PM -0400, Sasha Levin wrote:
On Thu, Mar 14, 2024 at 10:47:19PM +0100, Salvatore Bonaccorso wrote:
Hi Sasha,
On Wed, Mar 13, 2024 at 12:45:27PM -0400, Sasha Levin wrote:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
This one still has the problem with the documentation build and does not yet include:
https://lore.kernel.org/regressions/ZeZAHnzlmZoAhkqW@eldamar.lan/
Can you pick it up as well?
I'll pick it up for the next release cycle, thanks!
Did something went wrong here? I do not see in in the current review for 5.10.214-rc2. Can you still pick it for 5.10.214 to get documentation build working?
Thanks a lot already,
Regards, Salvatore
On Tue, Mar 26, 2024 at 07:59:31AM +0100, Salvatore Bonaccorso wrote:
Hi Sasha,
On Fri, Mar 15, 2024 at 02:39:37PM -0400, Sasha Levin wrote:
On Thu, Mar 14, 2024 at 10:47:19PM +0100, Salvatore Bonaccorso wrote:
Hi Sasha,
On Wed, Mar 13, 2024 at 12:45:27PM -0400, Sasha Levin wrote:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
This one still has the problem with the documentation build and does not yet include:
https://lore.kernel.org/regressions/ZeZAHnzlmZoAhkqW@eldamar.lan/
Can you pick it up as well?
I'll pick it up for the next release cycle, thanks!
Did something went wrong here? I do not see in in the current review for 5.10.214-rc2. Can you still pick it for 5.10.214 to get documentation build working?
Sorry for the delay, tried to have a vacation :)
Now queued up.
greg k-h
On Wednesday, March 13, 2024 22:15 IST, Sasha Levin sashal@kernel.org wrote:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/p... 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.
KernelCI report for stable-rc/linux-5.10.y for this week.
## stable-rc HEAD for linux-5.10.y: Date: 2024-03-13 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/l...
## Build failures: No build failures seen for the stable-rc/linux-5.10.y commit head \o/
## Boot failures: No **new** boot failures seen for the stable-rc/linux-5.10.y commit head \o/
Tested-by: kernelci.org bot bot@kernelci.org
Thanks, Shreeya Patel
Hi!
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
Ondrej Mosnacek (1): lsm: fix default return value of the socket_getpeersec_*() hooks
I don't see this one in 6.1.
Zhang Yi (2): ext4: convert to exclusive lock while inserting delalloc extents
I don't see this one in 6.1.
Marek Vasut (1): regmap: Add bulk read/write callbacks into regmap_config
This one quite intrusive for the stable. Plus, at least "regmap: Add missing map->bus check" is marked as fixing this one.
Best regards, Pavel
On 3/20/24 2:41 PM, Pavel Machek wrote:
Marek Vasut (1): regmap: Add bulk read/write callbacks into regmap_config
This one quite intrusive for the stable. Plus, at least "regmap: Add missing map->bus check" is marked as fixing this one.
If there is no very good reason to include that regmap patch in stable backports, I would skip it, it is a feature patch. Does any backport depend on it ?
Hi!
Marek Vasut (1): regmap: Add bulk read/write callbacks into regmap_config
This one quite intrusive for the stable. Plus, at least "regmap: Add missing map->bus check" is marked as fixing this one.
If there is no very good reason to include that regmap patch in stable backports, I would skip it, it is a feature patch. Does any backport depend on it ?
Well, yes and no.
Series of max310x patches depends on it:
!!a just a preparation; buggy, whole series for fixing this |ef8537927 285e76 o: 5.10| serial: max 310x: use regmap methods for SPI batch operations
...
!! whole series to fix corruption, which did not exist in 5.10 in the first place |57871c388 3f42b1 o: 5.10| serial: max310x: fix IO data corruption in batched operations
But according to the 3f42b1, the bug did not exist in 5.10 in the first place, so we got buggy 285e76 backported, and then fixes up-to 3f42b1 applied to fix it up.
Best regards, Pavel
On 3/22/24 10:48 AM, Pavel Machek wrote:
Hi!
Marek Vasut (1): regmap: Add bulk read/write callbacks into regmap_config
This one quite intrusive for the stable. Plus, at least "regmap: Add missing map->bus check" is marked as fixing this one.
If there is no very good reason to include that regmap patch in stable backports, I would skip it, it is a feature patch. Does any backport depend on it ?
Well, yes and no.
Series of max310x patches depends on it:
!!a just a preparation; buggy, whole series for fixing this |ef8537927 285e76 o: 5.10| serial: max 310x: use regmap methods for SPI batch operations
...
!! whole series to fix corruption, which did not exist in 5.10 in the first place |57871c388 3f42b1 o: 5.10| serial: max310x: fix IO data corruption in batched operations
But according to the 3f42b1, the bug did not exist in 5.10 in the first place, so we got buggy 285e76 backported, and then fixes up-to 3f42b1 applied to fix it up.
Then probably both max30x patches should be dropped/reverted and the regmap bulk callbacks also dropped ?
Hi!
Marek Vasut (1): regmap: Add bulk read/write callbacks into regmap_config
This one quite intrusive for the stable. Plus, at least "regmap: Add missing map->bus check" is marked as fixing this one.
If there is no very good reason to include that regmap patch in stable backports, I would skip it, it is a feature patch. Does any backport depend on it ?
Well, yes and no.
Series of max310x patches depends on it:
!!a just a preparation; buggy, whole series for fixing this |ef8537927 285e76 o: 5.10| serial: max 310x: use regmap methods for SPI batch operations
...
!! whole series to fix corruption, which did not exist in 5.10 in the first place |57871c388 3f42b1 o: 5.10| serial: max310x: fix IO data corruption in batched operations
But according to the 3f42b1, the bug did not exist in 5.10 in the first place, so we got buggy 285e76 backported, and then fixes up-to 3f42b1 applied to fix it up.
Then probably both max30x patches should be dropped/reverted and the regmap bulk callbacks also dropped ?
Agreed.
Best regards, Pavel
Hi!
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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.
While debugging "search for known-bad commit" script, I noticed:
We have
41b3cc57d626d c2e39305299f0 btrfs: clear extent buffer uptodate when we fail to write it
commit in 5.10, which is fixed by this, but we don't have that one:
651740a502411 btrfs: check WRITE_ERR when trying to read an extent buffer
Best regards, Pavel
On Wed, Mar 20, 2024 at 02:44:06PM +0100, Pavel Machek wrote:
Hi!
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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.
While debugging "search for known-bad commit" script, I noticed:
We have
41b3cc57d626d c2e39305299f0 btrfs: clear extent buffer uptodate when we fail to write it
commit in 5.10, which is fixed by this, but we don't have that one:
651740a502411 btrfs: check WRITE_ERR when trying to read an extent buffer
Hey Pavel,
There are two reasons it didn't make it into 5.10 or 5.4:
1. It doesn't build on any of those kernels, and we haven't gotten a backport we could apply.
2. There's a follow-up fix that happened soon after ( 40cdc509877b ("btrfs: skip reserved bytes warning on unmount after log cleanup failure") ) which needs a backport on it's own.
Hello!
On 13/03/24 10:45 a. m., Sasha Levin wrote:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/p... 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, Sasha
We're seeing regressions while building PowerPC with GCC 8 and 12 with ppc6xx_defconfig:
-----8<----- /builds/linux/drivers/macintosh/via-pmu-backlight.c:22:20: error: 'FB_BACKLIGHT_LEVELS' undeclared here (not in a function) 22 | static u8 bl_curve[FB_BACKLIGHT_LEVELS]; | ^~~~~~~~~~~~~~~~~~~ In file included from /builds/linux/include/linux/kernel.h:15, from /builds/linux/include/asm-generic/bug.h:20, from /builds/linux/arch/powerpc/include/asm/bug.h:109, from /builds/linux/include/linux/bug.h:5, from /builds/linux/include/linux/thread_info.h:12, from /builds/linux/arch/powerpc/include/asm/ptrace.h:264, from /builds/linux/drivers/macintosh/via-pmu-backlight.c:11: ----->8-----
Bisection points to:
commit ee550f669e91c4cb0c884f38aa915497bc201585 Author: Thomas Zimmermann tzimmermann@suse.de Date: Wed Mar 6 13:28:20 2024 +0100 arch/powerpc: Remove <linux/fb.h> from backlight code
Reverting that commit made the build pass again.
Reproducer:
tuxmake --runtime podman --target-arch powerpc --toolchain gcc-12 --kconfig ppc6xx_defconfig
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Greetings!
Daniel Díaz daniel.diaz@linaro.org
On Mon, 25 Mar 2024 at 00:55, Daniel Díaz daniel.diaz@linaro.org wrote:
Hello!
On 13/03/24 10:45 a. m., Sasha Levin wrote:
This is the start of the stable review cycle for the 5.10.213 release. There are 73 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 Mar 15 04:46:39 PM UTC 2024. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/p... 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, Sasha
We're seeing regressions while building PowerPC with GCC 8 and 12 with ppc6xx_defconfig:
-----8<----- /builds/linux/drivers/macintosh/via-pmu-backlight.c:22:20: error: 'FB_BACKLIGHT_LEVELS' undeclared here (not in a function) 22 | static u8 bl_curve[FB_BACKLIGHT_LEVELS]; | ^~~~~~~~~~~~~~~~~~~ In file included from /builds/linux/include/linux/kernel.h:15, from /builds/linux/include/asm-generic/bug.h:20, from /builds/linux/arch/powerpc/include/asm/bug.h:109, from /builds/linux/include/linux/bug.h:5, from /builds/linux/include/linux/thread_info.h:12, from /builds/linux/arch/powerpc/include/asm/ptrace.h:264, from /builds/linux/drivers/macintosh/via-pmu-backlight.c:11: ----->8-----
Bisection points to:
commit ee550f669e91c4cb0c884f38aa915497bc201585 Author: Thomas Zimmermann tzimmermann@suse.de Date: Wed Mar 6 13:28:20 2024 +0100 arch/powerpc: Remove <linux/fb.h> from backlight code
Reverting that commit made the build pass again.
Reproducer:
tuxmake --runtime podman --target-arch powerpc --toolchain gcc-12 --kconfig ppc6xx_defconfig
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Greetings!
Daniel Díaz daniel.diaz@linaro.org
Apologies for replying to the wrong email here -- it should have been for 5.10.214-rc1. Naresh took care of relaying the information to the right place.
-
Daniel Díaz -
Dominique Martinet -
Florian Fainelli -
Greg Kroah-Hartman -
Marek Vasut -
Naresh Kamboju -
Pavel Machek -
Salvatore Bonaccorso -
Sasha Levin -
Shreeya Patel