Re: linux-next: tracebacks in workqueue.c/__flush_work()

Tetsuo Handa writes: > (Adding Chris Metcalf and Rusty Russell.) > > If NR_CPUS == 1 due to CONFIG_SMP=n, for_each_cpu(cpu, _work) loop does > not > evaluate "struct cpumask has_work" modified by cpumask_set_cpu(cpu, > _work) at > previous for_each_online_

Re: [PATCH][RFC] module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity

Thanks taking on such a thankless task Thomas, Might have been overzealous in assuming a verionless GPL string meant "or later" (I'm happy for that for my own code, FWIW). My memory is fuzzy, but I don't think anyone cared at the time. Frankly, this should be autogenerated rather than "fixed"

Re: [PATCH] modpost: remove leftover symbol prefix handling for module device table

Please send this to the module maintainer (CC'd). Masahiro Yamada writes: > Blackfin and metag were the only architectures that prefix symbols with > an underscore. They were removed by commit 4ba66a976072 ("arch: remove > blackfin port"), commit bb6fb6dfcc17 ("metag: Remove arch/metag/"), >

Re: [PATCH] modpost: remove leftover symbol prefix handling for module device table

Please send this to the module maintainer (CC'd). Masahiro Yamada writes: > Blackfin and metag were the only architectures that prefix symbols with > an underscore. They were removed by commit 4ba66a976072 ("arch: remove > blackfin port"), commit bb6fb6dfcc17 ("metag: Remove arch/metag/"), >

Re: [PATCH] maintainers: drop Chris Wright from pvops

:Documentation/parport*.txt > > PARAVIRT_OPS INTERFACE > M: Juergen Gross <jgr...@suse.com> > -M: Chris Wright <chr...@sous-sol.org> > M: Alok Kataria <akata...@vmware.com> > M: Rusty Russell <ru...@rustcorp.com.au> > L: virtualizat...@lists.linux-foundation.org > -- > 2.12.3

Re: [PATCH] maintainers: drop Chris Wright from pvops

PARAVIRT_OPS INTERFACE > M: Juergen Gross > -M: Chris Wright > M: Alok Kataria > M: Rusty Russell > L: virtualizat...@lists.linux-foundation.org > -- > 2.12.3

Re: [PATCH] params: Align add_sysfs_param documentation with code

Jean Delvare <jdelv...@suse.de> writes: > This parameter is named kp, so the documentation should use that. > > Signed-off-by: Jean Delvare <jdelv...@suse.de> > Fixes: 9b473de87209 ("param: Fix duplicate module prefixes") > Cc: Rusty Russell <ru...@rustc

Re: [PATCH] params: Align add_sysfs_param documentation with code

Jean Delvare writes: > This parameter is named kp, so the documentation should use that. > > Signed-off-by: Jean Delvare > Fixes: 9b473de87209 ("param: Fix duplicate module prefixes") > Cc: Rusty Russell Acked-by: Rusty Russell Thanks, Rusty. > --- > kern

Re: [PATCH v2 0/2] x86: paravirt related cleanup

tended for it to be removed with the paravirt infrastructure itself, but I think that's getting closer anyway. Acked-by: Rusty Russell <ru...@rustcorp.com.au> > In case the patches make it to the tree there is quite some potential > for further simplification of paravirt stuff. Especially most

Re: [PATCH v2 0/2] x86: paravirt related cleanup

ved with the paravirt infrastructure itself, but I think that's getting closer anyway. Acked-by: Rusty Russell > In case the patches make it to the tree there is quite some potential > for further simplification of paravirt stuff. Especially most of the > pv operations can be put under the CONFI

[PATCH] MAINTAINERS: Remove from module & paravirt maintenance

finally takes a long! Seriously... [8] Though the ARRAY_SIZE macro and the poetry in lguest are a close second. [9] Actually, bitcoin is a nice reward too; it's like crystalized machine sweat! Signed-off-by: Rusty Russell <ru...@rustcorp.com.au> --- MAINTAINERS | 2 -- 1 file changed,

[PATCH] MAINTAINERS: Remove from module & paravirt maintenance

finally takes a long! Seriously... [8] Though the ARRAY_SIZE macro and the poetry in lguest are a close second. [9] Actually, bitcoin is a nice reward too; it's like crystalized machine sweat! Signed-off-by: Rusty Russell --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff -

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

Matthew Garrett <mj...@google.com> writes: > On Sun, Aug 6, 2017 at 7:49 PM, Rusty Russell <ru...@rustcorp.com.au> wrote: >> Matthew Garrett <mj...@google.com> writes: >>> Binary modules will still be tainted by the license checker. The issue >>> is

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

Matthew Garrett writes: > On Sun, Aug 6, 2017 at 7:49 PM, Rusty Russell wrote: >> Matthew Garrett writes: >>> Binary modules will still be tainted by the license checker. The issue >>> is that if you want to enforce module signatures under *some* >>&

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

Matthew Garrett <mj...@google.com> writes: > On Sat, Aug 5, 2017 at 11:54 PM, Rusty Russell <ru...@rustcorp.com.au> wrote: >> Matthew Garrett <mj...@google.com> writes: >>> Distributions may wish to provide kernels that permit loading of >>> unsig

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

Matthew Garrett writes: > On Sat, Aug 5, 2017 at 11:54 PM, Rusty Russell wrote: >> Matthew Garrett writes: >>> Distributions may wish to provide kernels that permit loading of >>> unsigned modules based on certain policy decisions. >> >> Sorry, th

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

Matthew Garrett writes: > Distributions may wish to provide kernels that permit loading of > unsigned modules based on certain policy decisions. Sorry, that's way too vague to accept this patch. So I'm guessing a binary module is behind this vagueness. If you want some other

Re: [PATCH] Allow automatic kernel taint on unsigned module load to be disabled

Matthew Garrett writes: > Distributions may wish to provide kernels that permit loading of > unsigned modules based on certain policy decisions. Sorry, that's way too vague to accept this patch. So I'm guessing a binary module is behind this vagueness. If you want some other method than

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

Wanlong Gao writes: > Folks, > > Any comments? I've CC'd the module maintainer, who can help with this :_ Cheers, Rusty. > On 2017/5/20 15:46, Xie XiuQi wrote: >> From: Wanlong Gao >> >> Module name has a limited length, but currently the build

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

Wanlong Gao writes: > Folks, > > Any comments? I've CC'd the module maintainer, who can help with this :_ Cheers, Rusty. > On 2017/5/20 15:46, Xie XiuQi wrote: >> From: Wanlong Gao >> >> Module name has a limited length, but currently the build system >> allows the build finishing even if

Re: [PATCH RFC 0/3] Improve stability of system clock

John Stultz writes: > On Wed, May 17, 2017 at 9:54 PM, Richard Cochran > wrote: >> On Wed, May 17, 2017 at 04:06:07PM -0700, John Stultz wrote: >>> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar >>> wrote: >>> > Is

Re: [PATCH RFC 0/3] Improve stability of system clock

John Stultz writes: > On Wed, May 17, 2017 at 9:54 PM, Richard Cochran > wrote: >> On Wed, May 17, 2017 at 04:06:07PM -0700, John Stultz wrote: >>> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar >>> wrote: >>> > Is there a better way to run the timekeeping code in an userspace >>> >

Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction

Djalal Harouni <tix...@gmail.com> writes: > Hi Rusty, > > On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell <ru...@rustcorp.com.au> wrote: >> Djalal Harouni <tix...@gmail.com> writes: >>> When value is (1), task must have CAP_SYS_MODULE to be able t

Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction

Djalal Harouni writes: > Hi Rusty, > > On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell wrote: >> Djalal Harouni writes: >>> When value is (1), task must have CAP_SYS_MODULE to be able to trigger a >>> module auto-load operation, or CAP_NET_ADMIN for mod

Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction

Djalal Harouni writes: > When value is (1), task must have CAP_SYS_MODULE to be able to trigger a > module auto-load operation, or CAP_NET_ADMIN for modules with a > 'netdev-%s' alias. Sorry, the magic 'netdev-' prefix is a crawling horror. To do this properly, you need to

Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction

Djalal Harouni writes: > When value is (1), task must have CAP_SYS_MODULE to be able to trigger a > module auto-load operation, or CAP_NET_ADMIN for modules with a > 'netdev-%s' alias. Sorry, the magic 'netdev-' prefix is a crawling horror. To do this properly, you need to hand the capability

Re: [PATCH] x86/lguest/timer: set ->min_delta_ticks and ->max_delta_ticks

ents core still looks exclusively at the (untouched) ->min_delta_ns > and ->max_delta_ns. As soon as this has changed, a followup patch will > purge the initialization of ->min_delta_ns and ->max_delta_ns from this > driver. Acked-by: Rusty Russell <ru...@rustcorp.com.a

Re: [PATCH] x86/lguest/timer: set ->min_delta_ticks and ->max_delta_ticks

exclusively at the (untouched) ->min_delta_ns > and ->max_delta_ns. As soon as this has changed, a followup patch will > purge the initialization of ->min_delta_ns and ->max_delta_ns from this > driver. Acked-by: Rusty Russell > > Signed-off-by: Nicolai Stange > --- >

Re: [PATCH] module: fix memory leak on early load_module() failures

le processing kernel parameters > (parse_args() returns an error) > o mod_sysfs_setup() fails > o we're a live patch module and copy_module_elf() fails > > Chances of running into this issue is really low. Good catch! Reviewed-by: Rusty Russell <ru...@rustcorp.com.au> Cheers,

Re: [PATCH] module: fix memory leak on early load_module() failures

t; (parse_args() returns an error) > o mod_sysfs_setup() fails > o we're a live patch module and copy_module_elf() fails > > Chances of running into this issue is really low. Good catch! Reviewed-by: Rusty Russell Cheers, Rusty. > > kmemleak splat: > > unrefe

Re: [PATCH] cpumask: add cpumask_any_and_but()

Mark Rutland <mark.rutl...@arm.com> writes: > In some cases, it's useful to be able to select a random cpu from the > intersection of two masks, excluding a particular CPU. Acked-by: Rusty Russell <ru...@rustcorp.com.au> Thanks, Rusty. > For example, in some systems an

Re: [PATCH] cpumask: add cpumask_any_and_but()

Mark Rutland writes: > In some cases, it's useful to be able to select a random cpu from the > intersection of two masks, excluding a particular CPU. Acked-by: Rusty Russell Thanks, Rusty. > For example, in some systems an uncore PMU is shared by a subset of > CPUs, and management

Re: [PATCH] modules: mark __inittest/__exittest as __maybe_unused

Arnd Bergmann <a...@arndb.de> writes: > On Thu, Feb 2, 2017 at 10:25 AM, Rusty Russell <ru...@rustcorp.com.au> wrote: >> Arnd Bergmann <a...@arndb.de> writes: >>> clang warns about unused inline functions by default: >>> >>> arch/arm/c

Re: [PATCH] modules: mark __inittest/__exittest as __maybe_unused

Arnd Bergmann writes: > On Thu, Feb 2, 2017 at 10:25 AM, Rusty Russell wrote: >> Arnd Bergmann writes: >>> clang warns about unused inline functions by default: >>> >>> arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function >>> '__inittest

Re: [PATCH] modules: mark __inittest/__exittest as __maybe_unused

Arnd Bergmann writes: > clang warns about unused inline functions by default: > > arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest' > [-Wunused-function] > arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest' >

Re: [PATCH] modules: mark __inittest/__exittest as __maybe_unused

Arnd Bergmann writes: > clang warns about unused inline functions by default: > > arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest' > [-Wunused-function] > arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest' > [-Wunused-function] > > As

Re: [RFC] [PATCH] audit: log module name on init_module

Hi RGB! This should get acked by the new module maintainer (and your RH peer!) Jeyu, cc'd. Cheers, Rusty. Richard Guy Briggs writes: > This adds a new auxiliary record MODULE_INIT to the SYSCALL event. > > We get finit_module for free since it made most sense

Re: [RFC] [PATCH] audit: log module name on init_module

Hi RGB! This should get acked by the new module maintainer (and your RH peer!) Jeyu, cc'd. Cheers, Rusty. Richard Guy Briggs writes: > This adds a new auxiliary record MODULE_INIT to the SYSCALL event. > > We get finit_module for free since it made most sense to hook this in to

Re: [PATCH v2 00/10] Finalize separation of extable.h from module.h

BTW, you missed Jeyu, the current module maintainer. Not that we care, I think, it's pretty trivial: Acked-by: Rusty Russell <ru...@rustcorp.com.au> (module.h parts) Cheers, Rusty. Paul Gortmaker <paul.gortma...@windriver.com> writes: > Some of the arch specific changes ha

Re: [PATCH v2 00/10] Finalize separation of extable.h from module.h

BTW, you missed Jeyu, the current module maintainer. Not that we care, I think, it's pretty trivial: Acked-by: Rusty Russell (module.h parts) Cheers, Rusty. Paul Gortmaker writes: > Some of the arch specific changes have already been picked up by the > arch maintainers in v1, so I'm as

Re: [RFC] taint/module: Fix problems when out-of-kernel driver defines true or false

; such as VirtualBox include their own definitions of true and false. > > Fixes: 7fd8329ba502 ("taint/module: Clean up global and module taint flags > handling") > Signed-off-by: Larry Finger <larry.fin...@lwfinger.net> > Cc: Petr Mladek <pmla...@suse.c

Re: [RFC] taint/module: Fix problems when out-of-kernel driver defines true or false

wn definitions of true and false. > > Fixes: 7fd8329ba502 ("taint/module: Clean up global and module taint flags > handling") > Signed-off-by: Larry Finger > Cc: Petr Mladek > Cc: Jessica Yu > Cc: Rusty Russell Acked-by: Rusty Russell Thanks, Rusty. > -

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: >> Maybe a similar hack for try_then_request_module(), but many places seem >> to open-code request_module() so it's not as trivial... Hi Luis, Jessica (who is the main module maintainer now), Back from break, sorry about delay. > Right,

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: >> Maybe a similar hack for try_then_request_module(), but many places seem >> to open-code request_module() so it's not as trivial... Hi Luis, Jessica (who is the main module maintainer now), Back from break, sorry about delay. > Right, out of ~350

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: > OK -- if userspace messes up again it may be a bit hard to prove > unless we have a validation debug thing in place, would such a thing > in debug form be reasonable ? That makes perfect sense. Untested hack: diff --git a/fs/filesystems.c

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: > OK -- if userspace messes up again it may be a bit hard to prove > unless we have a validation debug thing in place, would such a thing > in debug form be reasonable ? That makes perfect sense. Untested hack: diff --git a/fs/filesystems.c b/fs/filesystems.c index

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" <mcg...@kernel.org> writes: > On Dec 16, 2016 9:54 PM, "Rusty Russell" <ru...@rustcorp.com.au> wrote: > > AFAICT the mistake here is that kmod is returning "done, OK" when the > > module it is trying to load is already

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: > On Dec 16, 2016 9:54 PM, "Rusty Russell" wrote: > > AFAICT the mistake here is that kmod is returning "done, OK" when the > > module it is trying to load is already loading (but not finished > > loading). That'

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" <mcg...@kernel.org> writes: > On Thu, Dec 15, 2016 at 10:57:42AM +1030, Rusty Russell wrote: >> "Luis R. Rodriguez" <mcg...@kernel.org> writes: >> > kmod has an optimization in place whereby if a some kernel code >> >

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: > On Thu, Dec 15, 2016 at 10:57:42AM +1030, Rusty Russell wrote: >> "Luis R. Rodriguez" writes: >> > kmod has an optimization in place whereby if a some kernel code >> > uses request_module() on a module already load

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: > kmod has an optimization in place whereby if a some kernel code > uses request_module() on a module already loaded we never bother > userspace as the module already is loaded. This is not true for > get_fs_type() though as it uses aliases. Well,

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: > kmod has an optimization in place whereby if a some kernel code > uses request_module() on a module already loaded we never bother > userspace as the module already is loaded. This is not true for > get_fs_type() though as it uses aliases. Well, the obvious thing to

Re: module: extend 'rodata=off' boot cmdline parameter to module mappings

gt; >>Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org> >>Reviewed-by: Kees Cook <keesc...@chromium.org> >>Cc: Rusty Russell <ru...@rustcorp.com.au> > > Hi Rusty, could I get an (n)ack for this patch? :-) Acked-by: Rusty Russell <ru...@rustcorp.com.au> Cheers, Rusty.

Re: module: extend 'rodata=off' boot cmdline parameter to module mappings

O/RW >>permissions, keeping NX set. >> >>This is the first step to make CONFIG_DEBUG_SET_MODULE_RONX mandatory >>(always-on) in the future as CONFIG_DEBUG_RODATA on x86 and arm64. >> >>Suggested-by: and Acked-by: Mark Rutland >>Signed-off-by: AKASHI Takahiro >&g

Re: [RFC PATCH v2 2/2] module: When modifying a module's text ignore modules which are going away too

the module should be RW, before deallocation. > > This patch makes set_all_modules_text_ro() skip modules which are going > away too. > > Signed-off-by: Aaron Tomlin <atom...@redhat.com> Acked-by: Rusty Russell <ru...@rustcorp.com.au> Thanks! Rusty. > --- > kern

Re: [RFC PATCH v2 2/2] module: When modifying a module's text ignore modules which are going away too

e RW, before deallocation. > > This patch makes set_all_modules_text_ro() skip modules which are going > away too. > > Signed-off-by: Aaron Tomlin Acked-by: Rusty Russell Thanks! Rusty. > --- > kernel/module.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >

Re: [PATCH -RFC] moduleparam: introduce core_param_named macro for non-modular code

Paul Gortmaker writes: > We have the case where module_param_named() in file "foo.c" for > parameter myparam translates that into the bootarg for the > non-modular use case as "foo.myparam=..." > > The problem exists where the use case with the filename and the > dot

Re: [PATCH -RFC] moduleparam: introduce core_param_named macro for non-modular code

Paul Gortmaker writes: > We have the case where module_param_named() in file "foo.c" for > parameter myparam translates that into the bootarg for the > non-modular use case as "foo.myparam=..." > > The problem exists where the use case with the filename and the > dot prefix is established, but

Re: [PULL] modules: begin maintainer transition

Linus Torvalds <torva...@linux-foundation.org> writes: > On Tue, Oct 25, 2016 at 4:46 PM, Rusty Russell <ru...@rustcorp.com.au> wrote: >> >> Rusty Russell (1): >> MAINTAINERS: Begin module maintainer transition > > Jessica, do you have a pgp key? And

Re: [PULL] modules: begin maintainer transition

Linus Torvalds writes: > On Tue, Oct 25, 2016 at 4:46 PM, Rusty Russell wrote: >> >> Rusty Russell (1): >> MAINTAINERS: Begin module maintainer transition > > Jessica, do you have a pgp key? And Rusty, have you signed it? That > makes the whole "pull si

Re: taint/module: Clean up global and module taint flags handling

Jiri Kosina writes: > On Fri, 23 Sep 2016, Jessica Yu wrote: > >> Hm, quick question, which tree would this patch go to? Though the >> cleanup is for modules, there is an indirect cross-tree dependency >> (taint_flag.module needs to be true for TAINT_LIVEPATCH for Josh's >>

Re: taint/module: Clean up global and module taint flags handling

Jiri Kosina writes: > On Fri, 23 Sep 2016, Jessica Yu wrote: > >> Hm, quick question, which tree would this patch go to? Though the >> cleanup is for modules, there is an indirect cross-tree dependency >> (taint_flag.module needs to be true for TAINT_LIVEPATCH for Josh's >> patch to still work as

Re: [RFC PATCH 1/2] module: Ensure a module's state is set accordingly during module coming cleanup code

t mod->state; they seem OK. We actually do this in the init-failed path, so this should be OK. Acked-by: Rusty Russell <ru...@rustcorp.com.au> Thanks, Rusty. > Signed-off-by: Aaron Tomlin <atom...@redhat.com> > --- > kernel/module.c | 1 + > 1 file changed, 1 inse

Re: [RFC PATCH 1/2] module: Ensure a module's state is set accordingly during module coming cleanup code

OK. We actually do this in the init-failed path, so this should be OK. Acked-by: Rusty Russell Thanks, Rusty. > Signed-off-by: Aaron Tomlin > --- > kernel/module.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/module.c b/kernel/module.c > index f57d

Re: [RFC PATCH 2/2] module: When modifying a module's text ignore modules which are going away too

Aaron Tomlin writes: > By default, during the access permission modification of a module's core > and init pages, we only ignore modules that are malformed. There is no > reason not to extend this to modules which are going away too. Well, it depends on all the callers (ie.

Re: [RFC PATCH 2/2] module: When modifying a module's text ignore modules which are going away too

Aaron Tomlin writes: > By default, during the access permission modification of a module's core > and init pages, we only ignore modules that are malformed. There is no > reason not to extend this to modules which are going away too. Well, it depends on all the callers (ie. ftrace): is that also

Re: [PATCH v2] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs

heu...@linaro.org> This looks good! Thanks for this, it fixes a nasty wart with the relocation of crcs. If the ppc and arm maintainers are happy, I'm happy for Jessica to take it into her module tree. Acked-by: Rusty Russell <ru...@rustcorp.com.au> Thanks, Rusty. > --- > v2: drop

Re: [PATCH v2] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs

nasty wart with the relocation of crcs. If the ppc and arm maintainers are happy, I'm happy for Jessica to take it into her module tree. Acked-by: Rusty Russell Thanks, Rusty. > --- > v2: drop the change to struct modversion_info: it affects the layout of the > __versions sect

Re: [kernel-hardening] [PATCH] module: extend 'rodata=off' boot cmdline parameter to module mappings

by Kees); please CC the followup version to Jessica as new module maintainer. Thanks! Rusty. >> > >> > This is the first step to make CONFIG_DEBUG_SET_MODULE_RONX mandatory >> > (always-on) in the future as CONFIG_DEBUG_RODATA on x86 and arm64. >> > &

Re: [kernel-hardening] [PATCH] module: extend 'rodata=off' boot cmdline parameter to module mappings

module maintainer. Thanks! Rusty. >> > >> > This is the first step to make CONFIG_DEBUG_SET_MODULE_RONX mandatory >> > (always-on) in the future as CONFIG_DEBUG_RODATA on x86 and arm64. >> > >> > Suggested-by: Mark Rutland >> > Signed-off-by: AKASHI

[PULL] modules: begin maintainer transition

want your patches applied. She rocks, and is far more timely than me too! Cheers, Rusty. Rusty Russell (1): MAINTAINERS: Begin module maintainer transition MAINTAINERS | 1 + 1 file changed, 1 insertion(+)

[PULL] modules: begin maintainer transition

want your patches applied. She rocks, and is far more timely than me too! Cheers, Rusty. Rusty Russell (1): MAINTAINERS: Begin module maintainer transition MAINTAINERS | 1 + 1 file changed, 1 insertion(+)

Re: module/taint: Automatically increase the buffer size for new taint flags

Jessica Yu writes: > I liked the enum idea because we got TAINT_FLAGS_COUNT for free :-) > however I think we need to switch back to the #defines because of the kbuild > error. > > The "Error: invalid operands...for `<<'" messages are related to the > __WARN_TAINT() macro

Re: module/taint: Automatically increase the buffer size for new taint flags

Jessica Yu writes: > I liked the enum idea because we got TAINT_FLAGS_COUNT for free :-) > however I think we need to switch back to the #defines because of the kbuild > error. > > The "Error: invalid operands...for `<<'" messages are related to the > __WARN_TAINT() macro

Re: [PATCH] module/taint: Automatically increase the buffer size for new taint flags

Petr Mladek writes: > The commit 66cc69e34e86a231 ("Fix: module signature vs tracepoints: > add new TAINT_UNSIGNED_MODULE") updated module_taint_flags() to > potentially print one more character. But it did not increase the > size of the corresponding buffers in m_show() and

Re: [PATCH] module/taint: Automatically increase the buffer size for new taint flags

Petr Mladek writes: > The commit 66cc69e34e86a231 ("Fix: module signature vs tracepoints: > add new TAINT_UNSIGNED_MODULE") updated module_taint_flags() to > potentially print one more character. But it did not increase the > size of the corresponding buffers in m_show() and print_modules(). I

Re: [PATCH] tools/lguest: Don't bork the terminal in case of wrong args

Daniel Baluta writes: > On Tue, Dec 8, 2015 at 4:35 PM, Daniel Baluta wrote: >> Running lguest without arguments or with a wrong argument name >> borks the terminal, because the cleanup handler is set up too late >> in the initialization process.

Re: [PATCH] tools/lguest: Don't bork the terminal in case of wrong args

Daniel Baluta writes: > On Tue, Dec 8, 2015 at 4:35 PM, Daniel Baluta wrote: >> Running lguest without arguments or with a wrong argument name >> borks the terminal, because the cleanup handler is set up too late >> in the initialization process. >> >> Signed-off-by: Daniel Baluta > > Hi Rusty,

Re: [PATCH] livepatch/module: make TAINT_LIVEPATCH module-specific

it through livepatching.git? > Alternatively, if you prefer to merge this through your tree, please feel > free to add Happy to leave it to you :) Acked-by: Rusty Russell <ru...@rustcorp.com.au> Thanks, Rusty.

