b.a.t.m.a.n.lists.open-mesh.org archive mirror
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [RFC v3 01/19] batman-adv: Move common genl doit code pre/post hooks
Date: Sun, 30 Dec 2018 17:57:54 +0100	[thread overview]
Message-ID: <20181230165754.GC4150@otheros> (raw)
In-Reply-To: <20181207135846.6152-2-sven@narfation.org>

On Fri, Dec 07, 2018 at 02:58:28PM +0100, Sven Eckelmann wrote:
> +/**
> + * batadv_get_softif_from_info() - Retrieve soft interface from genl attributes
> + * @net: the applicable net namespace
> + * @info: receiver information
> + *
> + * Return: Pointer to soft interface on success, error pointer on error
> + */
> +static struct batadv_priv *
> +batadv_get_softif_from_info(struct net *net, struct genl_info *info)

Since this returns a batadv_priv, shouldn't it better be called
batadv_get_batpriv_from_info() or batadv_get_bat_priv_from_info() maybe?

> +{
> +	struct net_device *soft_iface;
> +	int ifindex;
> +
> +	if (!info->attrs[BATADV_ATTR_MESH_IFINDEX])
> +		return ERR_PTR(-EINVAL);
> +
> +	ifindex = nla_get_u32(info->attrs[BATADV_ATTR_MESH_IFINDEX]);
> +
> +	soft_iface = dev_get_by_index(net, ifindex);
> +	if (!soft_iface)
> +		return ERR_PTR(-ENODEV);
> +
> +	if (!batadv_softif_is_valid(soft_iface))
> +		goto err_put_softif;
> +
> +	return netdev_priv(soft_iface);
> +
> +err_put_softif:
> +	dev_put(soft_iface);
> +
> +	return ERR_PTR(-EINVAL);
> +}

Is holding a reference to bat_priv->soft_iface really
necessary (and releasing it in batadv_post_doit() )?
If we are able to retrieve a valid bat_priv then this bat_priv
itself should hold a reference to to soft_iface, shouldn't it?

> +
> +/**
> + * batadv_pre_doit() - Prepare batman-adv genl doit request
> + * @ops: requested netlink operation
> + * @skb: Netlink message with request data
> + * @info: receiver information
> + *
> + * Return: 0 on success or negative error number in case of failure
> + */
> +static int batadv_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
> +			   struct genl_info *info)
> +{
> +	struct batadv_priv *bat_priv;
> +
> +	if (ops->internal_flags & BATADV_FLAG_NEED_MESH) {
> +		bat_priv = batadv_get_softif_from_info(genl_info_net(info),
> +						       info);

Would it look nicer to store genl_info_net(info) in a temporary variable
so that its shorter and the newline for the second parameter could
be avoided?

> +		if (IS_ERR(bat_priv))
> +			return PTR_ERR(bat_priv);
> +
> +		info->user_ptr[0] = bat_priv;

Would it make sense to wrap this private data access into
something somehow? Conceptually similar to what we do not with skb private
data already for instance. There we use BATADV_SKB_CB() for instance.

> +	}
> +
> +	return 0;
> +}

  reply	other threads:[~2018-12-30 16:57 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07 13:58 [B.A.T.M.A.N.] [RFC v3 00/19] batman-adv: netlink restructuring, part 2 Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 01/19] batman-adv: Move common genl doit code pre/post hooks Sven Eckelmann
2018-12-30 16:57   ` Linus Lüssing [this message]
2018-12-31 19:08     ` Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 02/19] batman-adv: Prepare framework for mesh genl config Sven Eckelmann
2018-12-31 11:09   ` Linus Lüssing
2018-12-31 19:11     ` Sven Eckelmann
2019-01-07 18:49   ` Linus Lüssing
2019-01-08  7:54     ` Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 03/19] batman-adv: Prepare framework for hardif " Sven Eckelmann
2018-12-31 11:59   ` Linus Lüssing
2018-12-31 19:17     ` Sven Eckelmann
2019-01-04  0:39   ` Linus Lüssing
2019-01-04  7:52     ` Sven Eckelmann
2019-01-05 15:12       ` Linus Lüssing
2019-01-05 17:22         ` Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 04/19] batman-adv: Prepare framework for vlan " Sven Eckelmann
2019-01-04  1:53   ` Linus Lüssing
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 05/19] batman-adv: Add aggregated_ogms mesh genl configuration Sven Eckelmann
2019-01-04  1:40   ` Linus Lüssing
2019-01-04  7:59     ` Sven Eckelmann
2019-01-04  2:06   ` Linus Lüssing
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 06/19] batman-adv: Add ap_isolation mesh/vlan " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 07/19] batman-adv: Add bonding mesh " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 08/19] batman-adv: Add bridge_loop_avoidance " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 09/19] batman-adv: Add distributed_arp_table " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 10/19] batman-adv: Add fragmentation " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 11/19] batman-adv: Add gateway " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 12/19] batman-adv: Add hop_penalty " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 13/19] batman-adv: Add log_level " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 14/19] batman-adv: Add multicast_mode " Sven Eckelmann
2019-01-04  1:57   ` Linus Lüssing
2019-01-04  7:44     ` Sven Eckelmann
2019-01-04  8:51       ` Jiri Pirko
2019-01-05 15:02         ` Linus Lüssing
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 15/19] batman-adv: Add network_coding " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 16/19] batman-adv: Add orig_interval " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 17/19] batman-adv: Add elp_interval hardif " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 18/19] batman-adv: Add throughput_override " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 19/19] batman-adv: Trigger genl notification on sysfs config change Sven Eckelmann
2019-01-04  2:29   ` Linus Lüssing
2019-01-04  7:58     ` Sven Eckelmann
2019-01-05 15:03       ` Linus Lüssing

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=20181230165754.GC4150@otheros \
    --to=linus.luessing@c0d3.blue \
    --cc=b.a.t.m.a.n@lists.open-mesh.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 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).