lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 16 Sep 2022 11:24:46 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To:     Arnd Bergmann <arnd@...db.de>, kernel test robot <lkp@...el.com>
Cc:     kbuild-all@...ts.01.org, linux-kernel@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-omap@...r.kernel.org, Tomi Valkeinen <tomi.valkeinen@...com>,
        dri-devel@...ts.freedesktop.org
Subject: Re: drivers/gpu/drm/omapdrm/dss/dsi.c:1126:1: warning: the frame size
 of 1060 bytes is larger than 1024 bytes

On 15/09/2022 21:49, Arnd Bergmann wrote:
> On Thu, Sep 15, 2022, at 8:17 PM, kernel test robot wrote:
>> Hi Arnd,
>> tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> master
>> head:   3245cb65fd91cd514801bf91f5a3066d562f0ac4
>> commit: 3d427228f7370894680580fcd0381c0349624fa1 ARM: ixp4xx: enable
>> multiplatform support
> 
> This did not cause the problem, the bisection just landed on a
> commit that enabled additional configuraitons.
> 
>>     drivers/gpu/drm/omapdrm/dss/dsi.c: In function 'dsi_dump_dsi_irqs':
>>>> drivers/gpu/drm/omapdrm/dss/dsi.c:1126:1: warning: the frame size of 1060 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>      1126 | }
> 
> I think hte problem is that struct dsi_irq_stats is just too
> large, at 776 bytes. The interrupts are disabled during a copy
> from 'dsi->irq_stats' into 'stats'. A trivial workaround would
> avoid the local copy and keep interrupts disabled through
> the entire function so it can operate directly on the source
> data, but that would introduce a longer time with irqs disabled,
> which might be bad as well.
> 
> Since this is only called from a debugfs file, and reading that
> file is probably not performance critical itself, maybe
> using kmalloc on the large structure would be best.

I think that makes sense. I have sent a patch using kmalloc.

Oddly enough, I was not able to reproduce the warning with my normal 
toolchain, gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf. I even 
reduced the frame size limit to 700, and saw warnings from other places, 
but not from omapdrm.

  Tomi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