Re: [PATCH] livepatch/module: make TAINT_LIVEPATCH module-specific

gt; >> Reviewed-by: Chunyu Hu >> Signed-off-by: Josh Poimboeuf > > I like this change. > > Rusty, in case you're okay with it as well, could you please either > provide your Ack so that I could take it through livepatching.git? > Alternatively, if you prefer to merge this th

Re: [PULL] modules-next

Rusty Russell <ru...@rustcorp.com.au> writes: > Linus Torvalds <torva...@linux-foundation.org> writes: >> So this feels wrong to me, can you guys please explain: ... >> I didn't actually pull the tree, I just reacted to the pull request itself. ... > I can pull the

Re: [PULL] modules-next

Rusty Russell writes: > Linus Torvalds writes: >> So this feels wrong to me, can you guys please explain: ... >> I didn't actually pull the tree, I just reacted to the pull request itself. ... > I can pull them out of modules-next if you'd prefer. OK, removed that patch.

Re: [PATCH 0309/1285] Replace numeric parameter like 0444 with macro

Baole Ni writes: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro, > and that using

Re: [PATCH 0309/1285] Replace numeric parameter like 0444 with macro

Baole Ni writes: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro, > and that using macro can improve the

Re: [PULL] modules-next

Linus Torvalds <torva...@linux-foundation.org> writes: > So this feels wrong to me, can you guys please explain: > > On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell <ru...@rustcorp.com.au> wrote: >> >> Ben Hutchings (3): >> module: Invalidate signatures

