From: Vinayak Menon <vinmenon@codeaurora.org>
To: ldufour@linux.vnet.ibm.com
Cc: Linux-MM <linux-mm@kvack.org>, charante@codeaurora.org
Subject: [PATCH v11 00/26] Speculative page faults
Date: Fri, 11 Jan 2019 21:13:20 +0530 [thread overview]
Message-ID: <8b0b2c05-89f8-8002-2dce-fa7004907e78@codeaurora.org> (raw)
Hi Laurent,
We are observing an issue with speculative page fault with the following test code on ARM64 (4.14 kernel, 8 cores).
Steps:
1) Run the program
2) The 2 threads will try lock/unlock and prints messages, and main thread does fork. In around 1 minute time, lock/unlock threads will hang on pthread_mutex_lock.
Initially the issue was reported when ptrace was tried on apps. Later it was discovered that the write protect done by fork is causing the issue and the below test code was created.
Observations:
1) We have tried disabling SPF and the issue disappears.
2) Adding this piece of code in __handle_speculative_fault also fixes the problem.
if (flags & FAULT_FLAG_WRITE && !pte_write(vmf.orig_pte))
return VM_FAULT_RETRY;
3) As an experiment we tried encapsulating handle_speculative_fault with down_read(mmap_sem) and that too fixes the problem.
4) It is observed that while in wp_page_copy, the contents of the old_page changes which should not ideally happen as the pte is !pte_write.
5) To prove that it is a race, we tried affining the threads to single core, and the issue disappears.
Let us know if you want us to try out any experiments.
Thanks,
Vinayak
/**test.c***/
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#define UNUSED(expr) do { (void)(expr); } while(0)
#define print printf
pthread_mutex_t m;
pthread_cond_t c;
static void* cond_do(void* arg)
{
UNUSED(arg);
do {
print("%s:%d state=%u addr: %lx\n", __func__, __LINE__, *(uint32_t*)(&m), (unsigned long)&m);
pthread_mutex_lock(&m);
print("%s:%d state=%u addr: %lx\n", __func__, __LINE__, *(uint32_t*)(&m), (unsigned long)&m);
pthread_mutex_unlock(&m);
print("%s:%d state=%u addr: %lx\n", __func__, __LINE__, *(uint32_t*)(&m), (unsigned long)&m);
} while (true);
return NULL;
}
static void* sig_do(void* arg)
{
UNUSED(arg);
do {
print("%s:%d state=%u addr: %lx\n", __func__, __LINE__, *(uint32_t*)(&m), (unsigned long)&m);
pthread_mutex_lock(&m);
print("%s:%d state=%u addr: %lx\n", __func__, __LINE__, *(uint32_t*)(&m), (unsigned long)&m);
pthread_mutex_unlock(&m);
print("%s:%d state=%u addr: %lx\n", __func__, __LINE__, *(uint32_t*)(&m), (unsigned long)&m);
} while (true);
return NULL;
}
int main()
{
pthread_t sig;
pthread_t cond;
pthread_mutex_init(&m, NULL);
pthread_create(&cond, NULL, cond_do, NULL);
pthread_create(&sig, NULL, sig_do, NULL);
while(1) {
if (!fork()) {
usleep(500);
abort();
}
usleep(550);
}
pthread_join(sig, NULL);
pthread_join(cond, NULL);
return 0;
}
next reply other threads:[~2019-01-11 15:43 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 15:43 Vinayak Menon [this message]
2019-01-14 13:19 ` Vinayak Menon
2019-01-15 8:24 ` Laurent Dufour
2019-01-16 11:41 ` Vinayak Menon
2019-01-16 13:31 ` Laurent Dufour
2019-01-16 11:41 ` Vinayak Menon
2019-01-17 15:51 ` zhong jiang
2019-01-17 15:51 ` zhong jiang
2019-01-18 9:29 ` Laurent Dufour
2019-01-18 15:41 ` zhong jiang
2019-01-18 15:41 ` zhong jiang
2019-01-18 15:51 ` Laurent Dufour
2019-01-18 16:24 ` Laurent Dufour
2019-01-19 17:05 ` zhong jiang
2019-01-19 17:05 ` zhong jiang
2019-01-22 16:22 ` zhong jiang
2019-01-22 16:22 ` zhong jiang
2019-01-24 8:20 ` Laurent Dufour
2019-01-25 12:32 ` zhong jiang
2019-01-25 12:32 ` zhong jiang
2019-01-28 8:59 ` Laurent Dufour
2019-01-28 14:09 ` zhong jiang
2019-01-28 14:09 ` zhong jiang
2019-01-28 15:45 ` Laurent Dufour
2019-01-29 15:40 ` zhong jiang
-- strict thread matches above, loose matches on Subject: below --
2018-05-17 11:06 Laurent Dufour
2018-05-28 5:23 ` Song, HaiyanX
2018-05-28 7:51 ` Laurent Dufour
2018-05-28 8:22 ` Haiyan Song
2018-05-28 8:54 ` Laurent Dufour
2018-05-28 11:04 ` Wang, Kemi
2018-06-11 7:49 ` Song, HaiyanX
2018-06-11 15:15 ` Laurent Dufour
2018-06-19 9:16 ` Haiyan Song
2018-07-02 8:59 ` Laurent Dufour
2018-07-04 3:23 ` Song, HaiyanX
2018-07-04 7:51 ` Laurent Dufour
2018-07-11 17:05 ` Laurent Dufour
2018-07-13 3:56 ` Song, HaiyanX
2018-07-17 9:36 ` Laurent Dufour
2018-08-03 6:36 ` Song, HaiyanX
2018-08-03 6:45 ` Song, HaiyanX
2018-08-22 14:23 ` Laurent Dufour
2018-09-18 6:42 ` Song, HaiyanX
2018-11-05 10:42 ` Balbir Singh
2018-11-05 16:08 ` Laurent Dufour
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=8b0b2c05-89f8-8002-2dce-fa7004907e78@codeaurora.org \
--to=vinmenon@codeaurora.org \
--cc=charante@codeaurora.org \
--cc=ldufour@linux.vnet.ibm.com \
--cc=linux-mm@kvack.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