Re: Function stack size usage (was [PATCH][1/2] SquashFS)

[Andrew Morton]

Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Andrew Morton wrote:
> > Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx> wrote:
> >>
> >>+static struct inode *squashfs_iget(struct super_block *s, squashfs_inode inode)
> >>+{
> >>+	struct inode *i;
> >>+	squashfs_sb_info *msBlk = (squashfs_sb_info *)s->s_fs_info;
> >>+	squashfs_super_block *sBlk = &msBlk->sBlk;
> >>+	unsigned int block = SQUASHFS_INODE_BLK(inode) +
> >>+		sBlk->inode_table_start;
> >>+	unsigned int offset = SQUASHFS_INODE_OFFSET(inode);
> >>+	unsigned int ino = SQUASHFS_MK_VFS_INODE(block
> >>+		- sBlk->inode_table_start, offset);
> >>+	unsigned int next_block, next_offset;
> >>+	squashfs_base_inode_header inodeb;
> > 
> > 
> > How much stack space is being used here?  Perhaps you should run
> > scripts/checkstack.pl across the whole thing.
> > 
> 
> A lot of the functions use a fair amount of stack (I never thought it 
> was excessive)...  This is the result of running checkstack.pl against 
> the code on Intel.
> 
> 0x00003a3c get_dir_index_using_name:                    596
> 0x00000d80 squashfs_iget:                               488
> 0x000044d8 squashfs_lookup:                             380
> 0x00003d00 squashfs_readdir:                            372
> 0x000020fe squashfs_fill_super:                         316
> 0x000031b8 squashfs_readpage:                           308
> 0x00002f5c read_blocklist:                              296
> 0x00003634 squashfs_readpage4K:                         284
> 
> A couple of these functions show a fair amount of stack use.  What is 
> the maximum acceptable usage,

There's no hard-and-fast rule.  The conditions running up to a stack
overrun are necessarily complex, and rare.  But you can see that for a
twenty or thirty function deep call stack, 500 bytes is a big bite out of
4k.

> i.e. do any of the above functions need 
> work to reduce their stack usage?

I'd say so, yes.  If at all possible.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/