Re: [PULL] modules-next

Linus Torvalds writes: > So this feels wrong to me, can you guys please explain: > > On Sun, Jul 31, 2016 at 9:02 PM, Rusty Russell wrote: >> >> Ben Hutchings (3): >> module: Invalidate signatures on force-loaded modules >> module: Disable MODULE

[PULL] modules-next

rnel Paul Gortmaker (2): exceptions: fork exception table content from module.h into extable.h extable.h: add stddef.h so "NULL" definition is not implicit Prarit Bhargava (1): modules: Add kernel parameter to blacklist modules Rusty Russell (2): module

[PULL] modules-next

rnel Paul Gortmaker (2): exceptions: fork exception table content from module.h into extable.h extable.h: add stddef.h so "NULL" definition is not implicit Prarit Bhargava (1): modules: Add kernel parameter to blacklist modules Rusty Russell (2): module

Re: [PATCH] sched/core: add taint on "BUG: sleeping function called from invalid context"

Vegard Nossum writes: > Seeing this, it occurs to me that we should probably add a taint here: Taint has traditionally meant "the user did something unsupported, take the bug report with a grain of salt". Such as force removing a module. So this seems wrong...

Re: [PATCH] sched/core: add taint on "BUG: sleeping function called from invalid context"

Vegard Nossum writes: > Seeing this, it occurs to me that we should probably add a taint here: Taint has traditionally meant "the user did something unsupported, take the bug report with a grain of salt". Such as force removing a module. So this seems wrong... Cheers, Rusty. > > BUG:

