From: Michael Tokarev <mjt@tls.msk.ru>
To: Chen Gang S <gang.chen@sunrus.com.cn>,
riku.voipio@iki.fi, david.gilbert@linaro.org,
Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-trivial] [PATCH v2] linux-user/main.c: Remove redundant end_exclusive() in arm_kernel_cmpxchg64_helper()
Date: Tue, 27 Jan 2015 19:11:58 +0300 [thread overview]
Message-ID: <54C7B8CE.5020708@msgid.tls.msk.ru> (raw)
In-Reply-To: <54C4CD81.10503@sunrus.com.cn>
25.01.2015 14:03, Chen Gang S wrote:
> start/end_exclusive() need be pairs, except the start_exclusive() in
"need TO be pairs", or "should be pairs" or "should be called in pairs".
> stop_all_tasks() which is only used by force_sig(), which will be abort.
"which will abort" or "which will call abort()" or "which calls abort()".
> So at present, start_exclusive() in stop_all_task() need not be paired.
>
> queue_signal() may call force_sig(), or return after kill pid (or queue
> signal).
"or return after killing pid (or queuing signal)".
> If could return from queue_signal(), stop_all_task() would not
> be called in time,
"if queue_signal() returns
> the next end_exclusive() would be issue.
"would be AN issue".
But actually we're interested to know answer to a slightly different
question: whenever queue_signal() returns or not (it doesn't return in
force_sig case). So whole this part becomes something like:
queue_signal() may either call force_sig() and die, or return. In
the latter case, stop_all_task() would not be called in time, so
next end_exclusive() will be an issue.
And even more, when you look at this function (arm_kernel_cmpxchg64_helper),
you'll notice it has two calls to end_exclusive() in sigsegv case, without
a call to start_exclusive(). _That_ is, I think, the key point here --
the rest of the information here is not really very relevant, because
the actual problem is this double call to end_exclusive() which should
be removed. It is not really that interesting to know that it's not
_necessary_ to call end_exclusive() in some cases which leads to abort(),
because this is not one of them anyway (since queue_signal() might return
just fine), and because while it is not necessary, it is not an error
either. With all this extra info, thie commit message becomes just too
confusing.
> So in arm_kernel_cmpxchg64_helper() for ARM, need remove end_exclusive()
> after queue_signal().
"need TO remove", and again the missing subject. "We need to remove", or
"we should remove", or, yet another variant, "extra end_exclusive() call
should be removed".
> The related commit: "97cc756 linux-user: Implement
> new ARM 64 bit cmpxchg kernel helper".
So, how about this (the subject is fine):
start/end_exclusive() should be paired to each other. However, in
arm_kernel_cmpxchg64_helper() function, end_exclusive() is called
twice in a row. Remove the second, redundrand, call.
Commit which introduced this problem is"97cc756 linux-user: Implement
new ARM 64 bit cmpxchg kernel helper".
?
Did I understand the problem correctly?
Thanks,
/mjt
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> ---
> linux-user/main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 8c70be4..2d52c1f 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -523,8 +523,6 @@ segv:
> info.si_code = TARGET_SEGV_MAPERR;
> info._sifields._sigfault._addr = env->exception.vaddress;
> queue_signal(env, info.si_signo, &info);
> -
> - end_exclusive();
> }
>
> /* Handle a jump to the kernel code page. */
>
WARNING: multiple messages have this Message-ID (diff)
From: Michael Tokarev <mjt@tls.msk.ru>
To: Chen Gang S <gang.chen@sunrus.com.cn>,
riku.voipio@iki.fi, david.gilbert@linaro.org,
Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2] linux-user/main.c: Remove redundant end_exclusive() in arm_kernel_cmpxchg64_helper()
Date: Tue, 27 Jan 2015 19:11:58 +0300 [thread overview]
Message-ID: <54C7B8CE.5020708@msgid.tls.msk.ru> (raw)
In-Reply-To: <54C4CD81.10503@sunrus.com.cn>
25.01.2015 14:03, Chen Gang S wrote:
> start/end_exclusive() need be pairs, except the start_exclusive() in
"need TO be pairs", or "should be pairs" or "should be called in pairs".
> stop_all_tasks() which is only used by force_sig(), which will be abort.
"which will abort" or "which will call abort()" or "which calls abort()".
> So at present, start_exclusive() in stop_all_task() need not be paired.
>
> queue_signal() may call force_sig(), or return after kill pid (or queue
> signal).
"or return after killing pid (or queuing signal)".
> If could return from queue_signal(), stop_all_task() would not
> be called in time,
"if queue_signal() returns
> the next end_exclusive() would be issue.
"would be AN issue".
But actually we're interested to know answer to a slightly different
question: whenever queue_signal() returns or not (it doesn't return in
force_sig case). So whole this part becomes something like:
queue_signal() may either call force_sig() and die, or return. In
the latter case, stop_all_task() would not be called in time, so
next end_exclusive() will be an issue.
And even more, when you look at this function (arm_kernel_cmpxchg64_helper),
you'll notice it has two calls to end_exclusive() in sigsegv case, without
a call to start_exclusive(). _That_ is, I think, the key point here --
the rest of the information here is not really very relevant, because
the actual problem is this double call to end_exclusive() which should
be removed. It is not really that interesting to know that it's not
_necessary_ to call end_exclusive() in some cases which leads to abort(),
because this is not one of them anyway (since queue_signal() might return
just fine), and because while it is not necessary, it is not an error
either. With all this extra info, thie commit message becomes just too
confusing.
> So in arm_kernel_cmpxchg64_helper() for ARM, need remove end_exclusive()
> after queue_signal().
"need TO remove", and again the missing subject. "We need to remove", or
"we should remove", or, yet another variant, "extra end_exclusive() call
should be removed".
> The related commit: "97cc756 linux-user: Implement
> new ARM 64 bit cmpxchg kernel helper".
So, how about this (the subject is fine):
start/end_exclusive() should be paired to each other. However, in
arm_kernel_cmpxchg64_helper() function, end_exclusive() is called
twice in a row. Remove the second, redundrand, call.
Commit which introduced this problem is"97cc756 linux-user: Implement
new ARM 64 bit cmpxchg kernel helper".
?
Did I understand the problem correctly?
Thanks,
/mjt
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> ---
> linux-user/main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 8c70be4..2d52c1f 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -523,8 +523,6 @@ segv:
> info.si_code = TARGET_SEGV_MAPERR;
> info._sifields._sigfault._addr = env->exception.vaddress;
> queue_signal(env, info.si_signo, &info);
> -
> - end_exclusive();
> }
>
> /* Handle a jump to the kernel code page. */
>
next prev parent reply other threads:[~2015-01-27 16:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-25 11:03 [Qemu-trivial] [PATCH v2] linux-user/main.c: Remove redundant end_exclusive() in arm_kernel_cmpxchg64_helper() Chen Gang S
2015-01-25 11:03 ` [Qemu-devel] " Chen Gang S
2015-01-25 12:41 ` [Qemu-trivial] " Peter Maydell
2015-01-25 12:41 ` [Qemu-devel] " Peter Maydell
2015-01-27 16:11 ` Michael Tokarev [this message]
2015-01-27 16:11 ` Michael Tokarev
2015-01-28 5:42 ` [Qemu-trivial] " Chen Gang S
2015-01-28 5:42 ` [Qemu-devel] " Chen Gang S
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=54C7B8CE.5020708@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=david.gilbert@linaro.org \
--cc=gang.chen@sunrus.com.cn \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=riku.voipio@iki.fi \
/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.