All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] ARM: perf: disable the pagefault handler when reading from user space
Date: Thu, 3 Jul 2014 18:52:31 +0100	[thread overview]
Message-ID: <20140703175231.GF17372@arm.com> (raw)
In-Reply-To: <1403881067-22690-3-git-send-email-jean.pihet@linaro.org>

Hi Jean,

On Fri, Jun 27, 2014 at 03:57:46PM +0100, Jean Pihet wrote:
> As done on other architectures (ARM64, x86, Sparc etc.).
> 
> This prevents a deadlock on down_read in do_page_fault when unwinding
> using fp and triggering on kernel tracepoints:

So is this an issue because you could try setting tracepoints on the
pagefault path? If so, the patch is a little brutal as it would break user
backtracing as soon as we take any old page fault, no?

Or am I missing something obvious?

Will

>   INFO: task stress:2116 blocked for more than 120 seconds.
>         Not tainted 3.15.0-rc4-00364-g3401dfb-dirty #43
>   "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>   stress          D c04b41e8     0  2116   2115 0x00000000
>   [<c04b41e8>] (__schedule) from [<c04b46dc>] (schedule+0x40/0x90)
>   [<c04b46dc>] (schedule) from [<c04b6ec8>] (__down_read+0xc4/0xfc)
>   [<c04b6ec8>] (__down_read) from [<c04b69c0>] (down_read+0x18/0x1c)
>   [<c04b69c0>] (down_read) from [<c001d41c>] (do_page_fault+0xac/0x420)
>   [<c001d41c>] (do_page_fault) from [<c0008444>] (do_DataAbort+0x44/0xa8)
>   [<c0008444>] (do_DataAbort) from [<c00136b8>] (__dabt_svc+0x38/0x60)
>   Exception stack(0xecbc3af8 to 0xecbc3b40)
>   3ae0:                                                       ecbc3b74 b6d72ff4
>   3b00: ffffffec 00000000 b6d72ff4 ec0fc000 00000000 ec0fc000 0000007e 00000000
>   3b20: ecbc2000 ecbc3bac 00000014 ecbc3b44 c0019e78 c021ef44 00000013 ffffffff
>   [<c00136b8>] (__dabt_svc) from [<c021ef44>] (__copy_from_user+0xa4/0x3a0)
> 
> Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
>  arch/arm/kernel/perf_event.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 6493c4c..f5aeca2 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -560,11 +560,16 @@ user_backtrace(struct frame_tail __user *tail,
>  	       struct perf_callchain_entry *entry)
>  {
>  	struct frame_tail buftail;
> +	unsigned long err;
>  
> -	/* Also check accessibility of one struct frame_tail beyond */
>  	if (!access_ok(VERIFY_READ, tail, sizeof(buftail)))
>  		return NULL;
> -	if (__copy_from_user_inatomic(&buftail, tail, sizeof(buftail)))
> +
> +	pagefault_disable();
> +	err = __copy_from_user_inatomic(&buftail, tail, sizeof(buftail));
> +	pagefault_enable();
> +
> +	if (err)
>  		return NULL;
>  
>  	perf_callchain_store(entry, buftail.lr);
> -- 
> 1.8.1.2
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Jean Pihet <jean.pihet@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	Sneha Priya <sneha.cse@hotmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jiri Olsa <jolsa@redhat.com>,
	Arnaldo Carvalho de Melo <acme@infradead.org>
Subject: Re: [PATCH 2/3] ARM: perf: disable the pagefault handler when reading from user space
Date: Thu, 3 Jul 2014 18:52:31 +0100	[thread overview]
Message-ID: <20140703175231.GF17372@arm.com> (raw)
In-Reply-To: <1403881067-22690-3-git-send-email-jean.pihet@linaro.org>

Hi Jean,

On Fri, Jun 27, 2014 at 03:57:46PM +0100, Jean Pihet wrote:
> As done on other architectures (ARM64, x86, Sparc etc.).
> 
> This prevents a deadlock on down_read in do_page_fault when unwinding
> using fp and triggering on kernel tracepoints:

So is this an issue because you could try setting tracepoints on the
pagefault path? If so, the patch is a little brutal as it would break user
backtracing as soon as we take any old page fault, no?

Or am I missing something obvious?

Will

>   INFO: task stress:2116 blocked for more than 120 seconds.
>         Not tainted 3.15.0-rc4-00364-g3401dfb-dirty #43
>   "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>   stress          D c04b41e8     0  2116   2115 0x00000000
>   [<c04b41e8>] (__schedule) from [<c04b46dc>] (schedule+0x40/0x90)
>   [<c04b46dc>] (schedule) from [<c04b6ec8>] (__down_read+0xc4/0xfc)
>   [<c04b6ec8>] (__down_read) from [<c04b69c0>] (down_read+0x18/0x1c)
>   [<c04b69c0>] (down_read) from [<c001d41c>] (do_page_fault+0xac/0x420)
>   [<c001d41c>] (do_page_fault) from [<c0008444>] (do_DataAbort+0x44/0xa8)
>   [<c0008444>] (do_DataAbort) from [<c00136b8>] (__dabt_svc+0x38/0x60)
>   Exception stack(0xecbc3af8 to 0xecbc3b40)
>   3ae0:                                                       ecbc3b74 b6d72ff4
>   3b00: ffffffec 00000000 b6d72ff4 ec0fc000 00000000 ec0fc000 0000007e 00000000
>   3b20: ecbc2000 ecbc3bac 00000014 ecbc3b44 c0019e78 c021ef44 00000013 ffffffff
>   [<c00136b8>] (__dabt_svc) from [<c021ef44>] (__copy_from_user+0xa4/0x3a0)
> 
> Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
>  arch/arm/kernel/perf_event.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 6493c4c..f5aeca2 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -560,11 +560,16 @@ user_backtrace(struct frame_tail __user *tail,
>  	       struct perf_callchain_entry *entry)
>  {
>  	struct frame_tail buftail;
> +	unsigned long err;
>  
> -	/* Also check accessibility of one struct frame_tail beyond */
>  	if (!access_ok(VERIFY_READ, tail, sizeof(buftail)))
>  		return NULL;
> -	if (__copy_from_user_inatomic(&buftail, tail, sizeof(buftail)))
> +
> +	pagefault_disable();
> +	err = __copy_from_user_inatomic(&buftail, tail, sizeof(buftail));
> +	pagefault_enable();
> +
> +	if (err)
>  		return NULL;
>  
>  	perf_callchain_store(entry, buftail.lr);
> -- 
> 1.8.1.2
> 
> 

  reply	other threads:[~2014-07-03 17:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-27 14:57 [PATCH 0/3] ARM: perf: allow tracing with kernel tracepoints events Jean Pihet
2014-06-27 14:57 ` Jean Pihet
2014-06-27 14:57 ` [PATCH 1/3] ARM: perf: Check that current->mm is alive before getting user callchain Jean Pihet
2014-06-27 14:57   ` Jean Pihet
2014-07-03 17:53   ` Will Deacon
2014-07-03 17:53     ` Will Deacon
2014-06-27 14:57 ` [PATCH 2/3] ARM: perf: disable the pagefault handler when reading from user space Jean Pihet
2014-06-27 14:57   ` Jean Pihet
2014-07-03 17:52   ` Will Deacon [this message]
2014-07-03 17:52     ` Will Deacon
2014-07-07 13:40     ` Jean Pihet
2014-07-07 13:40       ` Jean Pihet
2014-06-27 14:57 ` [PATCH 3/3] ARM: perf: allow tracing with kernel tracepoints events Jean Pihet
2014-06-27 14:57   ` Jean Pihet
2014-07-03 17:54   ` Will Deacon
2014-07-03 17:54     ` Will Deacon
2014-07-07 13:42     ` Jean Pihet
2014-07-07 13:42       ` Jean Pihet
  -- strict thread matches above, loose matches on Subject: below --
2014-07-07 13:45 [PATCH 0/3] " Jean Pihet
2014-07-07 13:45 ` [PATCH 2/3] ARM: perf: disable the pagefault handler when reading from user space Jean Pihet
2014-07-07 13:45   ` Jean Pihet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140703175231.GF17372@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.