Re: [PATCH] extable.h: add stddef.h so "NULL" definition is not implicit

't a regression, since currently extable.h is > only used by module.h -- however, we will need this addition present > before we start migrating exception table users off module.h and onto > extable.h during the next release cycle. > > Cc: Rusty Russell <ru...@rustcorp

Re: [PATCH] extable.h: add stddef.h so "NULL" definition is not implicit

le.h is > only used by module.h -- however, we will need this addition present > before we start migrating exception table users off module.h and onto > extable.h during the next release cycle. > > Cc: Rusty Russell > Signed-off-by: Paul Gortmaker > --- > > [Was n

Re: [PATCH 01/14] exceptions: fork exception table content from module.h into extable.h

the core > files that only need exception table stuff don't have an include > of module.h that brings in lots of extra stuff and just looks > generally out of place. > > Cc: Rusty Russell <ru...@rustcorp.com.au> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc:

Re: [PATCH 01/14] exceptions: fork exception table content from module.h into extable.h

tion table stuff don't have an include > of module.h that brings in lots of extra stuff and just looks > generally out of place. > > Cc: Rusty Russell > Cc: Andrew Morton > Cc: Linus Torvalds > Signed-off-by: Paul Gortmaker > --- > include/linux/extable.h | 30 ++

Re: [PATCH v5] Add kernel parameter to blacklist modules

Prarit Bhargava writes: > Rusty, this looks like it will work. I tested this by adding Applied. Hey, we got there in the end! Thanks for your patience, Rusty.

Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible

Greg KH writes: >> Adding a license here implies we accept that it's actually GPLv2 >> compatible. And IANAL. > > Note, at least lawyer has signed off on this. > > I'd like to see Richard do so as well. Sure, but as I said before I'm not applying it until we have

Re: [PATCH v5] Add kernel parameter to blacklist modules

Prarit Bhargava writes: > Rusty, this looks like it will work. I tested this by adding Applied. Hey, we got there in the end! Thanks for your patience, Rusty.

Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible

Greg KH writes: >> Adding a license here implies we accept that it's actually GPLv2 >> compatible. And IANAL. > > Note, at least lawyer has signed off on this. > > I'd like to see Richard do so as well. Sure, but as I said before I'm not applying it until we have accepted in-tree code which

Re: [PATCH -next] module: use kmemdup rather than duplicating its implementation

weiyj...@163.com writes: > From: Wei Yongjun > > Use kmemdup rather than duplicating its implementation. > > Generated by: scripts/coccinelle/api/memdup.cocci > > Signed-off-by: Wei Yongjun Hi Wei! This code has been removed

Re: [PATCH -next] module: use kmemdup rather than duplicating its implementation

weiyj...@163.com writes: > From: Wei Yongjun > > Use kmemdup rather than duplicating its implementation. > > Generated by: scripts/coccinelle/api/memdup.cocci > > Signed-off-by: Wei Yongjun Hi Wei! This code has been removed by other changes in modules-next, so your very nice cleanup

  1   2   3   4   5   6   7   8   9   10   >