netdev - Re: [patch net-next v4 5/9] genetlink: introduce per-sock family private pointer storage

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]

Message-ID: <ZWWj8VZF5Puww2gm@nanopsycho>
Date: Tue, 28 Nov 2023 09:25:21 +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 v4 5/9] genetlink: introduce per-sock family
 private pointer storage

Mon, Nov 27, 2023 at 11:46:26PM CET, kuba@...nel.org wrote:
>On Thu, 23 Nov 2023 19:15:42 +0100 Jiri Pirko wrote:
>> +	void __rcu		*priv;
>
>How many times did I say "typed struct" in the feedback to the broken
>v3 of this series? You complain so much about people not addressing
>feedback you've given them, it's really hypocritical.

I did what I thought is best. Since this is struct netlink_sock, it is
not related only to genetlink. So other implementations may in theory
use this pointer for something else. Looked a bit odd to put
genetlink-specific pointer here, but as you wish.

>
>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.

>
>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.

>should also hold a callback to how the data is going to be freed.

If it is alloceted automatically, why is it needed?

>-- 
>pw-bot: cr