Age | Commit message (Collapse) | Author |
|
PiperOrigin-RevId: 357106080
|
|
PiperOrigin-RevId: 357090170
|
|
PiperOrigin-RevId: 357015186
|
|
PiperOrigin-RevId: 356868412
|
|
The limits for snd/rcv buffers for unix domain socket is controlled by the
following sysctls on linux
- net.core.rmem_default
- net.core.rmem_max
- net.core.wmem_default
- net.core.wmem_max
Today in gVisor we do not expose these sysctls but we do support setting the
equivalent in netstack via stack.Options() method. But AF_UNIX sockets in gVisor
can be used without netstack, with hostinet or even without any networking stack
at all. Which means ideally these sysctls need to live as globals in gVisor.
But rather than make this a big change for now we hardcode the limits in the
AF_UNIX implementation itself (which in itself is better than where we were
before) where it SO_SNDBUF was hardcoded to 16KiB. Further we bump the initial
limit to a default value of 208 KiB to match linux from the paltry 16 KiB we use
today.
Updates #5132
PiperOrigin-RevId: 356665498
|
|
PiperOrigin-RevId: 356450303
|
|
According to vfs.FilesystemImpl.RenameAt documentation:
- If the last path component in rp is "." or "..", and opts.Flags contains
RENAME_NOREPLACE, RenameAt returns EEXIST.
- If the last path component in rp is "." or "..", and opts.Flags does not
contain RENAME_NOREPLACE, RenameAt returns EBUSY.
Reported-by: syzbot+6189786e64fe13fe43f8@syzkaller.appspotmail.com
PiperOrigin-RevId: 355959266
|
|
PiperOrigin-RevId: 355675900
|
|
Our implementation of vfs.CheckDeleteSticky was not consistent with Linux,
specifically not consistent with fs/linux.h:check_sticky().
One of the biggest differences was that the vfs implementation did not
allow the owner of the sticky directory to delete files inside it that belonged
to other users.
This change makes our implementation consistent with Linux.
Also adds an integration test to check for this. This bug is also present in
VFS1.
Updates #3027
PiperOrigin-RevId: 355557425
|
|
When file is regular and metadata cache is authoritative, metadata lock
is taken. The code deadlocks trying to acquire the metadata lock
again to update time stampts.
PiperOrigin-RevId: 354584594
|
|
This makes it possible to add data to types that implement tcpip.Error.
ErrBadLinkEndpoint is removed as it is unused.
PiperOrigin-RevId: 354437314
|
|
Fixes #3027 as there is just 1 writable user using OrderedChildren's rename,
unlink and rmdir (kernfs.syntheticDirectory) but it doesn't support the sticky
bit yet.
Fuse which is the other writable user implements its own Inode operations.
PiperOrigin-RevId: 354386522
|
|
Contrary to the comment on the socket test, the failure was due to an issue
with goferfs rather than kernfs.
PiperOrigin-RevId: 353918021
|
|
Fixes #5113.
PiperOrigin-RevId: 353313374
|
|
PiperOrigin-RevId: 352908368
|
|
PiperOrigin-RevId: 352904728
|
|
Fixes #5263
PiperOrigin-RevId: 352903844
|
|
Return EEXIST when overwritting a file as long as the caller has exec
permission on the parent directory, even if the caller doesn't have
write permission.
Also reordered the mount write check, which happens before permission
is checked.
Closes #5164
PiperOrigin-RevId: 351868123
|
|
These are primarily simplification and lint mistakes. However, minor
fixes are also included and tests added where appropriate.
PiperOrigin-RevId: 351425971
|
|
Reported-by: syzbot+814105309d2ae8651084@syzkaller.appspotmail.com
PiperOrigin-RevId: 350159452
|
|
Syzkaller discovered this bug in pipefs by doing something quite strange:
creat(&(0x7f0000002a00)='./file1\x00', 0x0)
mount(&(0x7f0000000440)=ANY=[], &(0x7f00000002c0)='./file1\x00', &(0x7f0000000300)='devtmpfs\x00', 0x20000d, 0x0)
creat(&(0x7f0000000000)='./file1/file0\x00', 0x0)
This can be reproduced with:
touch mymount
mkfifo /dev/mypipe
mount -o ro -t devtmpfs devtmpfs mymount
echo 123 > mymount/mypipe
PiperOrigin-RevId: 349687714
|
|
PiperOrigin-RevId: 348092999
|
|
PiperOrigin-RevId: 348056159
|
|
Closes #5128
PiperOrigin-RevId: 348052446
|
|
PiperOrigin-RevId: 347706953
|
|
PiperOrigin-RevId: 347671070
|
|
PiperOrigin-RevId: 347091372
|
|
PiperOrigin-RevId: 347047550
|
|
PiperOrigin-RevId: 346923826
|
|
Don't propagate arbitrary golang errors up from fusefs because errors
that don't map to an errno result in a sentry panic.
Reported-by: syzbot+697cb635346e456fddfc@syzkaller.appspotmail.com
PiperOrigin-RevId: 346220306
|
|
Fixes #4991
PiperOrigin-RevId: 345800333
|
|
These options allow overriding the signal that gets sent to the process when
I/O operations are available on the file descriptor, rather than the default
`SIGIO` signal. Doing so also populates `siginfo` to contain extra information
about which file descriptor caused the event (`si_fd`) and what events happened
on it (`si_band`). The logic around which FD is populated within `si_fd`
matches Linux's, which means it has some weird edge cases where that value may
not actually refer to a file descriptor that is still valid.
This CL also ports extra S/R logic regarding async handler in VFS2.
Without this, async I/O handlers aren't properly re-registered after S/R.
PiperOrigin-RevId: 345436598
|
|
Previous experience has shown that these types of wrappers tends to create two
kinds of problems: hidden allocations (e.g. each call to
FileReadWriteSeeker.Read/Write allocates a usermem.BytesIO on the heap) and
hidden lock ordering problems (e.g. VFS1 splice deadlocks). Since this is only
needed by fsimpl/verity, move it there.
PiperOrigin-RevId: 345377830
|
|
Refactor some utilities and rename some others for clarity.
PiperOrigin-RevId: 345247836
|
|
PiperOrigin-RevId: 345178956
|
|
The bug has been fixed.
PiperOrigin-RevId: 344088206
|
|
PiperOrigin-RevId: 343959348
|
|
1. Add getD/getDentry methods to avoid long casting line in each test
2. Factor all calls to vfs.OpenAt/UnlinkAt/RenameAt on lower filesystem
to their own method (for both lower file and lower Merkle file) so
the tests are more readable
3. Add descriptive test names for delete/remove tests
PiperOrigin-RevId: 343540202
|
|
PiperOrigin-RevId: 343398191
|
|
If a kernfs user does not cache dentries, then cacheLocked will destroy the
dentry. The current DecRef implementation will be racy in this case as the
following can happen:
- Goroutine 1 calls DecRef and decreases ref count from 1 to 0.
- Goroutine 2 acquires d.fs.mu for reading and calls IncRef and increasing the
ref count from 0 to 1.
- Goroutine 2 releases d.fs.mu and calls DecRef again decreasing ref count from
1 to 0.
- Goroutine 1 now acquires d.fs.mu and calls cacheLocked which destroys the
dentry.
- Goroutine 2 now acquires d.fs.mu and calls cacheLocked to find that the dentry
is already destroyed!
Earlier we would panic in this case, we could instead just return instead of
adding complexity to handle this race. This is similar to what the gofer client
does.
We do not want to lock d.fs.mu in the case that the filesystem caches dentries
(common case as procfs and sysfs do this) to prevent congestion due to lock
contention.
PiperOrigin-RevId: 343229496
|
|
PiperOrigin-RevId: 343196927
|
|
PiperOrigin-RevId: 342992936
|
|
If we don't hold a reference, the dentry can be destroyed by another thread.
Reported-by: syzbot+f2132e50060c41f6d41f@syzkaller.appspotmail.com
PiperOrigin-RevId: 342951940
|
|
Also add the lock order for verity fs, and add a lock to protect dentry
hash.
PiperOrigin-RevId: 342946537
|
|
This is actually just b/168751672 again; cl/332394146 was incorrectly reverted
by cl/341411151. Document the reference holder to reduce the likelihood that
this happens again.
Also document a few other bugs observed in the process.
PiperOrigin-RevId: 342339144
|
|
PiperOrigin-RevId: 342221309
|
|
PiperOrigin-RevId: 342214859
|
|
kernel.Task can only be used as context.Context by that Task's task goroutine.
This is violated in at least two places:
- In any case where one thread accesses the /proc/[tid] of any other thread,
passing the kernel.Task for [tid] as the context.Context is incorrect.
- Task.rebuildTraceContext() may be called by Kernel.RebuildTraceContexts()
outside the scope of any task goroutine.
Fix these (as well as a data race on Task.traceContext discovered during the
course of finding the latter).
PiperOrigin-RevId: 342174404
|
|
children names map can be used to verify whether a child is expected
during walking, so that we can detect unexpected modifications that
deleted/renamed both the target file and the corresponding merkle tree
file.
PiperOrigin-RevId: 342170715
|
|
This reduces confusion with context.Context (which is also relevant to
kernel.Tasks) and is consistent with existing function kernel.LoadTaskImage().
PiperOrigin-RevId: 342167298
|