From: Ram Pai <linuxram@us.ibm.com>
To: shuahkh@osg.samsung.com, linux-kselftest@vger.kernel.org
Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
linux-mm@kvack.org, x86@kernel.org, linux-arch@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
mingo@redhat.com, akpm@linux-foundation.org,
dave.hansen@intel.com, benh@kernel.crashing.org,
paulus@samba.org, khandual@linux.vnet.ibm.com,
aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com,
hbabu@us.ibm.com, mhocko@kernel.org, bauerman@linux.vnet.ibm.com,
ebiederm@xmission.com, linuxram@us.ibm.com, arnd@arndb.de
Subject: [PATCH v10 22/24] selftests/vm: Fix deadlock in protection_keys.c
Date: Mon, 22 Jan 2018 10:52:15 -0800 [thread overview]
Message-ID: <1516647137-11174-23-git-send-email-linuxram@us.ibm.com> (raw)
In-Reply-To: <1516647137-11174-1-git-send-email-linuxram@us.ibm.com>
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
The sig_chld() handler calls dprintf2() taking care of setting
dprint_in_signal so that sigsafe_printf() won't call printf().
Unfortunately, this precaution is is negated by dprintf_level(), which
has a call to fflush().
This function acquires a lock, which means that if the signal interrupts an
ongoing fflush() the process will deadlock. At least on powerpc this is
easy to trigger, resulting in the following backtrace when attaching to the
frozen process:
(gdb) bt
#0 0x00007fff9f96c7d8 in __lll_lock_wait_private () from /lib64/power8/libc.so.6
#1 0x00007fff9f8cba4c in _IO_flush_all_lockp () from /lib64/power8/libc.so.6
#2 0x00007fff9f8cbd1c in __GI__IO_flush_all () from /lib64/power8/libc.so.6
#3 0x00007fff9f8b7424 in fflush () from /lib64/power8/libc.so.6
#4 0x00000000100504f8 in sig_chld (x=17) at protection_keys.c:283
#5 <signal handler called>
#6 0x00007fff9f8cb8ac in _IO_flush_all_lockp () from /lib64/power8/libc.so.6
#7 0x00007fff9f8cbd1c in __GI__IO_flush_all () from /lib64/power8/libc.so.6
#8 0x00007fff9f8b7424 in fflush () from /lib64/power8/libc.so.6
#9 0x0000000010050b50 in pkey_get (pkey=7, flags=0) at protection_keys.c:379
#10 0x0000000010050dc0 in pkey_disable_set (pkey=7, flags=2) at protection_keys.c:423
#11 0x0000000010051414 in pkey_write_deny (pkey=7) at protection_keys.c:486
#12 0x00000000100556bc in test_ptrace_of_child (ptr=0x7fff9f7f0000, pkey=7) at protection_keys.c:1288
#13 0x0000000010055f60 in run_tests_once () at protection_keys.c:1414
#14 0x00000000100561a4 in main () at protection_keys.c:1459
The fix is to refrain from calling fflush() when inside a signal handler.
The output may not be as pretty but at least the testcase will be able to
move on.
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
tools/testing/selftests/vm/pkey-helpers.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
---
tools/testing/selftests/vm/pkey-helpers.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/tools/testing/selftests/vm/pkey-helpers.h b/tools/testing/selftests/vm/pkey-helpers.h
index 9d06b4a..965cfcd 100644
--- a/tools/testing/selftests/vm/pkey-helpers.h
+++ b/tools/testing/selftests/vm/pkey-helpers.h
@@ -131,7 +131,8 @@ static inline void sigsafe_printf(const char *format, ...)
#define dprintf_level(level, args...) do { \
if (level <= DEBUG_LEVEL) \
sigsafe_printf(args); \
- fflush(NULL); \
+ if (!dprint_in_signal) \
+ fflush(NULL); \
} while (0)
#define dprintf0(args...) dprintf_level(0, args)
#define dprintf1(args...) dprintf_level(1, args)
--
1.7.1
next prev parent reply other threads:[~2018-01-22 18:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 18:51 [PATCH v10 00/24] selftests, powerpc, x86 : Memory Protection Keys Ram Pai
2018-01-22 18:51 ` [PATCH v10 01/24] selftests/x86: Move protecton key selftest to arch neutral directory Ram Pai
2018-01-22 18:51 ` [PATCH v10 02/24] selftests/vm: rename all references to pkru to a generic name Ram Pai
2018-01-22 18:51 ` [PATCH v10 03/24] selftests/vm: move generic definitions to header file Ram Pai
2018-01-22 18:51 ` [PATCH v10 04/24] selftests/vm: typecast the pkey register Ram Pai
2018-01-22 18:51 ` [PATCH v10 05/24] selftests/vm: generic function to handle shadow key register Ram Pai
2018-01-22 18:51 ` [PATCH v10 06/24] selftests/vm: fix the wrong assert in pkey_disable_set() Ram Pai
2018-01-22 18:52 ` [PATCH v10 07/24] selftests/vm: fixed bugs in pkey_disable_clear() Ram Pai
2018-01-22 18:52 ` [PATCH v10 08/24] selftests/vm: clear the bits in shadow reg when a pkey is freed Ram Pai
2018-01-22 18:52 ` [PATCH v10 09/24] selftests/vm: fix alloc_random_pkey() to make it really random Ram Pai
2018-01-22 18:52 ` [PATCH v10 10/24] selftests/vm: introduce two arch independent abstraction Ram Pai
2018-01-22 18:52 ` [PATCH v10 11/24] selftests/vm: pkey register should match shadow pkey Ram Pai
2018-01-22 18:52 ` [PATCH v10 12/24] selftests/vm: generic cleanup Ram Pai
2018-01-22 18:52 ` [PATCH v10 13/24] selftests/vm: powerpc implementation for generic abstraction Ram Pai
2018-01-22 18:52 ` [PATCH v10 14/24] selftests/vm: clear the bits in shadow reg when a pkey is freed Ram Pai
2018-01-22 18:52 ` [PATCH v10 15/24] selftests/vm: powerpc implementation to check support for pkey Ram Pai
2018-01-22 18:52 ` [PATCH v10 16/24] selftests/vm: fix an assertion in test_pkey_alloc_exhaust() Ram Pai
2018-01-22 18:52 ` [PATCH v10 17/24] selftests/vm: associate key on a mapped page and detect access violation Ram Pai
2018-01-22 18:52 ` [PATCH v10 18/24] selftests/vm: associate key on a mapped page and detect write violation Ram Pai
2018-01-22 18:52 ` [PATCH v10 19/24] selftests/vm: detect write violation on a mapped access-denied-key page Ram Pai
2018-01-22 18:52 ` [PATCH v10 20/24] selftests/vm: testcases must restore pkey-permissions Ram Pai
2018-01-22 18:52 ` [PATCH v10 21/24] selftests/vm: sub-page allocator Ram Pai
2018-01-22 18:52 ` Ram Pai [this message]
2018-01-22 18:52 ` [PATCH v10 23/24] selftests/powerpc: Add ptrace tests for Protection Key register Ram Pai
2018-01-22 18:52 ` [PATCH v10 24/24] selftests/powerpc: Add core file test " Ram Pai
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=1516647137-11174-23-git-send-email-linuxram@us.ibm.com \
--to=linuxram@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=arnd@arndb.de \
--cc=bauerman@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=bsingharora@gmail.com \
--cc=dave.hansen@intel.com \
--cc=ebiederm@xmission.com \
--cc=hbabu@us.ibm.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=shuahkh@osg.samsung.com \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).