linux-kernel - Re: [PATCH v2 1/1] pps: retrieve generator specific data from framework

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: <Z5nQeAFx3UlI9hxE@smile.fi.intel.com>
Date: Wed, 29 Jan 2025 08:53:44 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: subramanian.mohan@...el.com
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, greg@...ah.com, corbet@....net,
	christopher.s.hall@...el.com, tglx@...utronix.de,
	eddie.dong@...el.com, pandith.n@...el.com,
	thejesh.reddy.t.r@...el.com, david.zage@...el.com,
	srinivasan.chinnadurai@...el.com, rdunlap@...radead.org,
	bagasdotme@...il.com, giometti@...eenne.com
Subject: Re: [PATCH v2 1/1] pps: retrieve generator specific data from
 framework

On Tue, Jan 28, 2025 at 07:47:43PM +0530, subramanian.mohan@...el.com wrote:
> From: Subramanian Mohan <subramanian.mohan@...el.com>
> 
> While adapting pps generator driver(tio generator as an example)to the new
> generator framework, As part of driver registration the pps_gen_device
> pointer is returned from framework. Due to which there is difficulty in
> getting generator driver data back in enable function. we won’t be able
> to use container_of macro as it results in static assert. we might end up

container_of()

Can you be more specific, what exactly happens?

> in using static pointer. To avoid the same and get back the generator
> driver data back we are proposing generic approach to add drv_prv_data
> pointer inside the struct pps_gen_source_info.

> Example TIO structure wrapped with pps_gen_device and usage.
> 
> struct pps_tio {
> 	/* Framework Related * /
> 	struct pps_gen_source_info pps_tio_source_info
> 	struct pps_gen_device *pps_gen;

> };

> static int pps_tio_enable(struct pps_gen_device *pps_gen, bool enable) {
> 
>     /* Getting TIO data back */
>     /* Note: drv_prv_data will be initialized in our init routine */
>     struct pps_tio *tio = pps_gen->info.drv_prv_data;

So, what's wrong with the container_of() against pps_gen->info?
We have tons of code in the kernel that does it.

>     /* Access tio members here to set some of the parameters */
> 
>     return 0;
> }

Okay, looking into the implementation I see what's the issue (but it doesn't
mean that commit message is good here, you still need to explain better why
you can't get the correct address).

The problem is that info is got fully copied. Perhaps we should rely on
the fact that it always be provided? I dunno any data structure that defines
callbacks and other "info" material should be considered as temporary storage
(on stack), it makes not much sense.

...

> V1 -> V2:
>     * Updated reviewers.

Please, use...

> Signed-off-by: Subramanian Mohan <subramanian.mohan@...el.com>
> ---

...this place for the comments and changelogs.

...

> +	void *drv_prv_data;

If really needed we should probably use a better name, like "private".

-- 
With Best Regards,
Andy Shevchenko