[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140821.161816.1372290442061854758.davem@davemloft.net>
Date: Thu, 21 Aug 2014 16:18:16 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: _govind@....com
Cc: netdev@...r.kernel.org, ben@...adent.org.uk,
stephen@...workplumber.org, ssujith@...co.com, benve@...co.com
Subject: Re: [PATCH net-next v3 2/3] ethtool: Add generic options for
tunables
From: Govindarajulu Varadarajan <_govind@....com>
Date: Thu, 14 Aug 2014 14:59:19 +0530
> @@ -1621,6 +1621,50 @@ static int ethtool_get_module_eeprom(struct net_device *dev,
> modinfo.eeprom_len);
> }
>
> +static int ethtool_get_tunable(struct net_device *dev, void __user *useraddr)
> +{
> + int ret;
> + struct ethtool_tunable tuna;
> + const struct ethtool_tunable_ops *ops;
> +
> + if (copy_from_user(&tuna, useraddr, sizeof(tuna)))
> + return -EFAULT;
> + if (tuna.tcmd >= ETHTOOL_TUNABLE_MAX)
> + return -EOPNOTSUPP;
> + ops = &dev->ethtool_ops->tunable_ops[tuna.tcmd];
> + if (!ops->get)
> + return -EOPNOTSUPP;
> + ret = ops->get(dev, &tuna);
> + if (ret)
> + return ret;
> + if (copy_to_user(useraddr, &tuna, sizeof(tuna)))
> + return -EFAULT;
> +
> + return 0;
> +}
You should be validating tuna.len here, it should not be happening in the drivers
as I see you are doing in your enic implementation.
Also, having a seperate OP for each tunable might be overkill.
Consider instead one "get_tunable" and one "set_tunable" callback,
which contains a switch statement over 'tcmd'. The generic
ethtool_{g,s}et_tunable() would still validate the length, so that the
driver method does not need to do so.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists