[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZWdX5ccvLxuUh0Eb@nanopsycho>
Date: Wed, 29 Nov 2023 16:25:25 +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
Wed, Nov 29, 2023 at 04:01:57PM CET, kuba@...nel.org wrote:
>On Wed, 29 Nov 2023 14:59:31 +0100 Jiri Pirko wrote:
>> Tue, Nov 28, 2023 at 05:36:05PM CET, kuba@...nel.org wrote:
>> >No, you can do exact same thing, just instead of putting the string
>> >directly into the xarray you put a struct which points to the string.
>>
>> I'm lost. What "string" are you talking about exactly? I'm not putting
>> any string to xarray.
>>
>> In the existing implementation, I have following struct:
>> struct devlink_obj_desc {
>> struct rcu_head rcu;
>> const char *bus_name;
>> const char *dev_name;
>> unsigned int port_index;
>> bool port_index_valid;
>> long data[];
>> };
>>
>> This is the struct put pointer to into the xarray. Pointer to this
>> struct is dereferenced under rcu in notification code and the struct
>> is freed by kfree_rcu().
>
>Sorry I was looking at patch 8 which has only:
>
>+struct devlink_obj_desc {
>+ struct rcu_head rcu;
>+ const char *bus_name;
>+ const char *dev_name;
>+ long data[];
>+};
>
>that's basically a string and an rcu_head, that's what I meant.
>
>> >Core still does the kfree of the container (struct devlink_sk_priv).
>> >But what's inside the container struct (string pointer) has to be
>> >handled by the destructor.
>> >
>> >Feels like you focus on how to prove me wrong more than on
>> >understanding what I'm saying :|
>>
>> Not at all, I have no reason for it. I just want to get my job done
>> and I am having very hard time to understand what you want exactly.
>
>Sockets may want to hold state for more than filtering.
>Try to look past your singular use case.
Okay, I'll try to make another V. But please don't be mad I
misunderstood something if I do :)
Powered by blists - more mailing lists