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, jacob.e.keller@intel.com, jhs@mojatatu.com,
johannes@sipsolutions.net, andriy.shevchenko@linux.intel.com,
amritha.nambiar@intel.com, sdf@google.com, horms@kernel.org
Subject: Re: [patch net-next v4 5/9] genetlink: introduce per-sock family private pointer storage
Date: Tue, 28 Nov 2023 07:11:16 -0800 [thread overview]
Message-ID: <20231128071116.1b6aed13@kernel.org> (raw)
In-Reply-To: <ZWWj8VZF5Puww2gm@nanopsycho>
On Tue, 28 Nov 2023 09:25:21 +0100 Jiri Pirko wrote:
> >Put the xarray pointer here directly. Plus a lock to protect the init.
>
> Okay, just to make this clear. You want me to have:
> struct xarray __rcu *family_privs;
>
> in struct netlink_sock, correct?
>
>
> Why I need a lock? If I read things correctly, skbs are processed in
> serial over one sock. Since this is per-sock, should be safe.
Okay, then add an assertion that the socket lock is held, at least.
Also, is the socket lock not held yet when the filtering happens?
Maybe the __rcu annotation isn't necessary then either?
> >The size of the per-family struct should be in family definition,
> >allocation should happen on first get automatically. Family definition
>
> Yes, I thought about that. But I decided to do this lockless, allocating
> new priv every time the user sets the filter and replace the xarray item
> so it could be accessed in rcu read section during notification
> processing.
>
> What you suggest requires some lock to protect the memory being changed
> during filter set and suring accessing in in notify. But okay,
> if you insist.
Not necessarily, you can have a helper which doesn't allocate, too.
What I'm saying is that the common case for ops will be to access
the state and allocate if it doesn't exist.
How about genl_sk_family_priv() and genl_sk_has_family_priv() ?
> >should also hold a callback to how the data is going to be freed.
>
> If it is alloceted automatically, why is it needed?
Because priv may be a complex type which has member that need
individual fields to be destroyed (in fullness of time we also
need a constructor which can init things like list_head, but
we can defer that).
I'm guessing in your case the priv will look like this:
struct devlink_sk_priv {
const char *nft_fltr_instance_name;
};
static void devlink_sk_priv_free(void *ptr)
{
struct devlink_sk_priv *priv = ptr;
kfree(priv->nft_fltr_instance_name);
}
next prev parent reply other threads:[~2023-11-28 15:11 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-23 18:15 [patch net-next v4 0/9] devlink: introduce notifications filtering Jiri Pirko
2023-11-23 18:15 ` [patch net-next v4 1/9] devlink: use devl_is_registered() helper instead xa_get_mark() Jiri Pirko
2023-11-23 18:15 ` [patch net-next v4 2/9] devlink: introduce __devl_is_registered() helper and use it instead of xa_get_mark() Jiri Pirko
2023-11-23 18:15 ` [patch net-next v4 3/9] devlink: send notifications only if there are listeners Jiri Pirko
2023-11-27 11:01 ` Paolo Abeni
2023-11-27 12:04 ` Jiri Pirko
2023-11-27 15:00 ` Paolo Abeni
2023-11-28 7:39 ` Jiri Pirko
2023-11-23 18:15 ` [patch net-next v4 4/9] devlink: introduce a helper for netlink multicast send Jiri Pirko
2023-11-23 18:15 ` [patch net-next v4 5/9] genetlink: introduce per-sock family private pointer storage Jiri Pirko
2023-11-27 11:13 ` Paolo Abeni
2023-11-27 12:00 ` Jiri Pirko
2023-11-27 22:46 ` Jakub Kicinski
2023-11-28 8:25 ` Jiri Pirko
2023-11-28 15:11 ` Jakub Kicinski [this message]
2023-11-28 16:05 ` Jiri Pirko
2023-11-28 16:36 ` Jakub Kicinski
2023-11-29 13:59 ` Jiri Pirko
2023-11-29 15:01 ` Jakub Kicinski
2023-11-29 15:25 ` Jiri Pirko
2023-11-28 12:30 ` Przemek Kitszel
2023-11-28 15:05 ` Jiri Pirko
2023-11-28 16:18 ` Andy Shevchenko
2023-11-28 19:59 ` Jacob Keller
2023-11-28 20:06 ` Andy Shevchenko
2023-11-29 23:29 ` Jacob Keller
2023-11-23 18:15 ` [patch net-next v4 6/9] netlink: introduce typedef for filter function Jiri Pirko
2023-11-23 18:15 ` [patch net-next v4 7/9] genetlink: introduce helpers to do filtered multicast Jiri Pirko
2023-11-23 18:15 ` [patch net-next v4 8/9] devlink: add a command to set notification filter and use it for multicasts Jiri Pirko
2023-11-27 12:30 ` Przemek Kitszel
2023-11-27 12:51 ` Jiri Pirko
2023-11-27 12:56 ` Jiri Pirko
2023-11-27 15:40 ` Przemek Kitszel
2023-11-28 8:26 ` Jiri Pirko
2023-12-04 16:24 ` Jiri Pirko
2023-12-04 16:47 ` Andy Shevchenko
2023-12-04 19:17 ` Keller, Jacob E
2023-12-05 7:47 ` Jiri Pirko
2023-12-05 15:58 ` andriy.shevchenko
2023-11-23 18:15 ` [patch net-next v4 9/9] devlink: extend multicast filtering by port index Jiri Pirko
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=20231128071116.1b6aed13@kernel.org \
--to=kuba@kernel.org \
--cc=amritha.nambiar@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=johannes@sipsolutions.net \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.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.