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]
Message-ID: <20090625000558.GD7035@mit.edu>
Date:	Wed, 24 Jun 2009 20:05:58 -0400
From:	Theodore Tso <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Need to potentially watch stack usage for ext4 and AIO...

On Wed, Jun 24, 2009 at 11:39:02AM -0500, Eric Sandeen wrote:
> Eric Sandeen wrote:
> > Theodore Tso wrote:
> 
> >> I can see some things we can do to optimize stack usage; for example,
> >> struct ext4_allocation_request is allocated on the stack, and the
> >> structure was laid out without any regard to space wastage caused by
> >> alignment requirements.  That won't help on x86 at all, but it will
> >> help substantially on x86_64 (since x86_64 requires that 8 byte
> >> variables must be 8-byte aligned, where as x86_64 only requires 4 byte
> >> alignment, even for unsigned long long's).  But it's going have to be
> >> a whole series of incremental improvements; I don't see any magic
> >> bullet solution to our stack usage.
> > 
> > XFS forces gcc to not inline any static function; it's extreme, but
> > maybe it'd help here too.
> 
> Giving a blanket noinline treatment to mballoc.c yields some significant
> stack savings:

So stupid question.  I can see how using noinline reduces the static
stack savings, but does it actually reduce the run-time stack usage?
After all, if function ext4_mb_foo() call ext4_mb_bar(), using
noinline is a great way for seeing which function is actually
responsible for chewing up disk space, but if ext4_mb_foo() always
calls ext4_mb_bar(), and ext4_mb_bar() is a static inline only called
once by ext4_mb_foo() unconditionally, won't we ultimately end up
using more disk space (since we also have to save registers and save
the return address on the stack)?

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