[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211119065831.31406-1-songmuchun@bytedance.com>
Date: Fri, 19 Nov 2021 14:58:31 +0800
From: Muchun Song <songmuchun@...edance.com>
To: dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
duanxiongchun@...edance.com, zhengqi.arch@...edance.com,
Muchun Song <songmuchun@...edance.com>
Subject: [RFC PATCH] x86/fault: move might_sleep() out of mmap read lock
The mmap lock is supposed to be a contended lock sometimes, scheduling
to other task with holding mmap read lock does not seems to be a wise
choice. So move it to the front of mmap_read_trylock(). Although
mmap_read_lock() implies a might_sleep(), I think redundant check is
not a problem since this task is about to sleep and it is not a hot
path.
Signed-off-by: Muchun Song <songmuchun@...edance.com>
---
arch/x86/mm/fault.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 4bfed53e210e..22fd1dfafa3d 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1323,6 +1323,8 @@ void do_user_addr_fault(struct pt_regs *regs,
}
#endif
+ might_sleep();
+
/*
* Kernel-mode access to the user address space should only occur
* on well-defined single instructions listed in the exception
@@ -1346,13 +1348,6 @@ void do_user_addr_fault(struct pt_regs *regs,
}
retry:
mmap_read_lock(mm);
- } else {
- /*
- * The above down_read_trylock() might have succeeded in
- * which case we'll have missed the might_sleep() from
- * down_read():
- */
- might_sleep();
}
vma = find_vma(mm, address);
--
2.11.0
Powered by blists - more mailing lists