Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1292923 > unrolled thread

Re: [RFC PATCH v2 3/6] module: s390: keep mod_arch_specific for livepatch modules

Started byMiroslav Benes <mbenes@suse.cz>
First post2015-12-16 13:10 +0100
Last post2015-12-17 12:40 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RFC PATCH v2 3/6] module: s390: keep mod_arch_specific for  livepatch modules Miroslav Benes <mbenes@suse.cz> - 2015-12-16 13:10 +0100
    Re: module: s390: keep mod_arch_specific for livepatch modules Jessica Yu <jeyu@redhat.com> - 2015-12-17 00:50 +0100
      Re: module: s390: keep mod_arch_specific for livepatch modules Miroslav Benes <mbenes@suse.cz> - 2015-12-17 12:40 +0100

#1292923 — Re: [RFC PATCH v2 3/6] module: s390: keep mod_arch_specific for livepatch modules

FromMiroslav Benes <mbenes@suse.cz>
Date2015-12-16 13:10 +0100
SubjectRe: [RFC PATCH v2 3/6] module: s390: keep mod_arch_specific for livepatch modules
Message-ID<qGj45-1Aw-21@gated-at.bofh.it>
On Mon, 30 Nov 2015, Jessica Yu wrote:

> Livepatch needs to utilize the symbol information contained in the
> mod_arch_specific struct in order to be able to call the s390
> apply_relocate_add() function to apply relocations. Remove the redundant
> vfree() in module_finalize() since module_arch_freeing_init() (which also frees
> said structures) is called in do_init_module(). Keep a reference to syminfo if
> the module is a livepatch module and free the structures in
> module_arch_cleanup(). If the module isn't a livepatch module, we free the
> structures in module_arch_freeing_init() as usual.
> 
> Signed-off-by: Jessica Yu <jeyu@redhat.com>
> ---
>  arch/s390/kernel/module.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/kernel/module.c b/arch/s390/kernel/module.c
> index 0c1a679..17a1979 100644
> --- a/arch/s390/kernel/module.c
> +++ b/arch/s390/kernel/module.c
> @@ -51,6 +51,9 @@ void *module_alloc(unsigned long size)
>  
>  void module_arch_freeing_init(struct module *mod)
>  {
> +	if (mod->klp)
> +		return;
> +
>  	vfree(mod->arch.syminfo);
>  	mod->arch.syminfo = NULL;
>  }

Hm, this is problematic. module_arch_freeing_init() is called from 
module_deallocate() and this is called in the error path in load_module(). 
So if there was an error during load_module() of livepatch module which 
led to free_modinfo label or behind mod->arch.syminfo would not be freed 
at all. module_arch_cleanup() is called earlier under 
free_arch_cleanup.

Miroslav

> @@ -420,12 +423,18 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
>  	return 0;
>  }
>  
> +void module_arch_cleanup(struct module *mod)
> +{
> +	if (mod->klp) {
> +		vfree(mod->arch.syminfo);
> +		mod->arch.syminfo = NULL;
> +	}
> +}
> +
>  int module_finalize(const Elf_Ehdr *hdr,
>  		    const Elf_Shdr *sechdrs,
>  		    struct module *me)
>  {
>  	jump_label_apply_nops(me);
> -	vfree(me->arch.syminfo);
> -	me->arch.syminfo = NULL;
>  	return 0;
>  }
> -- 
> 2.4.3
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1293400 — Re: module: s390: keep mod_arch_specific for livepatch modules

