From: Ben Hutchings <ben@decadent.org.uk>
To: David Decotigny <ddecotig@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Amir Vadai <amirv@mellanox.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-api@vger.kernel.org, linux-mips@linux-mips.org,
fcoe-devel@open-fcoe.org
Cc: Eric Dumazet <edumazet@google.com>,
Eugenia Emantayev <eugenia@mellanox.co.il>,
Or Gerlitz <ogerlitz@mellanox.com>,
Ido Shamay <idos@mellanox.com>, Joe Perches <joe@perches.com>,
Saeed Mahameed <saeedm@mellanox.com>,
Govindarajulu Varadarajan <_govind@gmx.com>,
Venkata Duvvuru <VenkatKumar.Duvvuru@Emulex.Com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Eyal Perry <eyalpe@mellanox.com>,
Pravin B Shelar <pshelar@nicira.com>,
Ed Swierk <eswierk@skyportsystems.com>,
Robert Love <robert.w.love@intel.com>,
"James E.J. Bottomley" <JBottomley@parallels.com>,
Yuval Mintz <Yuval.Mintz@qlogic.com>,
David Decotigny <decot@googlers.com>
Subject: Re: [PATCH net-next v3 03/17] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API
Date: Tue, 01 Dec 2015 01:52:31 +0000 [thread overview]
Message-ID: <1448934751.30642.32.camel@decadent.org.uk> (raw)
In-Reply-To: <1448921155-24764-4-git-send-email-ddecotig@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8233 bytes --]
On Mon, 2015-11-30 at 14:05 -0800, David Decotigny wrote:
> From: David Decotigny <decot@googlers.com>
>
> This patch defines a new ETHTOOL_GSETTINGS/SSETTINGS API, handled by
> the new get_ksettings/set_ksettings callbacks. This API provides
> support for most legacy ethtool_cmd fields, adds support for larger
> link mode masks (up to 4064 bits, variable length), and removes
> ethtool_cmd deprecated fields (transceiver/maxrxpkt/maxtxpkt).
As you have to introduce new commands and a new structure, please
include the word 'link' in their names.
[...]
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 653dc9c..6de122d 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -12,6 +12,7 @@
> #ifndef _LINUX_ETHTOOL_H
> #define _LINUX_ETHTOOL_H
>
> +#include
> #include
> #include
>
> @@ -40,9 +41,6 @@ struct compat_ethtool_rxnfc {
>
> #include
>
> -extern int __ethtool_get_settings(struct net_device *dev,
> - struct ethtool_cmd *cmd);
> -
> /**
> * enum ethtool_phys_id_state - indicator state for physical identification
> * @ETHTOOL_ID_INACTIVE: Physical ID indicator should be deactivated
> @@ -97,13 +95,85 @@ static inline u32 ethtool_rxfh_indir_default(u32 index, u32 n_rx_rings)
> return index % n_rx_rings;
> }
>
> +#define __ETHTOOL_LINK_MODE_IS_VALID_BIT(indice) \
> + ((indice) >= 0 && (indice) <= __ETHTOOL_LINK_MODE_LAST)
'indice'? Shoudn't this be 'index' or 'mode'?
>
> +/* number of link mode bits handled internally by kernel */
> +#define __ETHTOOL_LINK_MODE_MASK_NBITS (__ETHTOOL_LINK_MODE_LAST+1)
Spaces around the + sign.
>
> +typedef struct {
> + unsigned long mask[BITS_TO_LONGS(__ETHTOOL_LINK_MODE_MASK_NBITS)];
> +} ethtool_link_mode_mask_t;
checkpatch claims you shouldn't introduce such typedefs.
[...]
>
> +/**
> + * struct ethtool_settings - link control and status
> + * This structure deprecates struct %ethtool_cmd.
We do the deprecating; the structures are purely passive.
[...]
>
> + * Deprecated fields should be ignored by both users and drivers.
Delete this last paragraph.
[...]
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -352,6 +352,388 @@ static int __ethtool_set_flags(struct net_device *dev, u32 data)
> return 0;
> }
>
> +/* TODO: remove when %ETHTOOL_GSET/%ETHTOOL_SSET disappear */
Please delete this TODO and all the similar ones; we don't remove
userland APIs just because they're deprecated.
[...]
>
> +/* number of 32-bit words to store the user's link mode bitmaps */
> +#define __ETHTOOL_LINK_MODE_MASK_NU32 \
> + ((__ETHTOOL_LINK_MODE_MASK_NBITS + 31) / 32)
Should use DIV_ROUND_UP().
>
> +/* layout of the struct passed from/to userland */
> +struct ethtool_usettings {
> + struct ethtool_settings parent;
> + struct {
> + __u32 supported[__ETHTOOL_LINK_MODE_MASK_NU32] __aligned(4);
> + __u32 advertising[__ETHTOOL_LINK_MODE_MASK_NU32] __aligned(4);
> + __u32 lp_advertising[
> + __ETHTOOL_LINK_MODE_MASK_NU32] __aligned(4);
Why __aligned(4)? Do you have any reason to think that some padding
might be added otherwise?
[...]
> +#if BITS_PER_LONG == 64
> +static unsigned long _shl32(__u32 v)
> +{
> + return ((unsigned long)v) << 32;
> +}
> +#endif
> +
> +/* convert a user's __u32[] bitmap in user space to a kernel internal
> + * bitmap. return 0 on success, errno on error. this assumes that
> + * link_mode_masks_nwords was already verified
> + */
> +static int load_ksettings_from_user(struct ethtool_ksettings *to,
> + const void __user *from)
> +{
> + struct ethtool_usettings usettings;
> +#if BITS_PER_LONG != 32
> + unsigned i;
> +#endif
> +
> + if (copy_from_user(&usettings, from, sizeof(usettings)))
> + return -EFAULT;
> +
> + /* make sure we didn't receive garbage between last allowed bit
> + * and end of last u32 word
> + */
> + if (__ETHTOOL_LINK_MODE_MASK_NBITS % 32) {
> + const u32 allowed = (
> + 1U << (__ETHTOOL_LINK_MODE_MASK_NBITS % 32)) - 1;
> + if (usettings.link_modes.supported[
> + __ETHTOOL_LINK_MODE_MASK_NU32 - 1] & ~allowed)
> + return -EINVAL;
> + if (usettings.link_modes.advertising[
> + __ETHTOOL_LINK_MODE_MASK_NU32 - 1] & ~allowed)
> + return -EINVAL;
> + if (usettings.link_modes.lp_advertising[
> + __ETHTOOL_LINK_MODE_MASK_NU32 - 1] & ~allowed)
> + return -EINVAL;
> + }
> +
> +#if BITS_PER_LONG == 32
> + compiletime_assert(sizeof(*to) == sizeof(usettings),
> + "sizeof(ulong) != 32");
> + memcpy(to, &usettings, sizeof(*to));
> +#elif BITS_PER_LONG == 64
> + memset(to, 0, sizeof(*to));
This memset() looks redundant.
> + memcpy(&to->parent, &usettings.parent, sizeof(to->parent));
> + for (i = 0 ; i < __ETHTOOL_LINK_MODE_MASK_NU32 ; ++i) {
> + if (0 == (i & 1)) {
> + to->link_modes.supported.mask[i >> 1]
> + = usettings.link_modes.supported[i];
> + to->link_modes.advertising.mask[i >> 1]
> + = usettings.link_modes.advertising[i];
> + to->link_modes.lp_advertising.mask[i >> 1]
> + = usettings.link_modes.lp_advertising[i];
> + } else {
> + to->link_modes.supported.mask[i >> 1] |= _shl32(
> + usettings.link_modes.supported[i]);
> + to->link_modes.advertising.mask[i >> 1] |= _shl32(
> + usettings.link_modes.advertising[i]);
> + to->link_modes.lp_advertising.mask[i >> 1] |= _shl32(
> + usettings.link_modes.lp_advertising[i]);
> + }
> + }
> +#else
> +# error "unsupported ulong width"
> +#endif
> + return 0;
> +}
I think the array conversion ought to be a separate function that you
can call 3 times here, rather than repeating it here. In fact that
could be a general function in lib/bitmap.c.
Similarly for the opposite conversion below.
[...]
> static int ethtool_get_settings(struct net_device *dev, void __user *useraddr)
> {
> - int err;
> struct ethtool_cmd cmd;
>
> - err = __ethtool_get_settings(dev, &cmd);
> - if (err < 0)
> - return err;
> + ASSERT_RTNL();
> +
> + if (dev->ethtool_ops->get_ksettings) {
> + /* First, use ksettings API if it is supported */
> + int err;
> + struct ethtool_ksettings ksettings;
> +
> + memset(&ksettings, 0, sizeof(ksettings));
> + err = dev->ethtool_ops->get_ksettings(dev, &ksettings);
> + if (err < 0)
> + return err;
> + if (!convert_ksettings_to_legacy_settings(&cmd, &ksettings)) {
> + static int __warned;
> +
> + /* not all bitmaps could be translated
> + * acurately to legacy API: print warning with
> + * netdev name, but does still succeed
> + */
> + if (!__warned)
> + netdev_warn(dev, "please upgrade ethtool\n");
ethtool isn't the only program that uses this API, not by a long way.
And since it's the program at fault, not the device, it doesn't make a
lot of sense to use netdev_warn().
So I suggest a message more like that in warn_legacy_capability_use()
in kernel/capability.c.
[...]
> static int ethtool_set_settings(struct net_device *dev, void __user *useraddr)
> {
> struct ethtool_cmd cmd;
>
> - if (!dev->ethtool_ops->set_settings)
> - return -EOPNOTSUPP;
> + ASSERT_RTNL();
>
> if (copy_from_user(&cmd, useraddr, sizeof(cmd)))
> return -EFAULT;
>
> + /* first, try new %ethtool_ksettings API. */
> + if (dev->ethtool_ops->set_ksettings) {
> + struct ethtool_ksettings ksettings;
> +
> + if (!convert_legacy_settings_to_ksettings(&ksettings, &cmd)) {
> + static int __warned;
> +
> + /* rejecting setting deprecated fields
> + * transceiver/maxtxpkt/maxrxpkt
> + */
> + if (!__warned)
> + netdev_warn(dev, "please upgrade ethtool");
I don't think this makes sense - it's not as if ethtool will
automatically try to set these without it being explicitly requested by
the user. Just return -EINVAL without logging anything.
> + __warned = 1;
> + return -EINVAL;
> + }
[...]
Ben.
--
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
next prev parent reply other threads:[~2015-12-01 1:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-30 22:05 [PATCH net-next v3 00/17] RFC: new ETHTOOL_GSETTINGS/SSETTINGS API David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 01/17] net: usnic: remove unused call to ethtool_ops::get_settings David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 02/17] net: usnic: use __ethtool_get_settings David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 03/17] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API David Decotigny
2015-12-01 0:04 ` kbuild test robot
2015-12-01 0:47 ` David Decotigny
2015-12-01 1:52 ` Ben Hutchings [this message]
2015-12-02 3:13 ` David Miller
2015-12-02 6:00 ` David Decotigny
2015-12-02 17:31 ` David Miller
2015-11-30 22:05 ` [PATCH net-next v3 04/17] tx4939: use __ethtool_get_ksettings David Decotigny
2015-11-30 23:51 ` Ralf Baechle
2015-11-30 22:05 ` [PATCH net-next v3 05/17] net: usnic: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 06/17] net: bonding: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 07/17] net: ipvlan: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 08/17] net: macvlan: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 09/17] net: team: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 10/17] net: fcoe: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 11/17] net: rdma: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 12/17] net: 8021q: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 13/17] net: bridge: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 14/17] net: core: " David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 15/17] net: ethtool: remove unused __ethtool_get_settings David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 16/17] net: mlx4: convenience predicate for debug messages David Decotigny
2015-11-30 22:05 ` [PATCH net-next v3 17/17] net: mlx4: use new ETHTOOL_G/SSETTINGS API David Decotigny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1448934751.30642.32.camel@decadent.org.uk \
--to=ben@decadent.org.uk \
--cc=JBottomley@parallels.com \
--cc=VenkatKumar.Duvvuru@Emulex.Com \
--cc=Yuval.Mintz@qlogic.com \
--cc=_govind@gmx.com \
--cc=amirv@mellanox.com \
--cc=davem@davemloft.net \
--cc=ddecotig@gmail.com \
--cc=decot@googlers.com \
--cc=edumazet@google.com \
--cc=eswierk@skyportsystems.com \
--cc=eugenia@mellanox.co.il \
--cc=eyalpe@mellanox.com \
--cc=fcoe-devel@open-fcoe.org \
--cc=idos@mellanox.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=joe@perches.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=netdev@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=pshelar@nicira.com \
--cc=robert.w.love@intel.com \
--cc=saeedm@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox