lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