Stack usage reduced from 3024 (!) to 576.
Most of those 3k came from a bug:
#define IXGB_REG_DUMP_LEN 136*sizeof(uint32_t)
^^^^^^^^^^^^^^^^^
...
uint32_t regs_buff[IXGB_REG_DUMP_LEN];
Bug fixed. Two large on-stack variables moved to kmalloc space.
Stack usage is still high because gcc will
allocate too much space for these cases:
case ETHTOOL_GSET:{
struct ethtool_cmd ecmd = { ETHTOOL_GSET };
ixgb_ethtool_gset(adapter, &ecmd);
if (copy_to_user(addr, &ecmd, sizeof(ecmd)))
return -EFAULT;
return 0;
}
case ETHTOOL_SSET:{
struct ethtool_cmd ecmd;
if (copy_from_user(&ecmd, addr, sizeof(ecmd)))
return -EFAULT;
return ixgb_ethtool_sset(adapter, &ecmd);
}
There will be space for _two_ ecmd's on stack.
Shall it be worked around with ugly union of structs
or we'll just wait for better gcc?
Compile-tested only.
--
vda
On Sun, 2004-09-19 at 13:33, Denis Vlasenko wrote:
Stack usage is still high because gcc will
allocate too much space for these cases:
case ETHTOOL_GSET:{
struct ethtool_cmd ecmd = { ETHTOOL_GSET };
ixgb_ethtool_gset(adapter, &ecmd);
if (copy_to_user(addr, &ecmd, sizeof(ecmd)))
return -EFAULT;
return 0;
}
case ETHTOOL_SSET:{
struct ethtool_cmd ecmd;
if (copy_from_user(&ecmd, addr, sizeof(ecmd)))
return -EFAULT;
return ixgb_ethtool_sset(adapter, &ecmd);
}
There will be space for _two_ ecmd's on stack.
Shall it be worked around with ugly union of structs
or we'll just wait for better gcc?
You could convert it to use ethtool_ops.
--
Dave Dillow [off-list ref]
Dave Dillow wrote:
On Sun, 2004-09-19 at 13:33, Denis Vlasenko wrote:
quoted
Stack usage is still high because gcc will
allocate too much space for these cases:
case ETHTOOL_GSET:{
struct ethtool_cmd ecmd = { ETHTOOL_GSET };
ixgb_ethtool_gset(adapter, &ecmd);
if (copy_to_user(addr, &ecmd, sizeof(ecmd)))
return -EFAULT;
return 0;
}
case ETHTOOL_SSET:{
struct ethtool_cmd ecmd;
if (copy_from_user(&ecmd, addr, sizeof(ecmd)))
return -EFAULT;
return ixgb_ethtool_sset(adapter, &ecmd);
}
There will be space for _two_ ecmd's on stack.
Shall it be worked around with ugly union of structs
or we'll just wait for better gcc?
You could convert it to use ethtool_ops.
Check -mm to make sure viro hasn't already converted it to ethtool_ops...
Jeff
quoted
quoted
case ETHTOOL_GSET:{
struct ethtool_cmd ecmd = { ETHTOOL_GSET };
ixgb_ethtool_gset(adapter, &ecmd);
if (copy_to_user(addr, &ecmd, sizeof(ecmd)))
return -EFAULT;
return 0;
}
case ETHTOOL_SSET:{
struct ethtool_cmd ecmd;
if (copy_from_user(&ecmd, addr, sizeof(ecmd)))
return -EFAULT;
return ixgb_ethtool_sset(adapter, &ecmd);
}
There will be space for _two_ ecmd's on stack.
Shall it be worked around with ugly union of structs
or we'll just wait for better gcc?
You could convert it to use ethtool_ops.
Check -mm to make sure viro hasn't already converted it to ethtool_ops...
Admit it: it's a conspiracy. Whenever I take some code to hack on, somebody
else takes care of it before I do ;)
--
vda