FromJessica Yu <jeyu@redhat.com>
Date2015-12-17 00:50 +0100
SubjectRe: module: s390: keep mod_arch_specific for livepatch modules
Message-ID<qGtZw-8qx-9@gated-at.bofh.it>
In reply to#1292923
+++ Miroslav Benes [16/12/15 13:02 +0100]:
>On Mon, 30 Nov 2015, Jessica Yu wrote:
>
>> Livepatch needs to utilize the symbol information contained in the
>> mod_arch_specific struct in order to be able to call the s390
>> apply_relocate_add() function to apply relocations. Remove the redundant
>> vfree() in module_finalize() since module_arch_freeing_init() (which also frees
>> said structures) is called in do_init_module(). Keep a reference to syminfo if
>> the module is a livepatch module and free the structures in
>> module_arch_cleanup(). If the module isn't a livepatch module, we free the
>> structures in module_arch_freeing_init() as usual.
>>
>> Signed-off-by: Jessica Yu <jeyu@redhat.com>
>> ---
>>  arch/s390/kernel/module.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/s390/kernel/module.c b/arch/s390/kernel/module.c
>> index 0c1a679..17a1979 100644
>> --- a/arch/s390/kernel/module.c
>> +++ b/arch/s390/kernel/module.c
>> @@ -51,6 +51,9 @@ void *module_alloc(unsigned long size)
>>
>>  void module_arch_freeing_init(struct module *mod)
>>  {
>> +	if (mod->klp)
>> +		return;
>> +
>>  	vfree(mod->arch.syminfo);
>>  	mod->arch.syminfo = NULL;
>>  }
>
>Hm, this is problematic. module_arch_freeing_init() is called from
>module_deallocate() and this is called in the error path in load_module().
>So if there was an error during load_module() of livepatch module which
>led to free_modinfo label or behind mod->arch.syminfo would not be freed
>at all. module_arch_cleanup() is called earlier under
>free_arch_cleanup.

Gah. Good catch. How about we add an additional check to see if
mod->state is MODULE_STATE_LIVE? If so, we can return. This means
we're coming from do_init_module(). If module_arch_freeing_init() was
called and the module was in a state other than MODULE_STATE_LIVE
(UNFORMED, GOING, COMING), we know we need to free. Think that would
work?

Jessica
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1293797 — Re: module: s390: keep mod_arch_specific for livepatch modules

FromMiroslav Benes <mbenes@suse.cz>
Date2015-12-17 12:40 +0100
SubjectRe: module: s390: keep mod_arch_specific for livepatch modules
Message-ID<qGF4B-7eB-9@gated-at.bofh.it>
In reply to#1293400
On Wed, 16 Dec 2015, Jessica Yu wrote:

> +++ Miroslav Benes [16/12/15 13:02 +0100]:
> > On Mon, 30 Nov 2015, Jessica Yu wrote:
> > 
> > > Livepatch needs to utilize the symbol information contained in the
> > > mod_arch_specific struct in order to be able to call the s390
> > > apply_relocate_add() function to apply relocations. Remove the redundant
> > > vfree() in module_finalize() since module_arch_freeing_init() (which also
> > > frees
> > > said structures) is called in do_init_module(). Keep a reference to
> > > syminfo if
> > > the module is a livepatch module and free the structures in
> > > module_arch_cleanup(). If the module isn't a livepatch module, we free the
> > > structures in module_arch_freeing_init() as usual.
> > > 
> > > Signed-off-by: Jessica Yu <jeyu@redhat.com>
> > > ---
> > >  arch/s390/kernel/module.c | 13 +++++++++++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/s390/kernel/module.c b/arch/s390/kernel/module.c
> > > index 0c1a679..17a1979 100644
> > > --- a/arch/s390/kernel/module.c
> > > +++ b/arch/s390/kernel/module.c
> > > @@ -51,6 +51,9 @@ void *module_alloc(unsigned long size)
> > > 
> > >  void module_arch_freeing_init(struct module *mod)
> > >  {
> > > +	if (mod->klp)
> > > +		return;
> > > +
> > >  	vfree(mod->arch.syminfo);
> > >  	mod->arch.syminfo = NULL;
> > >  }
> > 
> > Hm, this is problematic. module_arch_freeing_init() is called from
> > module_deallocate() and this is called in the error path in load_module().
> > So if there was an error during load_module() of livepatch module which
> > led to free_modinfo label or behind mod->arch.syminfo would not be freed
> > at all. module_arch_cleanup() is called earlier under
> > free_arch_cleanup.
> 
> Gah. Good catch. How about we add an additional check to see if
> mod->state is MODULE_STATE_LIVE? If so, we can return. This means
> we're coming from do_init_module(). If module_arch_freeing_init() was
> called and the module was in a state other than MODULE_STATE_LIVE
> (UNFORMED, GOING, COMING), we know we need to free. Think that would
> work?

It would I think. module_arch_freeing_init is called thrice.

1. in free_module(). The module is in UNFORMED state so everything is 
fine.

2. in module_deallocate(). The module is not LIVE yet here so ok as well.

3. in do_init_module() and the module is LIVE there.

So yes, you are right, that should work.

Miroslav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web