Re: [RFC][PATCH] module: Limit line length of module prints

Laura Abbott writes: > On 12/11/2015 01:39 AM, Rusty Russell wrote: >> Laura Abbott writes: >>> print_modules currently uses pr_cont to print all module information. >>> This has the side effect of printing lots of modules on one very long >>> line. This m

Re: [RFC][PATCH] module: Limit line length of module prints

Laura Abbott <labb...@redhat.com> writes: > On 12/11/2015 01:39 AM, Rusty Russell wrote: >> Laura Abbott <labb...@fedoraproject.org> writes: >>> print_modules currently uses pr_cont to print all module information. >>> This has the side effect of printing lo

Re: [RFC][PATCH] module: Limit line length of module prints

Laura Abbott writes: > print_modules currently uses pr_cont to print all module information. > This has the side effect of printing lots of modules on one very long > line. This makes copy/pasting oopses more effort if manual wrapping is > required. Place a reasonable limit (80 chars) on the

Re: [RFC][PATCH] module: Limit line length of module prints

Laura Abbott writes: > print_modules currently uses pr_cont to print all module information. > This has the side effect of printing lots of modules on one very long > line. This makes copy/pasting oopses more effort if manual wrapping is > required. Place a reasonable

Re: [PATCH] module: check vermagic match exactly when load modules

Xie XiuQi writes: > Usually, checking kernel version will be ignore when loading > modules if CONFIG_MODVERSIONS option is enable. This could > potentially lead to a mismatch with the running kernel. > > With this option, we prevent to load the modules which vermagic > is not match exactly with

Re: [PATCH] module: check vermagic match exactly when load modules

Xie XiuQi writes: > Usually, checking kernel version will be ignore when loading > modules if CONFIG_MODVERSIONS option is enable. This could > potentially lead to a mismatch with the running kernel. > > With this option, we prevent to load the modules which vermagic > is not

Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero

