Phillip Lougher <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > Phillip Lougher <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
