From: Jakub Kicinski <kuba@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, pabeni@redhat.com, davem@davemloft.net,
edumazet@google.com, moshe@nvidia.com
Subject: Re: [patch net-next] devlink: introduce dump selector attr and implement it for port dumps
Date: Fri, 14 Jul 2023 08:40:21 -0700 [thread overview]
Message-ID: <20230714084021.51fea890@kernel.org> (raw)
In-Reply-To: <ZLEAsaKj+eKYlceM@nanopsycho>
On Fri, 14 Jul 2023 10:00:49 +0200 Jiri Pirko wrote:
> Fri, Jul 14, 2023 at 05:51:41AM CEST, kuba@kernel.org wrote:
> >On Thu, 13 Jul 2023 17:15:28 +0200 Jiri Pirko wrote:
> >> + /* If the user provided selector attribute with devlink handle, dump only
> >> + * objects that belong under this instance.
> >> + */
> >> + if (cmd->dump_selector_nla_policy &&
> >> + attrs[DEVLINK_ATTR_DUMP_SELECTOR]) {
> >> + struct nlattr *tb[DEVLINK_ATTR_MAX + 1];
> >> +
> >> + err = nla_parse_nested(tb, DEVLINK_ATTR_MAX,
> >> + attrs[DEVLINK_ATTR_DUMP_SELECTOR],
> >> + cmd->dump_selector_nla_policy,
> >> + cb->extack);
> >> + if (err)
> >> + return err;
> >> + if (tb[DEVLINK_ATTR_BUS_NAME] && tb[DEVLINK_ATTR_DEV_NAME]) {
> >> + devlink = devlink_get_from_attrs_lock(sock_net(msg->sk), tb);
> >> + if (IS_ERR(devlink))
> >> + return PTR_ERR(devlink);
> >> + err = cmd->dump_one(msg, devlink, cb);
> >> + devl_unlock(devlink);
> >> + devlink_put(devlink);
> >> + goto out;
> >> + }
> >
> >This implicitly depends on the fact that cmd->dump_one() will set and
> >pay attention to state->idx. If it doesn't kernel will infinitely dump
> >the same instance. I think we should explicitly check state->idx and
> >set it to 1 after calling ->dump_one.
>
> Nothing changes, only instead of iterating over multiple devlinks, we
> just work with one.
>
> So, the state->idx is in-devlink-instance index. That means, after
> iterating to next devlink instance it is reset to 0 below (state->idx = 0;).
> Here however, as we stay only within a single devlink instance,
> the reset is not needed.
>
> Am I missing something?
The case I was thinking of is if we support filtering of dumps which
do not have sub-objects. In that case state->idx does not get touched
by the dump_one.
Looking closer, tho, there's no case of this sort today, so my concern
is premature. Also what I suggested won't really work. So ignore this
comment, sorry :)
prev parent reply other threads:[~2023-07-14 15:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 15:15 [patch net-next] devlink: introduce dump selector attr and implement it for port dumps Jiri Pirko
2023-07-14 3:51 ` Jakub Kicinski
2023-07-14 8:00 ` Jiri Pirko
2023-07-14 15:40 ` Jakub Kicinski [this message]
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=20230714084021.51fea890@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jiri@resnulli.us \
--cc=moshe@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.