Ingo Molnar writes: > * Rusty Russell wrote: >> I don't think there are great answers here. But adding more subtle zeroing >> semantics feels wrong, even if it will mostly Just Work. > > It's not subtle if the naming clearly reflects it (hence my suggestion to

Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero

Ingo Molnar <mi...@kernel.org> writes: > * Rusty Russell <ru...@rustcorp.com.au> wrote: >> I don't think there are great answers here. But adding more subtle zeroing >> semantics feels wrong, even if it will mostly Just Work. > > It's not subtle if the nam

Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero

Ingo Molnar writes: > * Steven Rostedt wrote: > >> On Fri, 04 Dec 2015 12:05:12 +1030 >> Rusty Russell wrote: >> >> > This is clever, but I would advise against such subtle code. We will >> > never be >> > able to remove this code onc

Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero

Ingo Molnar <mi...@kernel.org> writes: > * Steven Rostedt <rost...@goodmis.org> wrote: > >> On Fri, 04 Dec 2015 12:05:12 +1030 >> Rusty Russell <ru...@rustcorp.com.au> wrote: >> >> > This is clever, but I would advise against such subtle

Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero

Steven Rostedt writes: > Xunlei Pang reported a bug in the scheduler code when > CONFIG_CPUMASK_OFFSTACK is set, several of the cpumasks used by the > root domains can contain garbage. The code does the following: > > memset(rd, 0, sizeof(*rd)); > > if (!alloc_cpumask_var(>span,

Re: [PATCH v4] livepatch: Cleanup module page permission changes

Jiri Kosina writes: > On Thu, 3 Dec 2015, Josh Poimboeuf wrote: > >> Calling set_memory_rw() and set_memory_ro() for every iteration of the >> loop in klp_write_object_relocations() is messy, inefficient, and >> error-prone. >> >> Change all the read-only pages to read-write before the loop and

Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero

Steven Rostedt writes: > Xunlei Pang reported a bug in the scheduler code when > CONFIG_CPUMASK_OFFSTACK is set, several of the cpumasks used by the > root domains can contain garbage. The code does the following: > > memset(rd, 0, sizeof(*rd)); > > if

Re: [PATCH v4] livepatch: Cleanup module page permission changes

Jiri Kosina writes: > On Thu, 3 Dec 2015, Josh Poimboeuf wrote: > >> Calling set_memory_rw() and set_memory_ro() for every iteration of the >> loop in klp_write_object_relocations() is messy, inefficient, and >> error-prone. >> >> Change all the read-only pages to read-write

Re: linux-next: build failure after merge of the modules tree

Mark Brown writes: > Hi Rusty, > > After merging the modules tree, today's linux-next x86 allmodconfig build > (20151201) failed like this: > > /home/broonie/next/next/arch/x86/kernel/livepatch.c: In function > 'klp_write_module_reloc': >

Re: linux-next: build failure after merge of the modules tree

Mark Brown writes: > Hi Rusty, > > After merging the modules tree, today's linux-next x86 allmodconfig build > (20151201) failed like this: > > /home/broonie/next/next/arch/x86/kernel/livepatch.c: In function > 'klp_write_module_reloc': >

Re: linux-next: build failure after merge of the modules tree

Stephen Rothwell writes: > Hi Rusty, > > After merging the modules tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from include/linux/kexec.h:26:0, > from include/linux/crash_dump.h:5, > from

Re: linux-next: build failure after merge of the modules tree

Stephen Rothwell writes: > Hi Rusty, > > After merging the modules tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from include/linux/kexec.h:26:0, > from include/linux/crash_dump.h:5, >

Re: [PATCH v2] module: keep percpu symbols in module's symtab

Miroslav Benes writes: > Currently, percpu symbols from .data..percpu ELF section of a module are > not copied over and stored in final symtab array of struct module. > Consequently such symbol cannot be returned via kallsyms API (for > example kallsyms_lookup_name). This can be especially

Re: [PATCH v2] module: keep percpu symbols in module's symtab

Miroslav Benes writes: > Currently, percpu symbols from .data..percpu ELF section of a module are > not copied over and stored in final symtab array of struct module. > Consequently such symbol cannot be returned via kallsyms API (for > example kallsyms_lookup_name). This can be

Re: [PATCH] paravirt: remove paravirt ops pmd_update[_defer] and pte_update_defer

Juergen Gross writes: > Ping? Acked-by: Rusty Russell Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the

Re: [PATCH] module: keep percpu symbols in module's symtab

Miroslav Benes writes: > Currently, percpu symbols from .data..percpu ELF section of a module are > not copied over and stored in final symtab array of struct module. > Consequently such symbol cannot be returned via kallsyms API (for > example kallsyms_lookup_name). This can be especially

Re: [PATCH] paravirt: remove paravirt ops pmd_update[_defer] and pte_update_defer

Juergen Gross <jgr...@suse.com> writes: > Ping? Acked-by: Rusty Russell <ru...@rustcorp.com.au> Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://

Re: [PATCH] module: keep percpu symbols in module's symtab

Miroslav Benes writes: > Currently, percpu symbols from .data..percpu ELF section of a module are > not copied over and stored in final symtab array of struct module. > Consequently such symbol cannot be returned via kallsyms API (for > example kallsyms_lookup_name). This can be

Re: [PATCH 4/4] module: clean up RO/NX handling.

Josh Poimboeuf writes: > On Tue, Nov 10, 2015 at 12:27:34PM +1030, Rusty Russell wrote: >> Josh Poimboeuf writes: >> > On Mon, Nov 09, 2015 at 02:53:57PM +1030, Rusty Russell wrote: >> > >> >> @@ -1858,74 +1849,75 @@ static void mod_sysfs_teardown(struct

Re: [PATCH 4/4] module: clean up RO/NX handling.

Josh Poimboeuf <jpoim...@redhat.com> writes: > On Tue, Nov 10, 2015 at 12:27:34PM +1030, Rusty Russell wrote: >> Josh Poimboeuf <jpoim...@redhat.com> writes: >> > On Mon, Nov 09, 2015 at 02:53:57PM +1030, Rusty Russell wrote: >> > >> >> @@ -1858,7

Re: [PATCH 4/4] module: clean up RO/NX handling.

Josh Poimboeuf writes: > On Mon, Nov 09, 2015 at 02:53:57PM +1030, Rusty Russell wrote: > >> @@ -1858,74 +1849,75 @@ static void mod_sysfs_teardown(struct module *mod) >> /* >> * LKM RO/NX protection: protect module's text/ro-data >> * from modificati

Re: [PATCH 3/4] module: use a structure to encapsulate layout.

Peter Zijlstra writes: > On Mon, Nov 09, 2015 at 02:53:56PM +1030, Rusty Russell wrote: >> diff --git a/kernel/module.c b/kernel/module.c >> index 14b224967e7b..a0a3d6d9d5e8 100644 >> --- a/kernel/module.c >> +++ b/kernel/module.c >> @@ -108,13 +108,6 @@ stat

Re: [PATCH 4/4] module: clean up RO/NX handling.

Josh Poimboeuf <jpoim...@redhat.com> writes: > On Mon, Nov 09, 2015 at 02:53:57PM +1030, Rusty Russell wrote: > >> @@ -1858,74 +1849,75 @@ static void mod_sysfs_teardown(struct module *mod) >> /* >> * LKM RO/NX protection: protect module's text/ro-data >> *

Re: [PATCH 3/4] module: use a structure to encapsulate layout.

Peter Zijlstra <pet...@infradead.org> writes: > On Mon, Nov 09, 2015 at 02:53:56PM +1030, Rusty Russell wrote: >> diff --git a/kernel/module.c b/kernel/module.c >> index 14b224967e7b..a0a3d6d9d5e8 100644 >> --- a/kernel/module.c >> +++ b/kernel/module.c >>

[PATCH 3/4] module: use a structure to encapsulate layout.

Poimboeuf Signed-off-by: Rusty Russell --- arch/alpha/kernel/module.c | 2 +- arch/arc/kernel/unwind.c| 4 +- arch/avr32/kernel/module.c | 12 +-- arch/ia64/kernel/module.c | 14 +-- arch/metag/kernel/module.c | 4 +- arch/mips/kernel/vpe.c | 6 +- arch

[PATCH 4/4] module: clean up RO/NX handling.

create three helper functions: frob_text(), frob_rodata() and frob_writable_data(). We then call these explicitly at every point, so it's clear what we're doing. We also expose module_enable_ro() and module_disable_ro() for livepatch to use. Cc: Josh Poimboeuf Signed-off-by: Rusty Russell

[PATCH 0/4] module RO/NX cleanups.

Josh drew my attention to this code, and it clearly needed some love. Josh Poimboeuf (1): module: Use the same logic for setting and unsetting RO/NX Rusty Russell (3): gcov: use within_module() helper. module: use a structure to encapsulate layout. module: clean up RO/NX handling. arch

[PATCH 1/4] module: Use the same logic for setting and unsetting RO/NX

still confusingly asymmetrical. Instead, use the same logic to do both. Also add some new set_module_{init,core}_ro_nx() helper functions for more symmetry with the unset functions. Signed-off-by: Josh Poimboeuf Signed-off-by: Rusty Russell --- kernel/module.c | 57

[PATCH 2/4] gcov: use within_module() helper.

An exact mapping would be within_module_core(), but at this stage (MODULE_STATE_GOING) the init section is empty, and this is clearer. Cc: Peter Oberparleiter Signed-off-by: Rusty Russell --- kernel/gcov/base.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/kernel

[PULL] modules-next

The following changes since commit dd2384a75d1c046faf068a6352732a204814b86d: Merge tag 'arc-v4.2-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2015-08-08 04:38:00 +0300) are available in the git repository at:

Re: [PATCH v2 3/3] livepatch: Cleanup module page permission changes

Josh Poimboeuf writes: > On Fri, Nov 06, 2015 at 02:42:46PM +0100, Petr Mladek wrote: >> naming schemes. What about adding into the public API? >> >> set_module_ro() >> set_module_rw() >> >> It should modify everything: init, core, text, and data but only >> the ro/rw flags. > > Even that

Re: [PATCH v2 2/3] module: Use the same logic for setting and unsetting RO/NX

Josh Poimboeuf writes: > When setting a module's RO and NX permissions, set_section_ro_nx() is > used, but when clearing them, unset_module_{init,core}_ro_nx() are used. > The unset functions don't have the same checks the set function has for > partial page protections. It's probably harmless,

[PULL] modules-next

The following changes since commit dd2384a75d1c046faf068a6352732a204814b86d: Merge tag 'arc-v4.2-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2015-08-08 04:38:00 +0300) are available in the git repository at:

Re: [PATCH v2 3/3] livepatch: Cleanup module page permission changes

Josh Poimboeuf writes: > On Fri, Nov 06, 2015 at 02:42:46PM +0100, Petr Mladek wrote: >> naming schemes. What about adding into the public API? >> >> set_module_ro() >> set_module_rw() >> >> It should modify everything: init, core, text, and data but only >> the ro/rw

Re: [PATCH v2 2/3] module: Use the same logic for setting and unsetting RO/NX

Josh Poimboeuf writes: > When setting a module's RO and NX permissions, set_section_ro_nx() is > used, but when clearing them, unset_module_{init,core}_ro_nx() are used. > The unset functions don't have the same checks the set function has for > partial page protections.

[PATCH 3/4] module: use a structure to encapsulate layout.

pet...@infradead.org> Cc: Josh Poimboeuf <jpoim...@redhat.com> Signed-off-by: Rusty Russell <ru...@rustcorp.com.au> --- arch/alpha/kernel/module.c | 2 +- arch/arc/kernel/unwind.c| 4 +- arch/avr32/kernel/module.c | 12 +-- arch/ia64/kernel/module.c | 14 +--

[PATCH 4/4] module: clean up RO/NX handling.

ed-off-by: Rusty Russell <ru...@rustcorp.com.au> --- include/linux/module.h | 4 ++ kernel/module.c| 168 +++-- 2 files changed, 81 insertions(+), 91 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index

[PATCH 0/4] module RO/NX cleanups.

Josh drew my attention to this code, and it clearly needed some love. Josh Poimboeuf (1): module: Use the same logic for setting and unsetting RO/NX Rusty Russell (3): gcov: use within_module() helper. module: use a structure to encapsulate layout. module: clean up RO/NX handling. arch

[PATCH 1/4] module: Use the same logic for setting and unsetting RO/NX

It's probably harmless, but it's still confusingly asymmetrical. Instead, use the same logic to do both. Also add some new set_module_{init,core}_ro_nx() helper functions for more symmetry with the unset functions. Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> Signed-off-by: Rusty

[PATCH 2/4] gcov: use within_module() helper.

An exact mapping would be within_module_core(), but at this stage (MODULE_STATE_GOING) the init section is empty, and this is clearer. Cc: Peter Oberparleiter <ober...@linux.vnet.ibm.com> Signed-off-by: Rusty Russell <ru...@rustcorp.com.au> --- kernel/gcov/base.c | 7 +-- 1 fil

[PULL] Module preeption fix

The following changes since commit 1b647a166f07dcf08709c8606470f4b17a4aa11d: Merge tag 'dmaengine-fix-4.2-rc8' of git://git.infradead.org/users/vkoul/slave-dma (2015-08-18 12:17:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git

[PULL] Module preeption fix

The following changes since commit 1b647a166f07dcf08709c8606470f4b17a4aa11d: Merge tag 'dmaengine-fix-4.2-rc8' of git://git.infradead.org/users/vkoul/slave-dma (2015-08-18 12:17:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git

Re: [PATCH] module: Prevent recursion bug caused by module RCU check

Peter Zijlstra writes: > On Tue, Oct 20, 2015 at 06:53:31PM +0200, Peter Zijlstra wrote: >> Also, would it not be better to fix WARN_ON_ONCE() instead? >> > > Clearly I'm an idiot and should stay away from the computer... Acked-by: Rusty Russell (I mean, the patch, not t

Re: [PATCH] module: Prevent recursion bug caused by module RCU check

Peter Zijlstra <pet...@infradead.org> writes: > On Tue, Oct 20, 2015 at 06:53:31PM +0200, Peter Zijlstra wrote: >> Also, would it not be better to fix WARN_ON_ONCE() instead? >> > > Clearly I'm an idiot and should stay away from the computer... Acked-by: Rusty Russell

Re: [PATCH v2 0/6] kernel/cpu.c: eliminate some indirection

Rasmus Villemoes writes: > On Tue, Oct 06 2015, Rasmus Villemoes wrote: > >> v2: fix build failure on ppc, add acks. > > Does anyone want to take these through their tree? I think the x86 tree is the least illogical place, unless akpm wants it? Cheers, Rusty. -- To unsubscribe from this list:

Re: [PATCH v2 0/6] kernel/cpu.c: eliminate some indirection

Rasmus Villemoes writes: > On Tue, Oct 06 2015, Rasmus Villemoes wrote: > >> v2: fix build failure on ppc, add acks. > > Does anyone want to take these through their tree? I think the x86 tree is the least illogical place, unless akpm wants it?

Re: [PATCH 0/3] sys_membarrier (x86, generic)

Mathieu Desnoyers writes: > - On Oct 5, 2015, at 7:21 PM, Rusty Russell ru...@ozlabs.org wrote: > >> Mathieu Desnoyers writes: >>> Hi Andrew, >>> >>> Here is a repost of sys_membarrier, rebased on top of Linus commit >>> c4b5fd3fb2058b650

Re: [PATCH 0/3] sys_membarrier (x86, generic)

Mathieu Desnoyers <mathieu.desnoy...@efficios.com> writes: > - On Oct 5, 2015, at 7:21 PM, Rusty Russell ru...@ozlabs.org wrote: > >> Mathieu Desnoyers <mathieu.desnoy...@efficios.com> writes: >>> Hi Andrew, >>> >>> Here is a repos

Re: [PATCH v2] modpost: Add flag -E for making section mismatches fatal

Nicolas Boichat writes: > The section mismatch warning can be easy to miss during the kernel build > process. Allow it to be marked as fatal to be easily caught and prevent > bugs from slipping in. > > Setting CONFIG_SECTION_MISMATCH_WARN_ONLY=y causes these warnings to be > non-fatal, since

Re: [PATCH 0/3] sys_membarrier (x86, generic)

Mathieu Desnoyers writes: > Hi Andrew, > > Here is a repost of sys_membarrier, rebased on top of Linus commit > c4b5fd3fb2058b650447372472ad24e2a989f9f6 without any change since the > last v19 post other that proceeding to further testing. When merging > with other system calls, system call

Re: [PATCH v2] modpost: Add flag -E for making section mismatches fatal

Nicolas Boichat writes: > The section mismatch warning can be easy to miss during the kernel build > process. Allow it to be marked as fatal to be easily caught and prevent > bugs from slipping in. > > Setting CONFIG_SECTION_MISMATCH_WARN_ONLY=y causes these warnings to be

Re: [PATCH 0/3] sys_membarrier (x86, generic)

Mathieu Desnoyers writes: > Hi Andrew, > > Here is a repost of sys_membarrier, rebased on top of Linus commit > c4b5fd3fb2058b650447372472ad24e2a989f9f6 without any change since the > last v19 post other that proceeding to further testing. When merging > with other

Re: [PATCH] modpost: Add flag -f for making section mismatches fatal

Nicolas Boichat writes: > The section mismatch warning can be easy to miss during the kernel build > process. Allow it to be marked as fatal to be easily caught and prevent > bugs from slipping in. > > Setting CONFIG_SECTION_MISMATCH_WARNING=y causes these warnings to be > non-fatal, since there

Re: [PATCH] kernel/params.c: remove confusing cast

Rasmus Villemoes writes: > Both sides of the assignment are const char*, so this cast is > unnecessary and confusing. > > Signed-off-by: Rasmus Villemoes Acked-by: Rusty Russell Thanks, Rusty. > kernel/params.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

Re: [PATCH] modpost: Add flag -f for making section mismatches fatal

Nicolas Boichat writes: > The section mismatch warning can be easy to miss during the kernel build > process. Allow it to be marked as fatal to be easily caught and prevent > bugs from slipping in. > > Setting CONFIG_SECTION_MISMATCH_WARNING=y causes these warnings to be >

Re: [PATCH] kernel/params.c: remove confusing cast

Rasmus Villemoes <li...@rasmusvillemoes.dk> writes: > Both sides of the assignment are const char*, so this cast is > unnecessary and confusing. > > Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> Acked-by: Rusty Russell <ru...@rustcorp.com.au> Thanks,

Re: [PATCH 0/5] kernel/cpu.c: eliminate some indirection

Rasmus Villemoes writes: > On Sun, Sep 27 2015, Rusty Russell wrote: > >> But to be clear, it has outlived its usefulness, but it was not useless. >> >> In particular, there used to be a debug config where 'struct cpumask' >> wasn't defined, so we could catch pe

Re: [PATCH 0/5] kernel/cpu.c: eliminate some indirection

Rasmus Villemoes <li...@rasmusvillemoes.dk> writes: > On Sun, Sep 27 2015, Rusty Russell <ru...@rustcorp.com.au> wrote: > >> But to be clear, it has outlived its usefulness, but it was not useless. >> >> In particular, there used to be a debug config where 'stru

Re: [PATCH 0/5] kernel/cpu.c: eliminate some indirection

ctions set_cpu_xyz. There's quite a bit of code > throughout the kernel which iterates over or otherwise accesses these > bitmaps, and having the access go via the cpu_xyz_mask variables is > simply a useless indirection. Thanks, consider all patches Acked-by: Rusty Russell But to be clear, it

Re: [PATCH 0/5] kernel/cpu.c: eliminate some indirection

ing via > the exposed functions set_cpu_xyz. There's quite a bit of code > throughout the kernel which iterates over or otherwise accesses these > bitmaps, and having the access go via the cpu_xyz_mask variables is > simply a useless indirection. Thanks, consider all patches Acked-by: Rus

Re: module_put_and_exit() and free_module()

Aleksa Sarai writes: >>From my understanding, module_put_and_exit() can be used inside a > module to (from within the module) kill itself. However, it doesn't > seem to properly free the modules references (and internal > bookkeeping) since module_put_and_exit() doesn't call free_module(). > And

Re: module_put_and_exit() and free_module()

Aleksa Sarai writes: >>From my understanding, module_put_and_exit() can be used inside a > module to (from within the module) kill itself. However, it doesn't > seem to properly free the modules references (and internal > bookkeeping) since module_put_and_exit() doesn't call

Re: timing of module MODULE_STATE_COMING notifier

"Frank Ch. Eigler" writes: > Hi, Rusty - > > > I wrote: > >> [...] >> > Notifiers suck for stuff like this :( Module state has many steps, >> > so my preference has been to open-code explicit hooks. [...] >> >> You mean something like the trace_module_load()? (We will probably >> experiment

Re: timing of module MODULE_STATE_COMING notifier

"Frank Ch. Eigler" writes: > Hi, Rusty - > > > I wrote: > >> [...] >> > Notifiers suck for stuff like this :( Module state has many steps, >> > so my preference has been to open-code explicit hooks. [...] >> >> You mean something like the trace_module_load()? (We will probably

Re: timing of module MODULE_STATE_COMING notifier

"Frank Ch. Eigler" writes: > Hi, Rusty - > > We just [1] came across your patch [2] from last year (merged into > 3.17), wherein the RO/NX mapping settings for module sections were > moved to an earlier point in the module-loading sequence. > > That patch also moved the MODULE_STATE_COMING

Re: [PATCH] x86/paravirt: remove unused operation

Juergen Gross writes: > Ping? Acked-by: Rusty Russell Cheers, Rusty. > On 08/06/2015 01:55 PM, Juergen Gross wrote: >> Remove the paravirt operation "get_tsc_khz" as it is used nowhere. >> >> Signed-off-by: Juergen Gross >> --- >> arch/x86/

Re: [PATCH] x86/paravirt: remove unused operation

Juergen Gross jgr...@suse.com writes: Ping? Acked-by: Rusty Russell ru...@rustcorp.com.au Cheers, Rusty. On 08/06/2015 01:55 PM, Juergen Gross wrote: Remove the paravirt operation get_tsc_khz as it is used nowhere. Signed-off-by: Juergen Gross jgr...@suse.com --- arch/x86/include/asm

Re: timing of module MODULE_STATE_COMING notifier

Frank Ch. Eigler f...@redhat.com writes: Hi, Rusty - We just [1] came across your patch [2] from last year (merged into 3.17), wherein the RO/NX mapping settings for module sections were moved to an earlier point in the module-loading sequence. That patch also moved the MODULE_STATE_COMING

Re: [PATCH 1/2] module: export param_free_charp()

Dan Streetman writes: > Change the param_free_charp() function from static to exported. > > It is used by zswap in the next patch. > > Signed-off-by: Dan Streetman Acked-by: Rusty Russell Thanks! Rusty. > --- > include/linux/moduleparam.h | 1 + > kernel/params.c

Re: [PATCH] kernel: make module.c itself more explicitly non-modular

Paul Gortmaker writes: > On 2015-08-26 12:06 AM, Rusty Russell wrote: >> Paul Gortmaker writes: >>> The Kconfig currently controlling compilation of this code is: >>> >>> menuconfig MODULES >>>bool "Enable loadable module support"

Re: [PATCH] kernel: make module.c itself more explicitly non-modular

Paul Gortmaker paul.gortma...@windriver.com writes: On 2015-08-26 12:06 AM, Rusty Russell wrote: Paul Gortmaker paul.gortma...@windriver.com writes: The Kconfig currently controlling compilation of this code is: menuconfig MODULES bool Enable loadable module support ...meaning

Re: [PATCH 1/2] module: export param_free_charp()

Dan Streetman ddstr...@ieee.org writes: Change the param_free_charp() function from static to exported. It is used by zswap in the next patch. Signed-off-by: Dan Streetman ddstr...@ieee.org Acked-by: Rusty Russell ru...@rustcorp.com.au Thanks! Rusty. --- include/linux/moduleparam.h | 1

Re: [PATCH] kernel: make module.c itself more explicitly non-modular

ou are trying to do? I would argue that module_init() should be the default; it implies no dependencies on the initialization, and it's a common pattern. Cheers, Rusty. > We can't of course delete the module.h include in this case since it > is used all through the rest of the file. &

Re: [PATCH 1/1] params: don't ignore the rest of cmdline if parse_one() fails

Oleg Nesterov writes: > parse_args() just aborts after it hits an error, so other args > at the same initcall level are simply ignored. This can lead to > other hard-to-understand problems, for example my testing machine > panics during the boot if I pass "locktorture.verbose=true". > > Change

Re: [PATCH] kernel: make module.c itself more explicitly non-modular

() should be the default; it implies no dependencies on the initialization, and it's a common pattern. Cheers, Rusty. We can't of course delete the module.h include in this case since it is used all through the rest of the file. Cc: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Paul Gortmaker

Re: [PATCH 1/1] params: don't ignore the rest of cmdline if parse_one() fails

Oleg Nesterov o...@redhat.com writes: parse_args() just aborts after it hits an error, so other args at the same initcall level are simply ignored. This can lead to other hard-to-understand problems, for example my testing machine panics during the boot if I pass locktorture.verbose=true.

Re: parse_args() is too unforgivable?

Oleg Nesterov writes: > On 08/24, Oleg Nesterov wrote: >> >> I booted the kernel with the additional patch below, and nothing bad has >> happened, > > Until I tried reboot it once with "locktorture.verbose=true" paramater. > It didn't boot. > > This is because parse_args() just aborts after it

Re: parse_args() is too unforgivable?

Oleg Nesterov o...@redhat.com writes: On 08/24, Oleg Nesterov wrote: I booted the kernel with the additional patch below, and nothing bad has happened, Until I tried reboot it once with locktorture.verbose=true paramater. It didn't boot. This is because parse_args() just aborts after it

Re: WARNING: CPU: 1 PID: 813 at kernel/module.c:291 module_assert_mutex_or_preempt+0x49/0x90()

y while we hold a reference on it, the data structure we do the lookup in very much _CAN_ change while we do the lookup. Therefore fix the comment and add the required preempt_disable(). Reported-by: poma Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Rusty Russell Fixes: a6e6abd575fc

Re: WARNING: CPU: 1 PID: 813 at kernel/module.c:291 module_assert_mutex_or_preempt+0x49/0x90()

-by: Peter Zijlstra (Intel) pet...@infradead.org Signed-off-by: Rusty Russell ru...@rustcorp.com.au Fixes: a6e6abd575fc (module: remove module_text_address()) Cc: sta...@kernel.org diff --git a/kernel/module.c b/kernel/module.c index b86b7bf1be38..8f051a106676 100644 --- a/kernel/module.c +++ b/kernel

Re: 0be964be0 "module: Sanitize RCU usage and locking" breaks symbol_put_addr?

Peter Zijlstra writes: > On Wed, Aug 19, 2015 at 06:19:43AM +0930, Rusty Russell wrote: >> Indeed! That comment is wrong, and your fix is good. >> >> Care to S-O-B on it? > > Of course, here goes. Thanks! This is an ancient bug (2009) which your extra assertions cau

Re: 0be964be0 module: Sanitize RCU usage and locking breaks symbol_put_addr?

Peter Zijlstra pet...@infradead.org writes: On Wed, Aug 19, 2015 at 06:19:43AM +0930, Rusty Russell wrote: Indeed! That comment is wrong, and your fix is good. Care to S-O-B on it? Of course, here goes. Thanks! This is an ancient bug (2009) which your extra assertions caught. It's

Re: 0be964be0 "module: Sanitize RCU usage and locking" breaks symbol_put_addr?

Peter Zijlstra writes: > On Mon, Aug 17, 2015 at 04:20:09PM -0700, Laura Abbott wrote: >> Hi, >> >> We received a few bug backtraces: >> >> [ 41.536933] [ cut here ] >> [ 41.537545] WARNING: CPU: 1 PID: 813 at kernel/module.c:291 >>

Re: 0be964be0 module: Sanitize RCU usage and locking breaks symbol_put_addr?

Peter Zijlstra pet...@infradead.org writes: On Mon, Aug 17, 2015 at 04:20:09PM -0700, Laura Abbott wrote: Hi, We received a few bug backtraces: [ 41.536933] [ cut here ] [ 41.537545] WARNING: CPU: 1 PID: 813 at kernel/module.c:291

Re: [PATCH v2] modpost: abort if a module symbol is too long

Takashi Iwai writes: > Module symbols have a limited length, but currently the build system > allows the build finishing even if the driver code contains a too long > symbol name, which eventually overflows the modversion_info[] item. > The compiler may catch at compiling *.mod.c like > CC

Re: [PATCH v2] modpost: abort if a module symbol is too long

Takashi Iwai ti...@suse.de writes: Module symbols have a limited length, but currently the build system allows the build finishing even if the driver code contains a too long symbol name, which eventually overflows the modversion_info[] item. The compiler may catch at compiling *.mod.c like

Re: [PATCH] modpost: abort if a module symbol is too long

Takashi Iwai writes: > Module symbols have a limited length, but currently the build system > allows the build finishing even if the driver code contains a too long > symbol name, which eventually overflows the modversion_info[] item. > The compiler may catch at compiling *.mod.c like > CC

Re: [PATCH] modpost: abort if a module symbol is too long

Takashi Iwai ti...@suse.de writes: Module symbols have a limited length, but currently the build system allows the build finishing even if the driver code contains a too long symbol name, which eventually overflows the modversion_info[] item. The compiler may catch at compiling *.mod.c like

[tip:x86/apic] x86/lguest: Clean up lguest_setup_irq

Commit-ID: 27a6f41c1a20a3339f456647a21e45fca5b82b62 Gitweb: http://git.kernel.org/tip/27a6f41c1a20a3339f456647a21e45fca5b82b62 Author: Rusty Russell AuthorDate: Tue, 4 Aug 2015 14:02:55 +0930 Committer: Thomas Gleixner CommitDate: Thu, 6 Aug 2015 00:14:58 +0200 x86/lguest: Clean up

[tip:x86/apic] x86/lguest: Clean up lguest_setup_irq

Commit-ID: 27a6f41c1a20a3339f456647a21e45fca5b82b62 Gitweb: http://git.kernel.org/tip/27a6f41c1a20a3339f456647a21e45fca5b82b62 Author: Rusty Russell ru...@rustcorp.com.au AuthorDate: Tue, 4 Aug 2015 14:02:55 +0930 Committer: Thomas Gleixner t...@linutronix.de CommitDate: Thu, 6 Aug 2015

[PATCH 1/2] x86/lguest: clean up lguest_setup_irq.

We make it static and hoist it higher in the file for the next patch. We also give a nice panic if it fails during boot. Signed-off-by: Rusty Russell --- arch/x86/lguest/boot.c | 43 ++- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/arch

[PATCH 2/2] x86/lguest: Do not setup unused irq vectors

From: Thomas Gleixner No point in assigning the interrupt vectors if there is no interrupt chip installed. Move it to lguest_setup_irq(). (And call it from lguest_enable_irq). Signed-off-by: Thomas Gleixner Signed-off-by: Rusty Russell (fixed typo) Signed-off-by: Rusty Russell --- arch/x86

Re: [patch 2/7] x86/lguest: Do not setup unused irq vectors

Thomas Gleixner writes: > On Mon, 3 Aug 2015, Rusty Russell wrote: >> Thomas Gleixner writes: >> > + >> > + /* Some systems map "vectors" to interrupts weirdly. Not us! */ >> > + __this_cpu_write(vector_irq[FIRST_EXTERNAL_VECTOR + irq, irq);

[PATCH 1/2] x86/lguest: clean up lguest_setup_irq.

We make it static and hoist it higher in the file for the next patch. We also give a nice panic if it fails during boot. Signed-off-by: Rusty Russell ru...@rustcorp.com.au --- arch/x86/lguest/boot.c | 43 ++- 1 file changed, 22 insertions(+), 21 deletions

<    1   2   3   4   5   6   7   8   9   10   >