large frame size warning when compiling

[Valdis.Kletnieks at vt.edu]

On Wed, 07 May 2014 22:06:14 +0530, Jay Aurabind said:

> When I was building the kernel, I found a warning from drivers/mfd/
> abx500-core.c, that the Frame size is larger than 1024 bytes. Apparently the
> stack frame size can be changed from the config, but my question is, whether
> 1024 bytes low ? I am on an x86_64 (core i3).

Allocating 1K on the stack is indeed evil.

> abx500-core.c had an object of struct device being allocated on stack. So
> dynamically allocating it makes the warning go away. Are there any
> implications on using dynamic allocation on this particular code?

He probably didn't realize or didn't know better.

Having said that:

> +	dummy_child = kzalloc(sizeof(struct device),GFP_KERNEL);

There's no kfree() for this. So you introduced a memory leak.

>  	list_for_each_entry(dev_entry, &abx500_list, list) {
> -		dummy_child.parent = dev_entry->dev;
> +		dummy_child->parent = dev_entry->dev;
>  		ops = &dev_entry->ops;
>
>  		if ((ops != NULL) && (ops->dump_all_banks != NULL))
> -			ops->dump_all_banks(&dummy_child);
> +			ops->dump_all_banks(dummy_child);
>  	}

	kfree(dummy_child); /* should go here... */
>  }
>  EXPORT_SYMBOL(abx500_dump_all_banks);

The weird part is that the entries on abx500_list apparently don't
have valid ->parent pointers already, so we have have to invent dummy ones.

Anybody understand why that's the case?  This smells like we're not fixing
the actual problem here, just changing the way we paper it over to be a less
ugly papering over....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140507/de99ca63/attachment.bin