memmap.Mappable.Translate() is passed a hostarch.AccessType indicating what
permissions are *immediately* required; it returns permissions in
memmap.Translation.Perms that are granted *to MM* until invalidation. MM
ensures that the permissions granted to the application are the intersection of
those granted by Translate, and those granted by VMA permissions; see
determination of pma.effectivePerms in
mm.MemoryManager.getPMAsInternalLocked(). This mechanism is used to avoid
marking pages dirty in the sentry's page cache for gofer-backed files until
PROT_WRITE pages are actually written to; see gofer.dentry.Translate(). In most
other cases, granting all supported permissions (to MM) up-front avoids a
redundant page fault for pages that are touched first for reading, and later
for writing.
Also:
- Prevent PROT_WRITE mappings of erofs files at mmap()/mprotect() time, rather
than raising SIGBUS when writing to such mappings.
- Map nvproxy.frontendFD with PlatformEffectPopulate. This is the original goal
of this CL; however, before this rest of this CL, MM.MMap() =>
MM.populateVMAAndUnlock() => MM.getPMAsLocked(at=hostarch.NoAccess) =>
MM.getPMAsInternalLocked(at=hostarch.NoAccess) =>
nvproxy.frontendFD.Translate(at=hostarch.NoAccess) returns Translations with
no permissions, causing MM.mapASLocked() to no-op.
PiperOrigin-RevId: 679360594
The work done in c087777e37 ("Plumb restore context to afterLoad()") makes
pgalloc.MemoryFileProvider redundant as structs can now easily restore
pgalloc.MemoryFile in stateify's afterLoad() method. This allows structs to
have a pgalloc.MemoryFile field and use that directly, instead of going through
the provided interface.
This cleans up a lot of code and also should be more performant (avoids an
interface method call on many hot paths).
PiperOrigin-RevId: 615258927
It is an idea of running codespell as part of our presubmit checks.
Before enabling it for new changes, let's fix what it has found.
Signed-off-by: Andrei Vagin <avagin@gmail.com>
For memory accounting per task, the memory cgroup id of the task is required.
This CL retrieves the cgroup id from the task context and stores it in the
AllocOpts struct which will later be used to account for memory usage.
PiperOrigin-RevId: 546996195
This is consistent with what Linux does after bb68d504f7c4 ("io_uring: ignore
->buf_index if REQ_F_BUFFER_SELECT isn't set").
This is causing the READVWithInvalidSqeFieldValue test to fail on newer kernel.
PiperOrigin-RevId: 527386953
Accessing a pointer to the data in a slice can be achieved with
`unsafe.Pointer(&slice[0])`.
f051ec6463 motivated using gohacks.SliceHeader in
this way with "we often use SliceHeader to extract pointers from slices in a
way that avoids bounds checking and/or handles nil slices correctly", but this
no longer seems to be the case. None of the remaining uses are obviously
performance sensitive or necessarily include bounds checks, nor get used with
nil slices.
This brings us one step closer to removing gohacks.SliceHeader, which is one
less internal detail to keep in sync with Go.
For #8422
PiperOrigin-RevId: 504408578
The current io_uring support is very limited and experimental. Disable
it by default, and add a flag to enable it for testing.
PiperOrigin-RevId: 500760451
This loop can take a long time. Since we're blocking on IO outside
Task.Block, we need to periodically check for interrupts and update
pet the watchdog.
Reported-by: syzbot+3fd282d7e4e5c83fc196@syzkaller.appspotmail.com
PiperOrigin-RevId: 494009269
Previously we were using a mutex to serialize concurrent callers to
ProcessSubmissions. The processing loop can run for a long time, so
blocking a task on a Lock() can lead to watchdog timeouts as well as
interruptibility issues.
Instead, put concurrent callers to sleep with Task.Block.
PiperOrigin-RevId: 492527965
EOFs shouldn't be raised as an errno as error translation will
fail. Short reads aren't failures on a readv syscall.
Reported-by: syzbot+37fc0fc0df42740a5cea@syzkaller.appspotmail.com
PiperOrigin-RevId: 489242631
Handling NOP operations helped us to introduce facilities to process submission
requests. Now we can proceed to adding more meaningful operations. The logical
choice for the first one is the READV operation as it is a next operation after
NOP and it is also used for the cat-like application example based of IO_URING.
PiperOrigin-RevId: 487615618
We should compare against maximum number of allowed cq entries instead of
comparing against the flag that allows to set that number.
PiperOrigin-RevId: 487045476
With io_uring_setup() and mmap() we can proceed with implementing a simplest
operation, namely, NOP. Once we make sure that we can send this command and
receive a response from the gVisor, we can move forward to read operation.
PiperOrigin-RevId: 485106019
This avoids the cost at startup time and allows the resulting function to
be more effectively inlined to call sites. Although these are not widely
used at the moment, this change may also be used as an example for code
generation in similar cases.
PiperOrigin-RevId: 477597333
Once the user receives a file descriptor from `io_uring_setup()`, it will be
used for the subsequent `mmap()` calls. Thus, we need to add support for it in
our iouringfs.
PiperOrigin-RevId: 477318038
Similar to Linux, we should add pseudo-filesystem iouringfs in gVisor to back
IO_URING's file descriptors. We start with stubbing `io_uring_setup(2)` so it
provides a file descriptor backed by anonfs.
PiperOrigin-RevId: 473384042
