The helper function is deprecated. The package gvisor.dev/gvisor/pkg/rand
depends on crypto/rand which performs worse thatn math/rand, the changes
are fine since they are not at any gVisor's hot path.
The ultimate goal is to migrate math/rand to math/rand/v2.
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>
As of right now, runsc's fsgofer Readdir implementation is
awfully slow for large directories that have >2000 entries. So
slow that is deserves a description.
This happens because fsgofer confuses the unit of `Count` as
"number of dirents" rather than "number of bytes". lisafs does
not suffer from this.
Lets say there is a large directory with 100,000 files. When the
application does `ls`, the gofer reads all 100,000 entries from
the host and populates a huge slice with all these dirents.
p9/messages.go:Rreaddir.encode() silently discards 98,000 of
those dirents because only ~2,000 of them fit in `Count` bytes.
Then the gofer client again makes a Readdir RPC with offset
2,000. The gofer reads all 100,000 files, skips first 2,000,
returns next 2,000 and discards 96,000. This repeats until
all files are returned.
Updated fsgofer to realize `Count` as number of bytes to read.
fsgofer only reads upto 80% of the count limit from the host
to take into account the fact that p9.Dirent takes more bytes
to be encoded than unix.Dirent. Added warning logging in
encode() when it is discarding dirents.
Before:
```
$ docker run --runtime=runsc --rm -v /host/test:/test ubuntu bash -c 'time ls test > /dev/null'
real 0m7.826s
user 0m0.120s
sys 0m0.030s
```
After:
```
$ docker run --runtime=runsc --rm -v /host/test:/test ubuntu bash -c 'time ls test > /dev/null'
real 0m0.635s
user 0m0.130s
sys 0m0.040s
```
Updates #6665
PiperOrigin-RevId: 469546979
All atomic 64 bit ints are changed to atomicbitops.(Ui|I)nt64. A nogo checker
enforces that sync/atomic 64 bit functions are not called.
For reviewers: the interesting changes are in the atomicbitops and checkaligned
packages.
Why do this?
- It is very easy to accidentally use atomic values without sync/atomic funcs.
- We have checkatomics, but this is optional and is forgotten in several places.
- Using a type+checker to enforce this seems less error prone and simpler.
- We get NoCopy protection.
- Use of 64 bit atomics can break 32 bit builds. We have types to handle this
without any runtime cost, so we might as well use them.
PiperOrigin-RevId: 440473398
Since the socket type can be passed to Bind as well as Connect, it makes sense
to have a more general name.
Also consolidate the logic for converting between p9 and linux socket types.
Note that despite the name change, nothing in the 9p or LISA wire protocols
have changed, so there is no compatibility issues.
PiperOrigin-RevId: 430323611
This prevents a racing clunk() call from destroying the file while the callback
is running, leading to potential data races.
PiperOrigin-RevId: 426180506
EREMOTEIO is a more appropriate generic error for a remote procedure call (RPC)
failure on the gofer. EFAULT means bad address and can be misleading to the
application as it will denote a MM layer related issue.
PiperOrigin-RevId: 423990374
Earlier we were only locking the start directory's opMu while performing the
entire walk in MultiGetAttr. This means that a compromised client could
potentially delete and replace certain path components inside the start
directory while the walk is going on. Depending on the Server's File
implementation, this could lead to symlink based attacks.
Furthermore, calling WalkGetAttr requires the server to provide read
concurrency guarantee as documented while the DefaultMultiGetAttr
implementation was not providing.
PiperOrigin-RevId: 423218838
As described in the change, walking on a deleted file can be dangerous.
A malicious client could have replaced it with a hazardous symlink.
And depending on the file implementation, this could be dangerous. Some file
implementations might be using host paths for each operation and performing
host walks.
PiperOrigin-RevId: 422928261
This reduces the work required to do when a file is deleted. Just mark the path
node deleted. All fidRefs pointing to it will read the correct value then.
PiperOrigin-RevId: 421766678
This new RPC allows a client to be able to bind (and hence create) UDS on the
host filesystem. Following changes will add functionality to listen and accept
on such a bound UDS.
PiperOrigin-RevId: 420149313
It's safe to call SetAttr and Allocate on fsgofer because the
file path is not used to open the file, if needed.
Fixes#3654
PiperOrigin-RevId: 407149393
Change the linuxerr.ErrorFromErrno to return an error type and not
a *errors.Error type. The latter results in problems comparing to nil
as <nil><nil> != <nil><*errors.Error>.
In a follow up, there will be a change to remove *errors.Error.Errno(),
which will also encourage users to not use Errnos to reference linuxerr.
PiperOrigin-RevId: 406444419
This change mainly aims to define the semantics of communication for the LISAFS
(LInux SAndbox Filesystem) protocol. This protocol aims to replace 9P and
intends to bring some performance benefits with it.
Some of the notable differences from the p9 package are:
- Now the server implementations own the handlers.
- As a result, there is no verbose interface like `p9.File` that all servers
need to implement. Different implementations can extend their File
implementations to varying degrees without imposing those extensions to other
server implementations that might not have anything to do with those features.
- If a server implementation adds a new RPC message, other implementations are
not compelled to support it.
I wrote a benchmark `BenchmarkSendRecv` in connection_test.go which competes
with p9's `BenchmarkSendRecvChannel`. Running these on an AMD Milan machine
shows that lisafs is **45%** faster.
**With 9P**
goos: linux
goarch: amd64
pkg: gvisor/pkg/p9/p9
cpu: AMD EPYC 7B13 64-Core Processor
BenchmarkSendRecvLegacy-256 82830 14053 ns/op 633 B/op 23 allocs/op
BenchmarkSendRecvChannel-256 776971 1551 ns/op 184 B/op 6 allocs/op
**With lisafs**
goos: linux
goarch: amd64
pkg: pkg/lisafs/connection_test
cpu: AMD EPYC 7B13 64-Core Processor
BenchmarkSendRecv-256 1399610 853.5 ns/op 48 B/op 2 allocs/op
Fixes#5464
PiperOrigin-RevId: 397803163
The old implementation was mostly correct but error prone - making way for the
issue in question here. In its error path, it would leak the intermediate file
being walked. Each return/break needed explicit cleanup.
This change implements a more clean way to cleaning up intermediate directories.
If the code were to evolve to be more complex, it would still work.
PiperOrigin-RevId: 392102826
Jing Chen
gVisor bot
Ayush RanjanandgVisor bot
Koichi Shiraishi
Jing ChenandgVisor bot
Etienne PerotandgVisor bot
Andrei Vagin
Adin ScannellandgVisor bot
Kevin KrakauerandgVisor bot
Nicolas LacasseandgVisor bot
Fabricio VoznikaandgVisor bot
Zach KoopmansandgVisor bot
Jamie LiuandgVisor bot