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, 18 Oct 2019 18:19:15 -0700
From:   Joe Perches <joe@...ches.com>
To:     Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Ladislav Michl <ladis@...ux-mips.org>
Cc:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] omapfb: reduce stack usage

On Fri, 2019-10-18 at 23:30 +0100, Sudip Mukherjee wrote:
> On Fri, Oct 18, 2019 at 07:27:28PM +0200, Ladislav Michl wrote:
> > On Fri, Oct 18, 2019 at 05:30:04PM +0100, Sudip Mukherjee wrote:
> > > The build of xtensa allmodconfig is giving a warning of:
> > > In function 'dsi_dump_dsidev_irqs':
> > > warning: the frame size of 1120 bytes is larger than 1024 bytes
> > > 
> > > Allocate the memory for 'struct dsi_irq_stats' dynamically instead
> > > of assigning it in stack.
> > 
> > So now function can fail silently, executes longer, code is sligthly
> > bigger... And all that to silent warning about exceeding frame size.
> > Is it really worth "fixing"?

Depends if it could fail in practice due to a stack overrun.

> The only point of failure is if kmalloc() fails and if kmalloc() fails then
> there will be error prints in dmesg to tell the user that there is no
> memory left in the system. About the size bigger, it seems
> the drivers/video/fbdev/omap2/omapfb/dss/dsi.o file is smaller with the
> patch.
> This is without the patch:
> -rw-r--r-- 1 sudip sudip 316856 Oct 18 22:27 drivers/video/fbdev/omap2/omapfb/dss/dsi.o
> And this is with the patch:
> -rw-r--r-- 1 sudip sudip 316436 Oct 18 20:09 drivers/video/fbdev/omap2/omapfb/dss/dsi.o
> 
> And also, objdump shows me that <dsi_dump_dsidev_irqs> was taking up 0xD7D
> bytes, and now with the patch it is taking up 0xBED bytes, thats a saving
> of 400 bytes. If it has 400 bytes of less code to execute will it not be
> faster now?

You should try compiling without all the debugging symbols (defconfig)

> But, I may be totally wrong in my thinking, and in that case, please feel
> free to reject the patch.

Without your patch:

$ objdump -x drivers/video/fbdev/omap2/omapfb/dss/dsi.o | grep dsi_dump_dsidev_irqs
00000d20 l     F .text	0000061c dsi_dump_dsidev_irqs

With your patch:

$ objdump -x drivers/video/fbdev/omap2/omapfb/dss/dsi.o | grep dsi_dump_dsidev_irqs
00000d20 l     F .text	00000638 dsi_dump_dsidev_irqs


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