Re: [PATCH] reduce stack consumption in do_mount

[Denis Vlasenko]

On Thursday 28 October 2004 20:14, Andreas Herrmann wrote:
> 
> I have seen a kernel stack overflow during mount of a SCSI disk on
> s390, 31bit, with 4K stack size.
> 
> The backtrace showed that there were 3 functions with stack
> consumption of above 200 bytes.
> 
> These are do_mount (328 bytes stack size), ext3_fill_super (288 bytes)
> and mpage_writepages (352 bytes).
> 
> For the latter 2 functions the large stack consumption seems to be
> just due to extensive inlining of GCC 3.4.
> 
> But do_mount and friends store one or more struct nameidata on the
> stack.  The size of this structure is 64 bytes on s390.
> 
> I suggest to kmalloc this structure in do_mount, do_loopback and
> do_move_mount.
> 
> Applying the patch, stack size consumption of do_mount is 80 bytes
> instead of 328 bytes. This would have avoided the kernel stack
> overflow that I have encountered.

[snip]

>  static int do_move_mount(struct nameidata *nd, char *old_name)
>  {
> -     struct nameidata old_nd, parent_nd;
> +     struct nameidata *old_nd, *parent_nd = NULL;
>       struct vfsmount *p;
>       int err = 0;
>       if (!capable(CAP_SYS_ADMIN))
>             return -EPERM;
>       if (!old_name || !*old_name)
>             return -EINVAL;
> -     err = path_lookup(old_name, LOOKUP_FOLLOW, &old_nd);
> -     if (err)
> +     old_nd = kmalloc(sizeof(*old_nd), GFP_KERNEL);
> +     if (!old_nd)
> +           return -ENOMEM;

[snip]

> +     parent_nd = kmalloc(sizeof(*parent_nd), GFP_ATOMIC);
> +     if (!parent_nd) {
> +           err = -ENOMEM;
> +           goto out2;
> +     }

Do it in one go:

	struct {
		struct nameidata old_nd, parent_nd;
	} *loc;
	loc = kmalloc(sizeof(*loc), GFP_KERNEL);
	if (loc)
		return -ENOMEM;

and add loc-> to every occurrence of old_nd and parent_nd.

Reduces time, space, fragmentation overhead and code size.
--
vda

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