在 2024/10/2 20:15, Daniel Borkmann 写道:
On 9/30/24 3:33 AM, Yaxiong Tian wrote:
From: Yaxiong Tian
To save some running memory,Add __init and __exit to the
module load/unload functions.
Signed-off-by: Yaxiong Tian
---
tools/testing/selftests/bpf/bpf_test_no_cfi/bpf_test_no_cfi.c | 4
On 9/30/24 3:33 AM, Yaxiong Tian wrote:
From: Yaxiong Tian
To save some running memory,Add __init and __exit to the
module load/unload functions.
Signed-off-by: Yaxiong Tian
---
tools/testing/selftests/bpf/bpf_test_no_cfi/bpf_test_no_cfi.c | 4 ++--
1 file changed, 2 insertions(+), 2
From: Yaxiong Tian
To save some running memory,Add __init and __exit to the
module load/unload functions.
Signed-off-by: Yaxiong Tian
---
tools/testing/selftests/bpf/bpf_test_no_cfi/bpf_test_no_cfi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing
On Wed, 28 Feb 2024 at 16:47, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Calling an __exit function from an __init function is not allowed
> and will result in undefined behavior when the code is built-in:
>
> WARNING: modpost: vmlinux: section mismatch in reference
From: Arnd Bergmann
Calling an __exit function from an __init function is not allowed
and will result in undefined behavior when the code is built-in:
WARNING: modpost: vmlinux: section mismatch in reference: virtio_fs_init+0x50
(section: .init.text) -> virtio_fs_sysfs_exit (sect
On Thu, Mar 18, 2021 at 12:31:56PM +0100, Peter Zijlstra wrote:
> Hi,
>
> After more poking a new set of patches to fix static_call() vs __exit
> functions. These patches replace the patch I posted yesterday:
>
> https://lkml.kernel.org/r/yfh6br61b5gk8...@hirez.program
On Thu, 18 Mar 2021 at 17:10, Peter Zijlstra wrote:
>
> Hi,
>
> After more poking a new set of patches to fix static_call() vs __exit
> functions. These patches replace the patch I posted yesterday:
>
> https://lkml.kernel.org/r/yfh6br61b5gk8...@hirez.programming.kicks-a
Hi,
After more poking a new set of patches to fix static_call() vs __exit
functions. These patches replace the patch I posted yesterday:
https://lkml.kernel.org/r/yfh6br61b5gk8...@hirez.programming.kicks-ass.net
Since I've reproduced the problem locally, and these patches do seem to
From: Arnd Bergmann
[ Upstream commit 45fe7befe0db5e61cd3c846315f0ac48541e8445 ]
Functions that are annotated __exit are discarded for built-in drivers,
but the .remove callback in a device driver must still be kept around
to allow bind/unbind operations.
There is now a linker warning for the
From: Arnd Bergmann
Functions that are annotated __exit are discarded for built-in drivers,
but the .remove callback in a device driver must still be kept around
to allow bind/unbind operations.
There is now a linker warning for the discarded symbol references:
`tmc_remove' referenc
On Fri, Dec 04, 2020 at 12:11:40AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Functions that are annotated __exit are discarded for built-in drivers,
> but the .remove callback in a device driver must still be kept around
> to allow bind/unbind operations.
>
>
Quoting Arnd Bergmann (2020-12-03 15:11:40)
> From: Arnd Bergmann
>
> Functions that are annotated __exit are discarded for built-in drivers,
> but the .remove callback in a device driver must still be kept around
> to allow bind/unbind operations.
>
> There is now a l
From: Arnd Bergmann
Functions that are annotated __exit are discarded for built-in drivers,
but the .remove callback in a device driver must still be kept around
to allow bind/unbind operations.
There is now a linker warning for the discarded symbol references:
`tmc_remove' referenc
From: Andrew Murray
[ Upstream commit 8f35eaa5f2de020073a48ad51112237c5932cfcc ]
On architectures that discard .exit.* sections at runtime, a
warning is printed for each jump label that is used within an
in-kernel __exit annotated function:
can't patch jump_label at ehci_hcd_cleanup+0x8
__exit removed from machine_unsetup is because
kvm_arch_hardware_unsetup() is called by kvm_init() which is in the
__init section. It's not allowed to call a function located in the
__exit section and dropped during the kernel link from the __init
section or the kernel will crash if that ca
From: Andrew Murray
[ Upstream commit 8f35eaa5f2de020073a48ad51112237c5932cfcc ]
On architectures that discard .exit.* sections at runtime, a
warning is printed for each jump label that is used within an
in-kernel __exit annotated function:
can't patch jump_label at ehci_hcd_cleanup+0x8
all the init/cleanup_module
aliases in the kernel (defined by the module_init/exit macros),
ending up being very noisy.
These aliases point to the __init/__exit functions of a module,
which are defined as __cold (among other attributes). However,
the aliases themselves do not have the __cold
, it triggers for all the init/cleanup_module
aliases in the kernel (defined by the module_init/exit macros),
ending up being very noisy.
These aliases point to the __init/__exit functions of a module,
which are defined as __cold (among other attributes). However,
the aliases themselves do not have
)
{
struct jz4740_pwm_chip *jz4740;
@@ -169,7 +169,7 @@ static int jz4740_pwm_probe(struct
platform_device *pdev)
return pwmchip_add(&jz4740->chip);
}
-static int jz4740_pwm_remove(struct platform_device *pdev)
+static int __exit jz4740_pwm_remove(struct platform_devic
, it triggers for all the init/cleanup_module
aliases in the kernel (defined by the module_init/exit macros),
ending up being very noisy.
These aliases point to the __init/__exit functions of a module,
which are defined as __cold (among other attributes). However,
the aliases themselves do not have
tic int jz4740_pwm_remove(struct platform_device *pdev)
+static int __exit jz4740_pwm_remove(struct platform_device *pdev)
{
struct jz4740_pwm_chip *jz4740 = platform_get_drvdata(pdev);
--
2.21.0.593.g511ec345e18
, it triggers for all the init/cleanup_module
aliases in the kernel (defined by the module_init/exit macros),
ending up being very noisy.
These aliases point to the __init/__exit functions of a module,
which are defined as __cold (among other attributes). However,
the aliases themselves do not have
/cleanup_module
aliases in the kernel (defined by the module_init/exit macros),
ending up being very noisy.
These aliases point to the __init/__exit functions of a module,
which are defined as __cold (among other attributes). However,
the aliases themselves do not have the __cold attribute.
Since the
the module_init/exit macros),
ending up being very noisy.
These aliases point to the __init/__exit functions of a module,
which are defined as __cold (among other attributes). However,
the aliases themselves do not have the __cold attribute.
Since the compiler behaves differently when compiling a
kernel for each line
and a part of that embed in __exit text. So we need to keep the
EXIT_TEXT and EXIT_DATA if CONFIG_GCOV_KERNEL=y.
Link: https://lkml.org/lkml/2018/9/1/125
Signed-off-by: Greentime Hu
Reviewed-by: Masami Hiramatsu
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
The patch
spi: sprd: don't mark remove function as __exit
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and se
On 26 September 2018 at 20:58, Arnd Bergmann wrote:
> The __exit section is left out for built-in drivers, so a
> 'remove' callback must not be marked as such to avoid breaking when
> we unbind a device at runtime. This was pointed out by kbuild:
>
> `sprd_spi_remove'
The __exit section is left out for built-in drivers, so a
'remove' callback must not be marked as such to avoid breaking when
we unbind a device at runtime. This was pointed out by kbuild:
`sprd_spi_remove' referenced in section `.data' of drivers/spi/spi-sprd.o:
defined
From: Greentime Hu
[ Upstream commit 3350139c0ff3c95724b784f7109987d533cb3ecd ]
This patch is used to fix nds32 allmodconfig/allyesconfig build error
because GCOV kernel embeds counters in the kernel for each line
and a part of that embed in __exit text. So we need to keep the
EXIT_TEXT and
Hi,
Please drop it, since Peter's patch fixes this problem better way.
https://lkml.org/lkml/2018/9/6/403
Thank you,
On Sat, 1 Sep 2018 21:38:13 +0900
Masami Hiramatsu wrote:
> GCOV kernel embeds counters in the kernel for each line
> and a part of that embed in __exit text. So
On Tue, 4 Sep 2018 15:54:19 +0800
Greentime Hu wrote:
> This patch is used to fix nds32 allmodconfig/allyesconfig build error
> because GCOV kernel embeds counters in the kernel for each line
> and a part of that embed in __exit text. So we need to keep the
> EXIT_TEXT and E
This patch is used to fix nds32 allmodconfig/allyesconfig build error
because GCOV kernel embeds counters in the kernel for each line
and a part of that embed in __exit text. So we need to keep the
EXIT_TEXT and EXIT_DATA if CONFIG_GCOV_KERNEL=y.
Link: https://lkml.org/lkml/2018/9/1/125
Signed
GCOV kernel embeds counters in the kernel for each line
and a part of that embed in __exit text. So we need to
keep the __exit text if CONFIG_GCOV_KERNEL=y.
Without this patch, if we discards __exit text (e.g.
disables CONFIG_GENERIC_BUG, CONFIG_JUMP_LABEL and
CONFIG_SMP_ON_UP) but enables
jump labels in __exit code
With the following commit:
333522447063 ("jump_label: Explicitly disable jump labels in __init code")
... we explicitly disabled jump labels in __init code, so they could be
detected and not warned about in the following commit:
dc1dd184c2f0 ("jump
jump labels in __exit code
With the following commit:
333522447063 ("jump_label: Explicitly disable jump labels in __init code")
... we explicitly disabled jump labels in __init code, so they could be
detected and not warned about in the following commit:
dc1dd184c2f0 ("jump
_label patching attempt")
In-kernel __exit code has the same issue. It's never used, so it's
freed along with the rest of initmem. But jump label entries in __exit
code aren't explicitly disabled, so we get the following warning when
enabling pr_debug() in __exit code:
can&#
On 02/01/2018 at 10:43:33 +0100, Arnd Bergmann wrote:
> The mxc_rtc_remove is incorrectly annotated as __exit:
>
> `mxc_rtc_remove' referenced in section `.data' of drivers/rtc/rtc-mxc_v2.o:
> defined in discarded section `.exit.text' of drivers/rtc/rtc-mxc_v2.o
>
The mxc_rtc_remove is incorrectly annotated as __exit:
`mxc_rtc_remove' referenced in section `.data' of drivers/rtc/rtc-mxc_v2.o:
defined in discarded section `.exit.text' of drivers/rtc/rtc-mxc_v2.o
This should not be done, as devices can be dynamically bound
and unbound to a
ompson, Bryan E.
> ; *S-Par-Maintainer
> ; de...@driverdev.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] staging: unisys/visorbus: add __init/__exit annotations
>
> gcc-4.6 causes a harmless warning about the init function:
>
> WARNING: vmlinux.o(.text+
is often because init_unisys lacks a __init
annotation or the annotation of visorutil_spar_detect is wrong.
It appears that newer versions inline visorutil_spar_detect(),
end up with an empty __init section. This marks the module
entry points as __init and __exit respectively, which avoids
the
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Torokhov
commit 3ff861f59f6c1f5bf2bc03d2cd36ac3f992cbc06 upstream.
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Torokhov
commit 3ff861f59f6c1f5bf2bc03d2cd36ac3f992cbc06 upstream.
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit
On Mon, 20 Mar 2017, Bartlomiej Zolnierkiewicz wrote:
> > Even if bus is not hot-pluggable, devices can be unbound from the
> > driver via sysfs, so we should not be using __exit annotations on
> > remove() methods. The only exception is drivers registered with
> > platf
can be unbound from the
> > > driver via sysfs, so we should not be using __exit annotations on
> > > remove() methods. The only exception is drivers registered with
> > > platform_driver_probe() which specifically disables sysfs bind/unbind
> > > attributes.
Hi Bartlomiej,
On Mon, Mar 20, 2017 at 06:19:17PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday, March 01, 2017 05:31:01 PM Dmitry Torokhov wrote:
> > Even if bus is not hot-pluggable, devices can be unbound from the
> > driver via sysfs, so we should not be using __exit
On Wednesday, March 01, 2017 05:31:01 PM Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_p
On Saturday, February 25, 2017 11:24:46 AM Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, the devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_
On Wednesday, March 01, 2017 03:31:09 PM Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_p
On Saturday, February 25, 2017 11:25:11 AM Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, the devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_
Hi Dmitry,
On Wed, Mar 01, 2017 at 03:44:53PM -0800, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, the devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers regist
On 01/03/2017 at 15:33:23 -0800, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_pr
On 05/03/17 12:57, Linus Walleij wrote:
> On Thu, Mar 2, 2017 at 12:37 AM, Dmitry Torokhov
> wrote:
>
>> Even if bus is not hot-pluggable, devices can be unbound from the
>> driver via sysfs, so we should not be using __exit annotations on
>> remove() methods. Th
On Thu, Mar 2, 2017 at 12:37 AM, Dmitry Torokhov
wrote:
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_p
On 01/03/17 23:37, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_probe() which specifica
From: Dmitry Torokhov
Date: Wed, 1 Mar 2017 17:24:47 -0800
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_p
On Wed 2017-03-01 15:41:23, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_driver_probe() which
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Hi,
On Wed, Mar 01, 2017 at 03:33:23PM -0800, Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers registered with
> platform_
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe(), which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Signed-off-by
Hi,
On Sunday, February 12, 2017 04:13:49 PM Dmitry Torokhov wrote:
> Even if bus is not hot-pluggable, the devices can be unbound from the
> driver via sysfs, so we should not be using __exit annotations on
> remove() methods. The only exception is drivers regist
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.
Also pmagb(a|b
On 13/01/2017 at 16:32:51 +0100, Arnd Bergmann wrote :
> The remove function can be called at runtime for a manual 'unbind'
> operation and must not be left out from a built-in driver, as kbuild
> complains:
>
> `stm32_rtc_remove' referenced in section `.data.stm32_rtc_driver' of
> drivers/rtc/rt
2.c b/drivers/rtc/rtc-stm32.c
index c4789b5a5d81..3513e052722f 100644
--- a/drivers/rtc/rtc-stm32.c
+++ b/drivers/rtc/rtc-stm32.c
@@ -657,7 +657,7 @@ static int stm32_rtc_probe(struct platform_device *pdev)
return ret;
}
-static int __exit stm32_rtc_remove(struct platform_device *pdev)
Add __init,__exit attribute for function that only called in
module init/exit to save memory.
Signed-off-by: Ganesh Mahendran
v4:
remove __init/__exit from zsmalloc_mount/zsmalloc_umount
v3:
revert change in v2 - Sergey
v2:
add __init/__exit for zs_register_cpu_notifier
From: Jason Baron
Date: Wed, 6 Jul 2016 17:42:32 -0400
> The jump table can reference text found in an __exit section. Thus,
> instead of discarding it at build/link time, include EXIT_TEXT as part
> of __init and release it at system boot time.
>
> Without this patch the
The jump table can reference text found in an __exit section. Thus,
instead of discarding it at build time, include EXIT_TEXT as part
of __init and it will be released when the system boots.
Cc: Arnd Bergmann
Cc: linux-arm-ker...@lists.infradead.org
Cc: li...@armlinux.org.uk
Signed-off-by: Jason
From: Chris Metcalf
Previously, all the __exit sections were just dropped by
the link phase. However, if there are static_key (jump label)
constructs in __exit sections that are not modules, the link fails
with the message:
`.exit.text' referenced in section `__jump_table'
The jump table can reference text found in an __exit section. Thus,
instead of discarding it at build/link time, include EXIT_TEXT as part
of __init and release it at system boot time.
Without this patch the link fails with:
`.exit.text' referenced in section `__jump_table'
On Wed, Jul 06, 2016 at 02:23:51PM +0800, Ganesh Mahendran wrote:
> Add __init,__exit attribute for function that only called in
> module init/exit to save memory.
>
> Signed-off-by: Ganesh Mahendran
>
> v3:
> revert change in v2 - Sergey
> v2:
>
> WARNING: vmlinux.o(.init.text+0x1f2ca): Section mismatch in reference from
>> the function zs_init() to the function .exit.text:zs_stat_exit()
The function __init zs_init() references
a function __exit zs_stat_exit().
This is often seen when error handling in the ini
>>):
>> WARNING: mm/built-in.o(.init.text+0x4c3f): Section mismatch in reference
>> from the function zs_init() to the function .exit.text:zsmalloc_unmount()
The function __init zs_init() references
a function __exit zsmalloc_unmount().
This is often seen when error handling in
Add __init,__exit attribute for function that only called in
module init/exit to save memory.
Signed-off-by: Ganesh Mahendran
v3:
revert change in v2 - Sergey
v2:
add __init/__exit for zs_register_cpu_notifier/zs_unregister_cpu_notifier
---
mm/zsmalloc.c | 6 +++---
1 file changed
; > >> -static void zs_unregister_cpu_notifier(void)
>> > >> +static void __exit zs_unregister_cpu_notifier(void)
>> > >> {
>> > >
>> > > this __exit symbol is called from `__init zs_init()' and thus is
>> > > free to c
On Tue, Jul 05, 2016 at 10:00:28AM +0900, Sergey Senozhatsky wrote:
> Hello Ganesh,
>
> On (07/04/16 17:21), Ganesh Mahendran wrote:
> > > On (07/04/16 14:49), Ganesh Mahendran wrote:
> > > [..]
> > >> -static void zs_unregister_cpu_no
Hello Ganesh,
On (07/04/16 17:21), Ganesh Mahendran wrote:
> > On (07/04/16 14:49), Ganesh Mahendran wrote:
> > [..]
> >> -static void zs_unregister_cpu_notifier(void)
> >> +static void __exit zs_unregister_cpu_notifier(void)
> >> {
> >
> >
Hi, Sergey
2016-07-04 16:43 GMT+08:00 Sergey Senozhatsky
:
> On (07/04/16 14:49), Ganesh Mahendran wrote:
> [..]
>> -static void zs_unregister_cpu_notifier(void)
>> +static void __exit zs_unregister_cpu_notifier(void)
>> {
>
> this __exit symbol is called from
On (07/04/16 14:49), Ganesh Mahendran wrote:
[..]
> -static void zs_unregister_cpu_notifier(void)
> +static void __exit zs_unregister_cpu_notifier(void)
> {
this __exit symbol is called from `__init zs_init()' and thus is
free to crash.
-ss
Add __init,__exit attribute for function that only called in
module init/exit to save memory.
Signed-off-by: Ganesh Mahendran
v2:
add __init/__exit for zs_register_cpu_notifier/zs_unregister_cpu_notifier
---
mm/zsmalloc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions
On Fri, Jul 01, 2016 at 02:41:05PM +0800, Ganesh Mahendran wrote:
> Add __init,__exit attribute for function that is only called in
> module init/exit
to save memory.
>
> Signed-off-by: Ganesh Mahendran
> ---
> mm/zsmalloc.c | 6 +++---
> 1 file change
Add __init,__exit attribute for function that is only called in
module init/exit
Signed-off-by: Ganesh Mahendran
---
mm/zsmalloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 6fc631a..1c7460b 100644
--- a/mm/zsmalloc.c
+++ b/mm
On Saturday, 18 June 2016 19:42:07 UTC Joshua Houghton wrote:
> Add the __exit macro to the dgnc_cleanup_module(void) function
> in dgnc_driver.c
>
> Signed-off-by: Joshua Houghton
> ---
> drivers/staging/dgnc/dgnc_driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deleti
Add the __exit macro to the dgnc_cleanup_module(void) function
in dgnc_driver.c
Signed-off-by: Joshua Houghton
---
drivers/staging/dgnc/dgnc_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
On 15/03/2016 at 22:44:31 +0100, Arnd Bergmann wrote :
> The probe and remove callbacks of the platform driver are marked __init
> and __exit, respectively. However, this is not a correct way to annotate
> them, as it will result in those sections to be discarded at link time
> o
Am 16.03.2016 um 10:30 schrieb Alexandre Belloni:
> Hi,
>
> On 15/03/2016 at 22:44:31 +0100, Arnd Bergmann wrote :
>> The probe and remove callbacks of the platform driver are marked __init
>> and __exit, respectively. However, this is not a correct way to annotate
>>
Hi,
On 15/03/2016 at 22:44:31 +0100, Arnd Bergmann wrote :
> The probe and remove callbacks of the platform driver are marked __init
> and __exit, respectively. However, this is not a correct way to annotate
> them, as it will result in those sections to be discarded at link time
> o
The probe and remove callbacks of the platform driver are marked __init
and __exit, respectively. However, this is not a correct way to annotate
them, as it will result in those sections to be discarded at link time
or after boot, while we can actually call them again based on manual
unbinding, or
On Monday 29 February 2016 16:40:02 Joonsoo Kim wrote:
>
> Hello, Arnd.
>
> I think that we can avoid this error by using __free_page().
> It would not be inlined so calling it would have no problem.
>
> Could you test it, please?
Yes, I suspect the driver should have done that anyway, new patc
ump_table' of crypto/built-in.o:
> defined in discarded section `.exit.text' of crypto/built-in.o
>
> I could not come up with a nice solution that ignores __jump_table
> entries in discarded code, so we probably now have to treat this
> as something a driver is not allowed t
.exit.text' of crypto/built-in.o
I could not come up with a nice solution that ignores __jump_table
entries in discarded code, so we probably now have to treat this
as something a driver is not allowed to do. Removing the __exit
annotation avoids the problem in this particular driver, but t
On Thu, Oct 22, 2015 at 04:52:33PM +0200, Arnd Bergmann wrote:
> The remove function of a device driver should not be marked
> __exit, because that section gets discarded for built-in drivers,
> and it is still possible to manually unbind a driver from a
> device, which would result
-static int __exit ramoops_remove(struct platform_device *pdev)
+static int ramoops_remove(struct platform_device *pdev)
Arnd,
Thanks. I folded that fix into the commit that made the error and rebased (I
don't believe
anyone is foolish enough to base work on my "next" branch
1 - 100 of 292 matches
Mail list logo
