* [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section
[not found] <20211218130014.4037640-1-daniel.lezcano@linaro.org>
@ 2021-12-18 13:00 ` Daniel Lezcano
2021-12-31 13:33 ` Ulf Hansson
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Lezcano @ 2021-12-18 13:00 UTC (permalink / raw)
To: daniel.lezcano, rjw
Cc: lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm,
ulf.hansson, Arnd Bergmann,
open list:GENERIC INCLUDE/ASM HEADER FILES
The dtpm table is used to let the different dtpm backends to register
their setup callbacks in a single place and preventing to export
multiple functions all around the kernel. That allows the dtpm code to
be self-encapsulated.
The dtpm hierarchy will be passed as a parameter by a platform
specific code and that will lead to the creation of the different dtpm
nodes.
The function creating the hierarchy could be called from a module at
init time or when it is loaded. However, at this moment the table is
already freed as it belongs to the init section and the creation will
lead to a invalid memory access.
Fix this by moving the table to the data section.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
include/asm-generic/vmlinux.lds.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 42f3866bca69..50d494d94d6c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -362,7 +362,8 @@
BRANCH_PROFILE() \
TRACE_PRINTKS() \
BPF_RAW_TP() \
- TRACEPOINT_STR()
+ TRACEPOINT_STR() \
+ DTPM_TABLE()
/*
* Data section helpers
@@ -723,7 +724,6 @@
ACPI_PROBE_TABLE(irqchip) \
ACPI_PROBE_TABLE(timer) \
THERMAL_TABLE(governor) \
- DTPM_TABLE() \
EARLYCON_TABLE() \
LSM_TABLE() \
EARLY_LSM_TABLE() \
--
2.25.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section
2021-12-18 13:00 ` [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section Daniel Lezcano
@ 2021-12-31 13:33 ` Ulf Hansson
2022-01-04 8:57 ` Daniel Lezcano
2022-01-07 13:15 ` Daniel Lezcano
0 siblings, 2 replies; 6+ messages in thread
From: Ulf Hansson @ 2021-12-31 13:33 UTC (permalink / raw)
To: Daniel Lezcano
Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm,
Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES
On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
> The dtpm table is used to let the different dtpm backends to register
> their setup callbacks in a single place and preventing to export
> multiple functions all around the kernel. That allows the dtpm code to
> be self-encapsulated.
Well, that's not entirely true. The dtpm code and its backends (or
ops, whatever we call them) are already maintained from a single
place, the /drivers/powercap/* directory. I assume we intend to keep
it like this going forward too, right?
That is also what patch4 with the devfreq backend continues to conform to.
>
> The dtpm hierarchy will be passed as a parameter by a platform
> specific code and that will lead to the creation of the different dtpm
> nodes.
>
> The function creating the hierarchy could be called from a module at
> init time or when it is loaded. However, at this moment the table is
> already freed as it belongs to the init section and the creation will
> lead to a invalid memory access.
>
> Fix this by moving the table to the data section.
With the above said, I find it a bit odd to put a table in the data
section like this. Especially, since the only remaining argument for
why, is to avoid exporting functions, which isn't needed anyway.
I mean, it would be silly if we should continue to put subsystem
specific tables in here, to just let them contain a set of subsystem
specific callbacks.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Kind regards
Uffe
> ---
> include/asm-generic/vmlinux.lds.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 42f3866bca69..50d494d94d6c 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -362,7 +362,8 @@
> BRANCH_PROFILE() \
> TRACE_PRINTKS() \
> BPF_RAW_TP() \
> - TRACEPOINT_STR()
> + TRACEPOINT_STR() \
> + DTPM_TABLE()
>
> /*
> * Data section helpers
> @@ -723,7 +724,6 @@
> ACPI_PROBE_TABLE(irqchip) \
> ACPI_PROBE_TABLE(timer) \
> THERMAL_TABLE(governor) \
> - DTPM_TABLE() \
> EARLYCON_TABLE() \
> LSM_TABLE() \
> EARLY_LSM_TABLE() \
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section
2021-12-31 13:33 ` Ulf Hansson
@ 2022-01-04 8:57 ` Daniel Lezcano
2022-01-07 13:15 ` Daniel Lezcano
1 sibling, 0 replies; 6+ messages in thread
From: Daniel Lezcano @ 2022-01-04 8:57 UTC (permalink / raw)
To: Ulf Hansson
Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm,
Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES
Hi Ulf,
thanks for your comments
On 31/12/2021 14:33, Ulf Hansson wrote:
> On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>
>> The dtpm table is used to let the different dtpm backends to register
>> their setup callbacks in a single place and preventing to export
>> multiple functions all around the kernel. That allows the dtpm code to
>> be self-encapsulated.
>
> Well, that's not entirely true. The dtpm code and its backends (or
> ops, whatever we call them) are already maintained from a single
> place, the /drivers/powercap/* directory. I assume we intend to keep
> it like this going forward too, right?
Hopefully we can add more devices like the battery or the backlight, but
I'm not sure they will be in drivers/powercap.
> That is also what patch4 with the devfreq backend continues to conform to.
>
>>
>> The dtpm hierarchy will be passed as a parameter by a platform
>> specific code and that will lead to the creation of the different dtpm
>> nodes.
>>
>> The function creating the hierarchy could be called from a module at
>> init time or when it is loaded. However, at this moment the table is
>> already freed as it belongs to the init section and the creation will
>> lead to a invalid memory access.
>>
>> Fix this by moving the table to the data section.
>
> With the above said, I find it a bit odd to put a table in the data
> section like this. Especially, since the only remaining argument for
> why, is to avoid exporting functions, which isn't needed anyway.
>
> I mean, it would be silly if we should continue to put subsystem
> specific tables in here, to just let them contain a set of subsystem
> specific callbacks.
Do you have an alternative without introducing cyclic dependencies ?
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> Kind regards
> Uffe
>
>> ---
>> include/asm-generic/vmlinux.lds.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> index 42f3866bca69..50d494d94d6c 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -362,7 +362,8 @@
>> BRANCH_PROFILE() \
>> TRACE_PRINTKS() \
>> BPF_RAW_TP() \
>> - TRACEPOINT_STR()
>> + TRACEPOINT_STR() \
>> + DTPM_TABLE()
>>
>> /*
>> * Data section helpers
>> @@ -723,7 +724,6 @@
>> ACPI_PROBE_TABLE(irqchip) \
>> ACPI_PROBE_TABLE(timer) \
>> THERMAL_TABLE(governor) \
>> - DTPM_TABLE() \
>> EARLYCON_TABLE() \
>> LSM_TABLE() \
>> EARLY_LSM_TABLE() \
>> --
>> 2.25.1
>>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section
2021-12-31 13:33 ` Ulf Hansson
2022-01-04 8:57 ` Daniel Lezcano
@ 2022-01-07 13:15 ` Daniel Lezcano
2022-01-07 14:49 ` Ulf Hansson
1 sibling, 1 reply; 6+ messages in thread
From: Daniel Lezcano @ 2022-01-07 13:15 UTC (permalink / raw)
To: Ulf Hansson
Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm,
Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES
On 31/12/2021 14:33, Ulf Hansson wrote:
> On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>
>> The dtpm table is used to let the different dtpm backends to register
>> their setup callbacks in a single place and preventing to export
>> multiple functions all around the kernel. That allows the dtpm code to
>> be self-encapsulated.
>
> Well, that's not entirely true. The dtpm code and its backends (or
> ops, whatever we call them) are already maintained from a single
> place, the /drivers/powercap/* directory. I assume we intend to keep
> it like this going forward too, right?
>
> That is also what patch4 with the devfreq backend continues to conform to.
>
>>
>> The dtpm hierarchy will be passed as a parameter by a platform
>> specific code and that will lead to the creation of the different dtpm
>> nodes.
>>
>> The function creating the hierarchy could be called from a module at
>> init time or when it is loaded. However, at this moment the table is
>> already freed as it belongs to the init section and the creation will
>> lead to a invalid memory access.
>>
>> Fix this by moving the table to the data section.
>
> With the above said, I find it a bit odd to put a table in the data
> section like this. Especially, since the only remaining argument for
> why, is to avoid exporting functions, which isn't needed anyway.
>
> I mean, it would be silly if we should continue to put subsystem
> specific tables in here, to just let them contain a set of subsystem
> specific callbacks.
So I tried to change the approach and right now I was not able to find
an alternative keeping the code self-encapsulate and without introducing
cyclic dependencies.
I suggest to keep the patch as it is and double check if it makes sense
to change it after adding more dtpm backends
Alternatively I can copy the table to a dynamically allocated table.
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> Kind regards
> Uffe
>
>> ---
>> include/asm-generic/vmlinux.lds.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> index 42f3866bca69..50d494d94d6c 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -362,7 +362,8 @@
>> BRANCH_PROFILE() \
>> TRACE_PRINTKS() \
>> BPF_RAW_TP() \
>> - TRACEPOINT_STR()
>> + TRACEPOINT_STR() \
>> + DTPM_TABLE()
>>
>> /*
>> * Data section helpers
>> @@ -723,7 +724,6 @@
>> ACPI_PROBE_TABLE(irqchip) \
>> ACPI_PROBE_TABLE(timer) \
>> THERMAL_TABLE(governor) \
>> - DTPM_TABLE() \
>> EARLYCON_TABLE() \
>> LSM_TABLE() \
>> EARLY_LSM_TABLE() \
>> --
>> 2.25.1
>>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section
2022-01-07 13:15 ` Daniel Lezcano
@ 2022-01-07 14:49 ` Ulf Hansson
2022-01-10 13:33 ` Daniel Lezcano
0 siblings, 1 reply; 6+ messages in thread
From: Ulf Hansson @ 2022-01-07 14:49 UTC (permalink / raw)
To: Daniel Lezcano
Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm,
Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES
On Fri, 7 Jan 2022 at 14:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
> On 31/12/2021 14:33, Ulf Hansson wrote:
> > On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> >>
> >> The dtpm table is used to let the different dtpm backends to register
> >> their setup callbacks in a single place and preventing to export
> >> multiple functions all around the kernel. That allows the dtpm code to
> >> be self-encapsulated.
> >
> > Well, that's not entirely true. The dtpm code and its backends (or
> > ops, whatever we call them) are already maintained from a single
> > place, the /drivers/powercap/* directory. I assume we intend to keep
> > it like this going forward too, right?
> >
> > That is also what patch4 with the devfreq backend continues to conform to.
> >
> >>
> >> The dtpm hierarchy will be passed as a parameter by a platform
> >> specific code and that will lead to the creation of the different dtpm
> >> nodes.
> >>
> >> The function creating the hierarchy could be called from a module at
> >> init time or when it is loaded. However, at this moment the table is
> >> already freed as it belongs to the init section and the creation will
> >> lead to a invalid memory access.
> >>
> >> Fix this by moving the table to the data section.
> >
> > With the above said, I find it a bit odd to put a table in the data
> > section like this. Especially, since the only remaining argument for
> > why, is to avoid exporting functions, which isn't needed anyway.
> >
> > I mean, it would be silly if we should continue to put subsystem
> > specific tables in here, to just let them contain a set of subsystem
> > specific callbacks.
>
> So I tried to change the approach and right now I was not able to find
> an alternative keeping the code self-encapsulate and without introducing
> cyclic dependencies.
>
> I suggest to keep the patch as it is and double check if it makes sense
> to change it after adding more dtpm backends
>
> Alternatively I can copy the table to a dynamically allocated table.
I am not sure I understand the problem. You don't need a "table of
callbacks" at all, at least to start with.
Instead, what you need is to make a call to a function, or actually
one call per supported dtpm type from dtpm_setup_dt() (introduced in
patch2).
For CPUs, you would simply call dtpm_cpu_setup() (introduced in
patch3) from dtpm_setup_dt(), rather than walking the dtpm table an
invoking the ->setup() callback.
Did that make sense to you?
Going forward, when we decide to introduce the option to add/remove
support for dtpm types dynamically, you can then convert to a
dynamically allocated table.
[...]
Kind regards
Uffe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section
2022-01-07 14:49 ` Ulf Hansson
@ 2022-01-10 13:33 ` Daniel Lezcano
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Lezcano @ 2022-01-10 13:33 UTC (permalink / raw)
To: Ulf Hansson
Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm,
Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES
On 07/01/2022 15:49, Ulf Hansson wrote:
> On Fri, 7 Jan 2022 at 14:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>
>> On 31/12/2021 14:33, Ulf Hansson wrote:
>>> On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>>>
>>>> The dtpm table is used to let the different dtpm backends to register
>>>> their setup callbacks in a single place and preventing to export
>>>> multiple functions all around the kernel. That allows the dtpm code to
>>>> be self-encapsulated.
>>>
>>> Well, that's not entirely true. The dtpm code and its backends (or
>>> ops, whatever we call them) are already maintained from a single
>>> place, the /drivers/powercap/* directory. I assume we intend to keep
>>> it like this going forward too, right?
>>>
>>> That is also what patch4 with the devfreq backend continues to conform to.
>>>
>>>>
>>>> The dtpm hierarchy will be passed as a parameter by a platform
>>>> specific code and that will lead to the creation of the different dtpm
>>>> nodes.
>>>>
>>>> The function creating the hierarchy could be called from a module at
>>>> init time or when it is loaded. However, at this moment the table is
>>>> already freed as it belongs to the init section and the creation will
>>>> lead to a invalid memory access.
>>>>
>>>> Fix this by moving the table to the data section.
>>>
>>> With the above said, I find it a bit odd to put a table in the data
>>> section like this. Especially, since the only remaining argument for
>>> why, is to avoid exporting functions, which isn't needed anyway.
>>>
>>> I mean, it would be silly if we should continue to put subsystem
>>> specific tables in here, to just let them contain a set of subsystem
>>> specific callbacks.
>>
>> So I tried to change the approach and right now I was not able to find
>> an alternative keeping the code self-encapsulate and without introducing
>> cyclic dependencies.
>>
>> I suggest to keep the patch as it is and double check if it makes sense
>> to change it after adding more dtpm backends
>>
>> Alternatively I can copy the table to a dynamically allocated table.
>
> I am not sure I understand the problem. You don't need a "table of
> callbacks" at all, at least to start with.
>
> Instead, what you need is to make a call to a function, or actually
> one call per supported dtpm type from dtpm_setup_dt() (introduced in
> patch2).
>
> For CPUs, you would simply call dtpm_cpu_setup() (introduced in
> patch3) from dtpm_setup_dt(), rather than walking the dtpm table an
> invoking the ->setup() callback.
>
> Did that make sense to you?
Yeah, I already got the point ;)
I'll convert it to something else, and we will see in the future if that
needs to be converted back to the table.
> Going forward, when we decide to introduce the option to add/remove
> support for dtpm types dynamically, you can then convert to a
> dynamically allocated table.
>
> [...]
>
> Kind regards
> Uffe
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-10 13:33 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20211218130014.4037640-1-daniel.lezcano@linaro.org>
2021-12-18 13:00 ` [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section Daniel Lezcano
2021-12-31 13:33 ` Ulf Hansson
2022-01-04 8:57 ` Daniel Lezcano
2022-01-07 13:15 ` Daniel Lezcano
2022-01-07 14:49 ` Ulf Hansson
2022-01-10 13:33 ` Daniel Lezcano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).