Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Sat, Feb 28, 2015 at 10:24:48PM +0100, Peter Zijlstra wrote:
> While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
> one must equally hold it over the use of the object returned.
>
> The moment you release the RCU-sched read lock, the object can be dead
> and gone.
>
> Cc: Seth Jennings
> Cc: Josh Poimboeuf
> Cc: Masami Hiramatsu
> Cc: Miroslav Benes
> Cc: Petr Mladek
> Cc: Jiri Kosina
> Cc: "Paul E. McKenney"
> Cc: Rusty Russell
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Josh Poimboeuf
> ---
> kernel/livepatch/core.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -248,11 +248,12 @@ static int klp_find_external_symbol(stru
> /* first, check if it's an exported symbol */
> preempt_disable();
> sym = find_symbol(name, NULL, NULL, true, true);
> - preempt_enable();
> if (sym) {
> *addr = sym->value;
> + preempt_enable();
> return 0;
> }
> + preempt_enable();
>
> /* otherwise check if it's in another .o within the patch module */
> return klp_find_object_symbol(pmod->name, name, addr);
>
>
--
Josh
--
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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Sat, Feb 28, 2015 at 10:24:48PM +0100, Peter Zijlstra wrote:
> While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
> one must equally hold it over the use of the object returned.
>
> The moment you release the RCU-sched read lock, the object can be dead
> and gone.
>
> Cc: Seth Jennings
> Cc: Josh Poimboeuf
> Cc: Masami Hiramatsu
> Cc: Miroslav Benes
> Cc: Petr Mladek
> Cc: Jiri Kosina
> Cc: "Paul E. McKenney"
> Cc: Rusty Russell
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Paul E. McKenney
> ---
> kernel/livepatch/core.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -248,11 +248,12 @@ static int klp_find_external_symbol(stru
> /* first, check if it's an exported symbol */
> preempt_disable();
> sym = find_symbol(name, NULL, NULL, true, true);
> - preempt_enable();
> if (sym) {
> *addr = sym->value;
> + preempt_enable();
> return 0;
> }
> + preempt_enable();
>
> /* otherwise check if it's in another .o within the patch module */
> return klp_find_object_symbol(pmod->name, name, addr);
>
>
--
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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Mon, Mar 02, 2015 at 10:13:05AM +0100, Jiri Kosina wrote: > On Mon, 2 Mar 2015, Peter Zijlstra wrote: > > That said; I do have a follow up question on that code. So now you've > > successfully obtained an address in module space; but the moment you > > release that RCU-sched lock, the module can be gone. > > > > How does the whole live patching stuff deal with module removal during > > patching? > > We have a module notifier that serializes using klp_mutex with the > patching. Do you see a problem there? Should work I think; might be worth noting this in a comment above this lookup though. -- 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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Mon 2015-03-02 09:35:30, Peter Zijlstra wrote: > On Sun, Mar 01, 2015 at 09:09:24PM +0100, Jiri Kosina wrote: > > On Sat, 28 Feb 2015, Peter Zijlstra wrote: > > > > > While one must hold RCU-sched (aka. preempt_disable) for find_symbol() > > > one must equally hold it over the use of the object returned. > > > > > > The moment you release the RCU-sched read lock, the object can be dead > > > and gone. > > > > > > Cc: Seth Jennings > > > Cc: Josh Poimboeuf > > > Cc: Masami Hiramatsu > > > Cc: Miroslav Benes > > > Cc: Petr Mladek > > > Cc: Jiri Kosina > > > Cc: "Paul E. McKenney" > > > Cc: Rusty Russell > > > Signed-off-by: Peter Zijlstra (Intel) > > > > Acked-by: Jiri Kosina > > > > I guess you'll be taking this together with the series, so I am not > > applying it. > > Feel free to take it; this series might take a wee while longer to > mature. > > That said; I do have a follow up question on that code. So now you've > successfully obtained an address in module space; but the moment you > release that RCU-sched lock, the module can be gone. > > How does the whole live patching stuff deal with module removal during > patching? There is a notifier, see klp_module_notify(). It applies existing patches when an affected module is loaded. Also it removes patches when an affected module is going. It is serialized with the other operations using the klp_mutex lock. Hmm, when I think about it. I am afraid that there is a race. For example, the going module might be unpatched by the notifier but a new patch might get applied when it is still visible by kallsyms. I am going to look at it. Best Regards, Petr -- 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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Mon, 2 Mar 2015, Peter Zijlstra wrote: > > Acked-by: Jiri Kosina > > > > I guess you'll be taking this together with the series, so I am not > > applying it. > > Feel free to take it; this series might take a wee while longer to > mature. OK, thanks. > That said; I do have a follow up question on that code. So now you've > successfully obtained an address in module space; but the moment you > release that RCU-sched lock, the module can be gone. > > How does the whole live patching stuff deal with module removal during > patching? We have a module notifier that serializes using klp_mutex with the patching. Do you see a problem there? Thanks, -- Jiri Kosina SUSE Labs -- 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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Sun, Mar 01, 2015 at 09:09:24PM +0100, Jiri Kosina wrote: > On Sat, 28 Feb 2015, Peter Zijlstra wrote: > > > While one must hold RCU-sched (aka. preempt_disable) for find_symbol() > > one must equally hold it over the use of the object returned. > > > > The moment you release the RCU-sched read lock, the object can be dead > > and gone. > > > > Cc: Seth Jennings > > Cc: Josh Poimboeuf > > Cc: Masami Hiramatsu > > Cc: Miroslav Benes > > Cc: Petr Mladek > > Cc: Jiri Kosina > > Cc: "Paul E. McKenney" > > Cc: Rusty Russell > > Signed-off-by: Peter Zijlstra (Intel) > > Acked-by: Jiri Kosina > > I guess you'll be taking this together with the series, so I am not > applying it. Feel free to take it; this series might take a wee while longer to mature. That said; I do have a follow up question on that code. So now you've successfully obtained an address in module space; but the moment you release that RCU-sched lock, the module can be gone. How does the whole live patching stuff deal with module removal during patching? -- 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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Sat, Feb 28, 2015 at 10:24:48PM +0100, Peter Zijlstra wrote:
While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
one must equally hold it over the use of the object returned.
The moment you release the RCU-sched read lock, the object can be dead
and gone.
Cc: Seth Jennings sjenn...@redhat.com
Cc: Josh Poimboeuf jpoim...@redhat.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Miroslav Benes mbe...@suse.cz
Cc: Petr Mladek pmla...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
Acked-by: Josh Poimboeuf jpoim...@redhat.com
---
kernel/livepatch/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -248,11 +248,12 @@ static int klp_find_external_symbol(stru
/* first, check if it's an exported symbol */
preempt_disable();
sym = find_symbol(name, NULL, NULL, true, true);
- preempt_enable();
if (sym) {
*addr = sym-value;
+ preempt_enable();
return 0;
}
+ preempt_enable();
/* otherwise check if it's in another .o within the patch module */
return klp_find_object_symbol(pmod-name, name, addr);
--
Josh
--
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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Mon, 2 Mar 2015, Peter Zijlstra wrote: Acked-by: Jiri Kosina jkos...@suse.cz I guess you'll be taking this together with the series, so I am not applying it. Feel free to take it; this series might take a wee while longer to mature. OK, thanks. That said; I do have a follow up question on that code. So now you've successfully obtained an address in module space; but the moment you release that RCU-sched lock, the module can be gone. How does the whole live patching stuff deal with module removal during patching? We have a module notifier that serializes using klp_mutex with the patching. Do you see a problem there? Thanks, -- Jiri Kosina SUSE Labs -- 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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Mon 2015-03-02 09:35:30, Peter Zijlstra wrote: On Sun, Mar 01, 2015 at 09:09:24PM +0100, Jiri Kosina wrote: On Sat, 28 Feb 2015, Peter Zijlstra wrote: While one must hold RCU-sched (aka. preempt_disable) for find_symbol() one must equally hold it over the use of the object returned. The moment you release the RCU-sched read lock, the object can be dead and gone. Cc: Seth Jennings sjenn...@redhat.com Cc: Josh Poimboeuf jpoim...@redhat.com Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com Cc: Miroslav Benes mbe...@suse.cz Cc: Petr Mladek pmla...@suse.cz Cc: Jiri Kosina jkos...@suse.cz Cc: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org Acked-by: Jiri Kosina jkos...@suse.cz I guess you'll be taking this together with the series, so I am not applying it. Feel free to take it; this series might take a wee while longer to mature. That said; I do have a follow up question on that code. So now you've successfully obtained an address in module space; but the moment you release that RCU-sched lock, the module can be gone. How does the whole live patching stuff deal with module removal during patching? There is a notifier, see klp_module_notify(). It applies existing patches when an affected module is loaded. Also it removes patches when an affected module is going. It is serialized with the other operations using the klp_mutex lock. Hmm, when I think about it. I am afraid that there is a race. For example, the going module might be unpatched by the notifier but a new patch might get applied when it is still visible by kallsyms. I am going to look at it. Best Regards, Petr -- 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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Sun, Mar 01, 2015 at 09:09:24PM +0100, Jiri Kosina wrote: On Sat, 28 Feb 2015, Peter Zijlstra wrote: While one must hold RCU-sched (aka. preempt_disable) for find_symbol() one must equally hold it over the use of the object returned. The moment you release the RCU-sched read lock, the object can be dead and gone. Cc: Seth Jennings sjenn...@redhat.com Cc: Josh Poimboeuf jpoim...@redhat.com Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com Cc: Miroslav Benes mbe...@suse.cz Cc: Petr Mladek pmla...@suse.cz Cc: Jiri Kosina jkos...@suse.cz Cc: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org Acked-by: Jiri Kosina jkos...@suse.cz I guess you'll be taking this together with the series, so I am not applying it. Feel free to take it; this series might take a wee while longer to mature. That said; I do have a follow up question on that code. So now you've successfully obtained an address in module space; but the moment you release that RCU-sched lock, the module can be gone. How does the whole live patching stuff deal with module removal during patching? -- 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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Mon, Mar 02, 2015 at 10:13:05AM +0100, Jiri Kosina wrote: On Mon, 2 Mar 2015, Peter Zijlstra wrote: That said; I do have a follow up question on that code. So now you've successfully obtained an address in module space; but the moment you release that RCU-sched lock, the module can be gone. How does the whole live patching stuff deal with module removal during patching? We have a module notifier that serializes using klp_mutex with the patching. Do you see a problem there? Should work I think; might be worth noting this in a comment above this lookup though. -- 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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Sat, Feb 28, 2015 at 10:24:48PM +0100, Peter Zijlstra wrote:
While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
one must equally hold it over the use of the object returned.
The moment you release the RCU-sched read lock, the object can be dead
and gone.
Cc: Seth Jennings sjenn...@redhat.com
Cc: Josh Poimboeuf jpoim...@redhat.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Miroslav Benes mbe...@suse.cz
Cc: Petr Mladek pmla...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
kernel/livepatch/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -248,11 +248,12 @@ static int klp_find_external_symbol(stru
/* first, check if it's an exported symbol */
preempt_disable();
sym = find_symbol(name, NULL, NULL, true, true);
- preempt_enable();
if (sym) {
*addr = sym-value;
+ preempt_enable();
return 0;
}
+ preempt_enable();
/* otherwise check if it's in another .o within the patch module */
return klp_find_object_symbol(pmod-name, name, addr);
--
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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
(2015/03/01 6:24), Peter Zijlstra wrote:
> While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
> one must equally hold it over the use of the object returned.
>
> The moment you release the RCU-sched read lock, the object can be dead
> and gone.
>
> Cc: Seth Jennings
> Cc: Josh Poimboeuf
> Cc: Masami Hiramatsu
> Cc: Miroslav Benes
> Cc: Petr Mladek
> Cc: Jiri Kosina
> Cc: "Paul E. McKenney"
> Cc: Rusty Russell
> Signed-off-by: Peter Zijlstra (Intel)
Looks good to me.
Reviewed-by: Masami Hiramatsu
Thank you,
> ---
> kernel/livepatch/core.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -248,11 +248,12 @@ static int klp_find_external_symbol(stru
> /* first, check if it's an exported symbol */
> preempt_disable();
> sym = find_symbol(name, NULL, NULL, true, true);
> - preempt_enable();
> if (sym) {
> *addr = sym->value;
> + preempt_enable();
> return 0;
> }
> + preempt_enable();
>
> /* otherwise check if it's in another .o within the patch module */
> return klp_find_object_symbol(pmod->name, name, addr);
>
>
> --
> 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 FAQ at http://www.tux.org/lkml/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Sat, 28 Feb 2015, Peter Zijlstra wrote: > While one must hold RCU-sched (aka. preempt_disable) for find_symbol() > one must equally hold it over the use of the object returned. > > The moment you release the RCU-sched read lock, the object can be dead > and gone. > > Cc: Seth Jennings > Cc: Josh Poimboeuf > Cc: Masami Hiramatsu > Cc: Miroslav Benes > Cc: Petr Mladek > Cc: Jiri Kosina > Cc: "Paul E. McKenney" > Cc: Rusty Russell > Signed-off-by: Peter Zijlstra (Intel) Acked-by: Jiri Kosina I guess you'll be taking this together with the series, so I am not applying it. Thanks, -- Jiri Kosina SUSE Labs -- 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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
(2015/03/01 6:24), Peter Zijlstra wrote:
While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
one must equally hold it over the use of the object returned.
The moment you release the RCU-sched read lock, the object can be dead
and gone.
Cc: Seth Jennings sjenn...@redhat.com
Cc: Josh Poimboeuf jpoim...@redhat.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Miroslav Benes mbe...@suse.cz
Cc: Petr Mladek pmla...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
Looks good to me.
Reviewed-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Thank you,
---
kernel/livepatch/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -248,11 +248,12 @@ static int klp_find_external_symbol(stru
/* first, check if it's an exported symbol */
preempt_disable();
sym = find_symbol(name, NULL, NULL, true, true);
- preempt_enable();
if (sym) {
*addr = sym-value;
+ preempt_enable();
return 0;
}
+ preempt_enable();
/* otherwise check if it's in another .o within the patch module */
return klp_find_object_symbol(pmod-name, name, addr);
--
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 FAQ at http://www.tux.org/lkml/
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
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 FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/9] klp: Fix obvious RCU fail
On Sat, 28 Feb 2015, Peter Zijlstra wrote: While one must hold RCU-sched (aka. preempt_disable) for find_symbol() one must equally hold it over the use of the object returned. The moment you release the RCU-sched read lock, the object can be dead and gone. Cc: Seth Jennings sjenn...@redhat.com Cc: Josh Poimboeuf jpoim...@redhat.com Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com Cc: Miroslav Benes mbe...@suse.cz Cc: Petr Mladek pmla...@suse.cz Cc: Jiri Kosina jkos...@suse.cz Cc: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org Acked-by: Jiri Kosina jkos...@suse.cz I guess you'll be taking this together with the series, so I am not applying it. Thanks, -- Jiri Kosina SUSE Labs -- 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 FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/9] klp: Fix obvious RCU fail
While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
one must equally hold it over the use of the object returned.
The moment you release the RCU-sched read lock, the object can be dead
and gone.
Cc: Seth Jennings
Cc: Josh Poimboeuf
Cc: Masami Hiramatsu
Cc: Miroslav Benes
Cc: Petr Mladek
Cc: Jiri Kosina
Cc: "Paul E. McKenney"
Cc: Rusty Russell
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/livepatch/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -248,11 +248,12 @@ static int klp_find_external_symbol(stru
/* first, check if it's an exported symbol */
preempt_disable();
sym = find_symbol(name, NULL, NULL, true, true);
- preempt_enable();
if (sym) {
*addr = sym->value;
+ preempt_enable();
return 0;
}
+ preempt_enable();
/* otherwise check if it's in another .o within the patch module */
return klp_find_object_symbol(pmod->name, name, addr);
--
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 FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/9] klp: Fix obvious RCU fail
While one must hold RCU-sched (aka. preempt_disable) for find_symbol()
one must equally hold it over the use of the object returned.
The moment you release the RCU-sched read lock, the object can be dead
and gone.
Cc: Seth Jennings sjenn...@redhat.com
Cc: Josh Poimboeuf jpoim...@redhat.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Miroslav Benes mbe...@suse.cz
Cc: Petr Mladek pmla...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
---
kernel/livepatch/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -248,11 +248,12 @@ static int klp_find_external_symbol(stru
/* first, check if it's an exported symbol */
preempt_disable();
sym = find_symbol(name, NULL, NULL, true, true);
- preempt_enable();
if (sym) {
*addr = sym-value;
+ preempt_enable();
return 0;
}
+ preempt_enable();
/* otherwise check if it's in another .o within the patch module */
return klp_find_object_symbol(pmod-name, name, addr);
--
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 FAQ at http://www.tux.org/lkml/
