Age | Commit message (Collapse) | Author |
|
|
|
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
|
|
|
|
PiperOrigin-RevId: 342161204
|
|
|
|
PiperOrigin-RevId: 341982672
|
|
|
|
This will help to debug:
https://syzkaller.appspot.com/bug?id=0d717bd7028dceeb4b38f09aab2841c398b41d81
PiperOrigin-RevId: 341458715
|
|
|
|
This lets us avoid treating a value of 0 as one reference. All references
using the refsvfs2 template must call InitRefs() before the reference is
incremented/decremented, or else a panic will occur. Therefore, it should be
pretty easy to identify missing InitRef calls during testing.
Updates #1486.
PiperOrigin-RevId: 341411151
|
|
|
|
This is necessary to allow writes to files opened with O_WRONLY to go through
host FDs.
PiperOrigin-RevId: 341174509
|
|
|
|
This is consistent with what Linux does. This was causing a PHP runtime test
failure. Fixed it for VFS2.
PiperOrigin-RevId: 341155209
|
|
|
|
We can reuse information about whether a whiteout exists on a given file path
from stepLocked when creating a file at that path. This helps save an Unlink
call to the upper filesystem if the whiteout does NOT exist (common case).
Plumbs this information from lookupLocked() -> getChildLocked() -> stepLocked().
This also helped save a Lookup in RenameAt().
Fixes #1199
PiperOrigin-RevId: 341105351
|
|
|
|
The root dentry was not created through Inode.Lookup, so we should not
release a reference even if inode.Keep() is true.
PiperOrigin-RevId: 341103220
|
|
PiperOrigin-RevId: 340536306
|
|
|
|
The default pipe size already matched linux, and is unchanged.
Furthermore `atomicIOBytes` is made a proper constant (as it is in Linux). We
were plumbing usermem.PageSize everywhere, so this is no functional change.
PiperOrigin-RevId: 340497006
|
|
|
|
Don't return the filename, since it can already be determined by the caller.
This was causing a panic in RenameAt, which relied on the name to be nonempty
even if the error was EEXIST.
Reported-by: syzbot+e9f117d000301e42361f@syzkaller.appspotmail.com
PiperOrigin-RevId: 340381946
|
|
PiperOrigin-RevId: 340275942
|
|
|