All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 3/5] netlink: rework policy dump to support multiple policies
Date: Fri, 02 Oct 2020 22:11:14 +0200	[thread overview]
Message-ID: <7312dbde2b0bada0700afa6af417d065e45fb053.camel@sipsolutions.net> (raw)
In-Reply-To: <20201002083926.603adbcb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Fri, 2020-10-02 at 08:39 -0700, Jakub Kicinski wrote:
> 
> > -	ctx->state = netlink_policy_dump_start(op.policy, op.maxattr);
> > -	if (IS_ERR(ctx->state))
> > -		return PTR_ERR(ctx->state);
> > -	return 0;
> > +	return netlink_policy_dump_add_policy(&ctx->state, op.policy,
> > +					      op.maxattr);
> 
> Looks like we flip-flopped between int and pointer return between
> patches 1 and this one?

Huh, yeah, that was kinda dumb. I started going down one path and then
...

I'll probably just squash the first patch or something. Will figure
something out, thanks.

> >  }
> > +int netlink_policy_dump_get_policy_idx(struct netlink_policy_dump_state *state,
> > +				       const struct nla_policy *policy,
> > +				       unsigned int maxtype)
> > +{
> > +	unsigned int i;
> > +
> > +	if (WARN_ON(!policy || !maxtype))
> > +                return 0;
> 
> Would this warning make sense in add() (if not already there)?
> If null/0 is never added it can't match and we'd just hit the
> warning below.

It's not there, because had originally thought it should be OK to just
blindly add a policy of a family even if it has none. But that makes no
sense.

However, it's not true that it can't match, because

> > +	for (i = 0; i < state->n_alloc; i++) {

we go to n_alloc here, and don't separately track n_used, but n_alloc
grows in tens (or so), not singles.

johannes



  reply	other threads:[~2020-10-02 20:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02  9:09 [PATCH 0/5] genetlink: complete policy dumping Johannes Berg
2020-10-02  9:09 ` [PATCH 1/5] netlink: simplify netlink_policy_dump_start() prototype Johannes Berg
2020-10-02 15:31   ` Jakub Kicinski
2020-10-02 20:02     ` Johannes Berg
2020-10-02  9:09 ` [PATCH 2/5] netlink: compare policy more accurately Johannes Berg
2020-10-02 15:39   ` Jakub Kicinski
2020-10-02  9:09 ` [PATCH 3/5] netlink: rework policy dump to support multiple policies Johannes Berg
2020-10-02 15:39   ` Jakub Kicinski
2020-10-02 20:11     ` Johannes Berg [this message]
2020-10-02 20:13     ` Johannes Berg
2020-10-02 20:37       ` Jakub Kicinski
2020-10-02 20:38         ` Johannes Berg
2020-10-02 20:42           ` Jakub Kicinski
2020-10-02  9:09 ` [PATCH 4/5] genetlink: factor skb preparation out of ctrl_dumppolicy() Johannes Berg
2020-10-02 15:42   ` Jakub Kicinski
2020-10-02  9:09 ` [PATCH 5/5] genetlink: properly support per-op policy dumping Johannes Berg

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=7312dbde2b0bada0700afa6af417d065e45fb053.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /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.