On 6/4/25 01:06, Greg Kroah-Hartman wrote:
On Tue, Jun 03, 2025 at 09:00:58AM -0700, Florian Fainelli wrote:
On 6/3/25 00:58, Greg Kroah-Hartman wrote:
On Mon, Jun 02, 2025 at 09:50:24AM -0700, Florian Fainelli wrote:
On 6/2/25 09:49, Florian Fainelli wrote:
On 6/2/25 06:44, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.238 release. There are 270 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, 04 Jun 2025 13:42:20 +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.238-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
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Tested-by: Florian Fainelli florian.fainelli@broadcom.com
Similar build warning as reported for 5.4, due to the same commit:
commit b47e6abc7dc5772ecb45383d9956f9fcb7fdf33c Author: Jeongjun Park aha310510@gmail.com Date: Tue Apr 22 20:30:25 2025 +0900
tracing: Fix oob write in trace_seq_to_buffer()
commit f5178c41bb43444a6008150fe6094497135d07cb upstream.
In file included from ./include/linux/kernel.h:15, from ./include/asm-generic/bug.h:20, from ./arch/arm/include/asm/bug.h:60, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/mm.h:9, from ./include/linux/ring_buffer.h:5, from kernel/trace/trace.c:15: kernel/trace/trace.c: In function 'tracing_splice_read_pipe': ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast 20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~ ./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck' 26 | (__typecheck(x, y) && __no_side_effects(x, y)) | ^~~~~~~~~~~ ./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp' 36 | __builtin_choose_expr(__safe_cmp(x, y), \ | ^~~~~~~~~~ ./include/linux/minmax.h:45:25: note: in expansion of macro '__careful_cmp' 45 | #define min(x, y) __careful_cmp(x, y, <) | ^~~~~~~~~~~~~ kernel/trace/trace.c:6688:43: note: in expansion of macro 'min' 6688 | min((size_t)trace_seq_used(&iter->seq), | ^~~
And also this one:
commit e0a3a33cecd3ce2fde1de4ff0e223dc1db484a8d Author: Eric Dumazet edumazet@google.com Date: Wed Mar 5 13:05:50 2025 +0000
tcp: bring back NUMA dispersion in inet_ehash_locks_alloc() [ Upstream commit f8ece40786c9342249aa0a1b55e148ee23b2a746 ]on ARM64:
In file included from ./include/linux/kernel.h:15, from ./include/linux/list.h:9, from ./include/linux/module.h:12, from net/ipv4/inet_hashtables.c:12: net/ipv4/inet_hashtables.c: In function 'inet_ehash_locks_alloc': ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast 20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~ ./include/linux/minmax.h:26:18: note: in expansion of macro '__typecheck' 26 | (__typecheck(x, y) && __no_side_effects(x, y)) | ^~~~~~~~~~~ ./include/linux/minmax.h:36:31: note: in expansion of macro '__safe_cmp' 36 | __builtin_choose_expr(__safe_cmp(x, y), \ | ^~~~~~~~~~ ./include/linux/minmax.h:52:25: note: in expansion of macro '__careful_cmp' 52 | #define max(x, y) __careful_cmp(x, y, >) | ^~~~~~~~~~~~~ net/ipv4/inet_hashtables.c:946:19: note: in expansion of macro 'max' 946 | nblocks = max(nblocks, num_online_nodes() * PAGE_SIZE / locksz); | ^~~
For both of these, I'll just let them be as they are ok, it's just the mess of our min/max macro unwinding causes these issues.
Unless they really bother someone, and in that case, a patch to add the correct type to the backport to make the noise go away would be greatly appreciated.
Yeah that's a reasonable resolution, I will try to track down the missing patches for minmax.h so we are warning free for the stable kernels.
I tried in the past, it's non-trivial. What would be easier is to just properly cast the variables in the places where this warning is showing up to get rid of that warning. We've done that in some backports in the past as well.
good luck!
I see now that in 5.4.295-rc1 you have backported:
commit 36d6c6cd65043d553126b934bf1fcb79dcb58499 Author: Pan Taixi pantaixi@huaweicloud.com Date: Mon May 26 09:37:31 2025 +0800
tracing: Fix compilation warning on arm32
commit 2fbdb6d8e03b70668c0876e635506540ae92ab05 upstream.
which takes care of resolving the warning, thanks!