[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZV3KCF7Q2fwZyzg4@nanopsycho>
Date: Wed, 22 Nov 2023 10:29:44 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net,
edumazet@...gle.com, jacob.e.keller@...el.com, jhs@...atatu.com,
johannes@...solutions.net, andriy.shevchenko@...ux.intel.com,
amritha.nambiar@...el.com, sdf@...gle.com, horms@...nel.org
Subject: Re: [patch net-next v3 5/9] genetlink: implement release callback
and free sk_user_data there
Tue, Nov 21, 2023 at 06:55:12PM CET, kuba@...nel.org wrote:
>On Tue, 21 Nov 2023 14:12:55 +0100 Jiri Pirko wrote:
>> >How is this supposed to work?
>> >
>> >genetlink sockets are not bound to a family. User can use a single
>> >socket to subscribe to notifications from all families and presumably
>> >each one of the would interpret sk->sk_user_data as their own state?
>> >
>> >You need to store the state locally in the family, keyed
>> >on pid, and free it using the NETLINK_URELEASE notifier...
>>
>> Well, pin can have 2 sockets of different config. I think that sk/family
>> tuple is needed. I'm exploring a possibility to have genetlink
>> sk->sk_user_data used to store the hashlist keyed by the sk/family tuple.
>
>If you're doing it centrally, please put the state as a new field in
>the netlink socket. sk_user_data is for the user.
I planned to use sk_user_data. What do you mean it is for the user?
I see it is already used for similar usecase by connector for example:
$ git grep sk_user_data drivers/connector/
drivers/connector/cn_proc.c: if (!dsk || !dsk->sk_user_data || !data)
drivers/connector/cn_proc.c: val = ((struct proc_input *)(dsk->sk_user_data))->event_type;
drivers/connector/cn_proc.c: mc_op = ((struct proc_input *)(dsk->sk_user_data))->mcast_op;
drivers/connector/cn_proc.c: if (sk->sk_user_data == NULL) {
drivers/connector/cn_proc.c: sk->sk_user_data = kzalloc(sizeof(struct proc_input),
drivers/connector/cn_proc.c: if (sk->sk_user_data == NULL) {
drivers/connector/cn_proc.c: ((struct proc_input *)(sk->sk_user_data))->mcast_op;
drivers/connector/cn_proc.c: ((struct proc_input *)(sk->sk_user_data))->event_type =
drivers/connector/cn_proc.c: ((struct proc_input *)(sk->sk_user_data))->mcast_op = mc_op;
drivers/connector/cn_proc.c: ((struct proc_input *)(sk->sk_user_data))->event_type =
drivers/connector/connector.c: kfree(sk->sk_user_data);
drivers/connector/connector.c: sk->sk_user_data = NULL;
>
>Also let's start with a list, practically speaking using one socket
>in many families should be very rare.
Okay.
Powered by blists - more mailing lists