linux-ext4 - Re: Need to potentially watch stack usage for ext4 and AIO...

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:	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