On Wed, Sep 8, 2021 at 10:55 PM Nathan Chancellor <nathan@xxxxxxxxxx> wrote: > On Tue, Sep 07, 2021 at 11:11:17AM +0200, Arnd Bergmann wrote: > > On Tue, Sep 7, 2021 at 4:32 AM Nathan Chancellor <nathan@xxxxxxxxxx> wrote: function 'rtw_aes_decrypt' [-Werror,-Wframe-larger-than] > > > arm32-fedora.log: drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3043:6: error: stack frame size (1376) exceeds limit (1024) in function 'bw_calcs' [-Werror,-Wframe-larger-than] > > > arm32-fedora.log: drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:77:13: error: stack frame size (5384) exceeds limit (1024) in function 'calculate_bandwidth' [-Werror,-Wframe-larger-than] > > > > > > Aside from the dce_calcs.c warnings, these do not seem too bad. I > > > believe allmodconfig turns on UBSAN but it could also be aggressive > > > inlining by clang. I intend to look at all -Wframe-large-than warnings > > > closely later. > > > > I've had them close to zero in the past, but a couple of new ones came in. > > > > The amdgpu ones are probably not fixable unless they stop using 64-bit > > floats in the kernel for > > random calculations. The crypto/* ones tend to be compiler bugs, but hard to fix > > I have started taking a look at these. Most of the allmodconfig ones > appear to be related to CONFIG_KASAN, which is now supported for > CONFIG_ARM. > > The two in bpmp-debugfs.c appear regardless of CONFIG_KASAN and it turns > out that you actually submitted a patch for these: > > https://lore.kernel.org/r/20201204193714.3134651-1-arnd@xxxxxxxxxx/ > > Is it worth resending or pinging that? I'm now restarting from a clean tree for my randconfig patches to see which ones are actually needed, will hopefully get to that. > The dce_calcs.c ones also appear without CONFIG_KASAN, which you noted > is probably unavoidable. (adding amdgpu folks to Cc here) Harry Wentland did a nice rework for dcn_calcs.c that should also be portable to dce_calcs.c, I hope that he will be able to get to that as well. Looking at my older patches now, I found that I had only suppressed that one and given up fixing it, but I did put my analysis into https://bugs.llvm.org/show_bug.cgi?id=42551, which should be helpful for addressing it in either the kernel or the compiler. Arnd
