From: Jakub Kicinski <kuba@kernel.org>
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com,
Jakub Kicinski <kuba@kernel.org>
Subject: [PATCH net-next v2 0/2] ethtool: netlink: handle SET intro/outro in the common code
Date: Wed, 25 Jan 2023 15:05:17 -0800 [thread overview]
Message-ID: <20230125230519.1069676-1-kuba@kernel.org> (raw)
Factor out the boilerplate code from SET handlers to common code.
I volunteered to refactor the extack in GET in a conversation
with Vladimir but I gave up.
The handling of failures during dump in GET handlers is a bit
unclear to me. Some code uses presence of info as indication
of dump and tries to avoid reporting errors altogether
(including extack messages).
There's also the question of whether we should have a validation
callback (similar to .set_validate here) for GET. It looks like
.parse_request was expected to perform the validation. It takes
the extack and tb directly, not via info:
int (*parse_request)(struct ethnl_req_info *req_info,
struct nlattr **tb,
struct netlink_ext_ack *extack);
int (*prepare_data)(const struct ethnl_req_info *req_info,
struct ethnl_reply_data *reply_data,
struct genl_info *info);
so no crashes dereferencing info possible.
But .parse_request doesn't run under rtnl nor ethnl_ops_begin().
As a result some implementations defer validation until .prepare_data
where all the locks are held and they can call out to the driver.
All this makes me think that maybe we should refactor GET in the
same direction I'm refactoring SET. Split .prepare_data, take
more locks in the core, and add a validation helper which would
take extack directly:
- ret = ops->prepare_data(req_info, reply_data, info);
+ ret = ops->prepare_data_validate(req_info, reply_data, attrs, extack);
+ if (ret < 1) // if 0 -> skip for dump; -EOPNOTSUPP in do
+ goto err1;
+
+ ret = ethnl_ops_begin(dev);
+ if (ret)
+ goto err1;
+
+ ret = ops->prepare_data(req_info, reply_data); // no extack
+ ethnl_ops_complete(dev);
I'll file that away as a TODO for posterity / older me.
v2:
- invert checks for coalescing to avoid error code changes
- rebase and convert MM as well
v1: https://lore.kernel.org/all/20230121054430.642280-1-kuba@kernel.org/
Jakub Kicinski (2):
ethtool: netlink: handle SET intro/outro in the common code
ethtool: netlink: convert commands to common SET
net/ethtool/channels.c | 92 ++++++++++++++----------------------
net/ethtool/coalesce.c | 92 ++++++++++++++++--------------------
net/ethtool/debug.c | 71 ++++++++++++----------------
net/ethtool/eee.c | 78 ++++++++++++-------------------
net/ethtool/fec.c | 83 +++++++++++++--------------------
net/ethtool/linkinfo.c | 81 ++++++++++++++------------------
net/ethtool/linkmodes.c | 91 +++++++++++++++++-------------------
net/ethtool/mm.c | 82 ++++++++++++--------------------
net/ethtool/module.c | 89 ++++++++++++++---------------------
net/ethtool/netlink.c | 91 ++++++++++++++++++++++++++++++------
net/ethtool/netlink.h | 36 +++++++-------
net/ethtool/pause.c | 79 +++++++++++++------------------
net/ethtool/plca.c | 75 +++++++++--------------------
net/ethtool/privflags.c | 84 ++++++++++++++++-----------------
net/ethtool/pse-pd.c | 79 ++++++++++++-------------------
net/ethtool/rings.c | 101 +++++++++++++++++-----------------------
net/ethtool/wol.c | 79 +++++++++++++------------------
17 files changed, 608 insertions(+), 775 deletions(-)
--
2.39.1
next reply other threads:[~2023-01-25 23:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 23:05 Jakub Kicinski [this message]
2023-01-25 23:05 ` [PATCH net-next v2 1/2] ethtool: netlink: handle SET intro/outro in the common code Jakub Kicinski
2023-01-25 23:05 ` [PATCH net-next v2 2/2] ethtool: netlink: convert commands to common SET Jakub Kicinski
2023-01-27 12:40 ` [PATCH net-next v2 0/2] ethtool: netlink: handle SET intro/outro in the common code patchwork-bot+netdevbpf
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=20230125230519.1069676-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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;
as well as URLs for NNTP newsgroup(s).