linux-mainline

mirror of https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux synced 2025-10-03 15:33:21 +10:00

Main-line Linux kernel tree http://www.kernel.org

Go to file

Linus Torvalds 4542057e18 mm: avoid 'might_sleep()' in get_mmap_lock_carefully() This might_sleep() goes back a long time: it was originally introduced way back when by commit `010060741a` ("x86: add might_sleep() to do_page_fault()"), and made it into the generic VM code when the x86 fault path got re-organized and generalized in commit `c2508ec5a5` ("mm: introduce new 'lock_mm_and_find_vma()' page fault helper"). However, it turns out that the placement of that might_sleep() has always been rather questionable simply because it's not only a debug statement to warn about sleeping in contexts that shouldn't sleep (which was the original reason for adding it), but it also implies a voluntary scheduling point. That, in turn, is less than desirable for two reasons: (a) it ends up being done after we successfully got the mmap_lock, so just as we got the lock we will now eagerly schedule away and increase lock contention and (b) this is all very possibly part of the "oops, things went horribly wrong" path and we just haven't figured that out yet After all, the whole _reason_ for having that get_mmap_lock_carefully() rather than just doing the obvious mmap_read_lock() is because this code wants to deal somewhat gracefully with potential kernel wild pointer bugs. So then a voluntary scheduling point here is simply not a good idea. We could certainly turn the 'might_sleep()' into a '__might_sleep()' and make it be just the debug check that it was originally intended to be. But even that seems questionable in the wild kernel pointer case - which again is part of the whole point of this code. The problem wouldn't be about the _sleeping_ part of the page fault, but about a bad kernel access. The fact that that bad kernel access might happen in a section that you shouldn't sleep in is secondary. So it really ends up being the case that this is simply entirely the wrong place to do this debug check and related scheduling point at all. So let's just remove the check entirely. It's been around for over a decade, it has served its purpose. The re-schedule will happen at return to user space anyway for the normal case, and the warning - if we even need it - might be better off done as a special case for "page fault from kernel mode" once we've dealt with any potential kernel oopses where the oops is the relevant thing, not some artificial "scheduling while atomic" test. Reported-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://lore.kernel.org/lkml/20230820104303.2083444-1-mjguzik@gmail.com/ Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>		2023-08-21 06:11:33 +02:00
arch	- Use LEA ...%rsp instead of ADD %rsp in the Zen1/2 SRSO return sequence	2023-08-19 10:46:02 +02:00
block	block-6.5-2023-08-19	2023-08-19 17:31:46 +02:00
certs
crypto
Documentation	Usual set of driver fixes. A bit more than usual because I was	2023-08-19 19:22:41 +02:00
drivers	TTY/Serial fixes for 6.5-rc7	2023-08-20 08:26:51 +02:00
fs	for-6.5-rc6-tag	2023-08-19 17:57:07 +02:00
include	TTY/Serial fixes for 6.5-rc7	2023-08-20 08:26:51 +02:00
init
io_uring
ipc
kernel
lib
LICENSES
mm	mm: avoid 'might_sleep()' in get_mmap_lock_carefully()	2023-08-21 06:11:33 +02:00
net
rust
samples
scripts
security
sound
tools	- Use LEA ...%rsp instead of ADD %rsp in the Zen1/2 SRSO return sequence	2023-08-19 10:46:02 +02:00
usr
virt
.clang-format
.cocciconfig
.get_maintainer.ignore
.gitattributes
.gitignore
.mailmap
.rustfmt.toml
COPYING
CREDITS
Kbuild
Kconfig
MAINTAINERS	TTY/Serial fixes for 6.5-rc7	2023-08-20 08:26:51 +02:00
Makefile	Linux 6.5-rc7	2023-08-20 15:02:52 +02:00
README

README

Linux kernel
============

There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.

In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.  The formatted documentation can also be read online at:

    https://www.kernel.org/doc/html/latest/

There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.

Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.