Age | Commit message (Collapse) | Author |
|
TcpPortReuseMultiThread creates lots of connections which result in
a lot of goroutines in the sentry. This can cause gotsan runs to
take really long and timeout. Increasing listen backlog and
reducing number of connections should help the connections complete
faster as well as reduce the number of goroutines that gotsan needs
to track.
PiperOrigin-RevId: 284046018
|
|
PiperOrigin-RevId: 284038840
|
|
PiperOrigin-RevId: 284033820
|
|
This change adds a type to represent the NDP Recursive DNS Server option, as
defined by RFC 8106 section 5.1.
PiperOrigin-RevId: 284005493
|
|
PiperOrigin-RevId: 283955946
|
|
Fixes #1207
PiperOrigin-RevId: 283914438
|
|
PiperOrigin-RevId: 283828423
|
|
Get rid of the SocketTest class, which is only extended by ReadvSocketTest.
Also, get rid of TCP sockets (which were unused anyway) from readv_socket.cc.
This is a very old test suite that isn't the right place for TCP loopback
tests.
PiperOrigin-RevId: 283672772
|
|
PiperOrigin-RevId: 283657725
|
|
If the socket is bound to ANY and connected to a loopback address,
getsockname() has to return the loopback address. Without this fix,
getsockname() returns ANY.
PiperOrigin-RevId: 283647781
|
|
PiperOrigin-RevId: 283630669
|
|
The code in rcv.consumeSegment incorrectly transitions to
CLOSED state from LAST-ACK before the final ACK for the FIN.
Further if receiving a segment changes a socket to a closed state
then we should not invoke the sender as the socket is now closed
and sending any segments is incorrect.
PiperOrigin-RevId: 283625300
|
|
PiperOrigin-RevId: 283613824
|
|
I have not seen a false positive stuck task yet.
Biggest offender was whitelistfs which is going away.
PiperOrigin-RevId: 283613064
|
|
PiperOrigin-RevId: 283610781
|
|
A few tests have their own ad-hoc implementations. Add a single common one.
PiperOrigin-RevId: 283601666
|
|
PiperOrigin-RevId: 283571456
|
|
There are two potential ways of sending a TOS byte with outgoing packets:
including a control message in sendmsg, or setting the IP_TOS/IPV6_TCLASS
socket options (for IPV4 and IPV6 respectively). This change lets hostinet
support the latter.
Fixes #1188
PiperOrigin-RevId: 283550925
|
|
This has adapted for use with bazel from the original commit
a26e93769ebefd82593a43e22fb13a09717cfa6d.
In particular, the style has been made consistent with internal python style
guidelines, and the packages (including the main entrypoint) have been
refactored in order to allow bazel testing targets.
PiperOrigin-RevId: 283484433
|
|
Allow non-unique UIDs in the bazel docker container in order to avoid failures
using host UIDs that are already present in the image.
Issue #1267
PiperOrigin-RevId: 283456369
|
|
We skipped it due to the issue in the golang scheduler
which has been fixed in go1.13.
PiperOrigin-RevId: 283432226
|
|
There are two potential ways of sending a TOS byte with outgoing packets:
including a control message in sendmsg, or setting the IP_TOS/IPV6_TCLASS
socket options (for IPV4 and IPV6 respectively). This change lets hostinet
support the former.
PiperOrigin-RevId: 283346737
|
|
PiperOrigin-RevId: 283345791
|
|
Separate out a test in udp_socket.cc that depends on <linux/errqueue.h> so the
rest of the tests can run on Fuchsia.
PiperOrigin-RevId: 283322633
|
|
This change does not introduce any new features, or modify existing ones.
This change tests handling TCP segments right away for connections that were
completed from a listening endpoint.
PiperOrigin-RevId: 282986457
|
|
This involves allowing getsockopt/setsockopt for the corresponding socket
options, as well as allowing hostinet to process control messages received from
the actual recvmsg syscall.
PiperOrigin-RevId: 282851425
|
|
PiperOrigin-RevId: 282828273
|
|
This allows writable proc and devices files to be opened with O_CREAT|O_TRUNC.
This is encountered most frequently when interacting with proc or devices files
via the command line.
e.g. $ echo 8192 1048576 4194304 > /proc/sys/net/ipv4/tcp_rmem
Also adds a test to test the behavior of open(O_TRUNC), truncate, and ftruncate
on named pipes.
Fixes #1116
PiperOrigin-RevId: 282677425
|
|
PiperOrigin-RevId: 282669859
|
|
PiperOrigin-RevId: 282667122
|
|
- Remove the Filesystem argument from DentryImpl.*Ref(); in general DentryImpls
that need the Filesystem for reference counting will probably also need it
for other interface methods that don't plumb Filesystem, so it's easier to
just store a pointer to the filesystem in the DentryImpl.
- Add a pointer to the VirtualFilesystem to Filesystem, which is needed by the
gofer client to disown dentries for cache eviction triggered by dentry
reference count changes.
- Rename FilesystemType.NewFilesystem to GetFilesystem; in some cases (e.g.
sysfs, cgroupfs) it's much cleaner for there to be only one Filesystem that
is used by all mounts, and in at least one case (devtmpfs) it's visibly
incorrect not to do so, so NewFilesystem doesn't always actually create and
return a *new* Filesystem.
- Require callers of FileDescription.Init() to increment Mount/Dentry
references. This is because the gofer client may, in the OpenAt() path, take
a reference on a dentry with 0 references, which is safe due to
synchronization that is outside the scope of this CL, and it would be safer
to still have its implementation of DentryImpl.IncRef() check for an
increment for 0 references in other cases.
- Add FileDescription.TryIncRef. This is used by the gofer client to take
references on "special file descriptions" (FDs for files such as pipes,
sockets, and devices), which use per-FD handles (fids) instead of
dentry-shared handles, for sync() and syncfs().
PiperOrigin-RevId: 282473364
|
|
This is required to test filesystems with a non-trivial implementation of
FilesystemImpl.Release(). Propagation isn't handled yet, and umount isn't yet
plumbed out to VirtualFilesystem.UmountAt(), but otherwise the implementation
of umount is believed to be correct.
- Move entering mountTable.seq writer critical sections to callers of
mountTable.{insert,remove}Seqed. This is required since umount(2) must ensure
that no new references are taken on the candidate mount after checking that
it isn't busy, which is only possible by entering a vfs.mountTable.seq writer
critical section before the check and remaining in it until after
VFS.umountRecursiveLocked() is complete. (Linux does the same thing:
fs/namespace.c:do_umount() => lock_mount_hash(),
fs/pnode.c:propagate_mount_busy(), umount_tree(), unlock_mount_hash().)
- It's not possible for dentry deletion to umount while only holding
VFS.mountMu for reading, but it's also very unappealing to hold VFS.mountMu
exclusively around e.g. gofer unlink RPCs. Introduce dentry.mu to avoid these
problems. This means that VFS.mountMu is never acquired for reading, so
change it to a sync.Mutex.
PiperOrigin-RevId: 282444343
|
|
With the ticks, the command `master` is actually be run and the output included
(which is nothing). This is confusing, as we actually mean to say "master" in
the description of the Go branch.
PiperOrigin-RevId: 282426081
|
|
PiperOrigin-RevId: 282401165
|
|
PiperOrigin-RevId: 282396322
|
|
PiperOrigin-RevId: 282382564
|
|
These are necessary for iptables to read and parse headers for packet filtering.
PiperOrigin-RevId: 282372811
|
|
Packets written via SOCK_RAW are guaranteed to have network headers, but not
transport headers. Check first whether there are enough bytes left in the packet
to contain a transport header before attempting to parse it.
PiperOrigin-RevId: 282363895
|
|
PiperOrigin-RevId: 282194656
|
|
Refer to golang mallocgc(), each time of allocating an object > 32 KB,
a gc will be triggered.
When we do readdir, sentry always passes 65535, which leads to a malloc
of 65535 * sizeof(p9.Direnta) > 32 KB.
Considering we already use slice append, let's avoid defining the
capability for this slide.
Command for test:
Before this change:
(container)$ time tree linux-5.3.1 > /dev/null
real 0m54.272s
user 0m2.010s
sys 0m1.740s
(CPU usage of Gofer: ~30 cores)
(host)$ perf top -p <pid-of-gofer>
42.57% runsc [.] runtime.gcDrain
23.41% runsc [.] runtime.(*lfstack).pop
9.74% runsc [.] runtime.greyobject
8.06% runsc [.] runtime.(*lfstack).push
4.33% runsc [.] runtime.scanobject
1.69% runsc [.] runtime.findObject
1.12% runsc [.] runtime.findrunnable
0.69% runsc [.] runtime.runqgrab
...
(host)$ mkdir test && cd test
(host)$ for i in `seq 1 65536`; do mkdir $i; done
(container)$ time ls test/ > /dev/null
real 2m10.934s
user 0m0.280s
sys 0m4.260s
(CPU usage of Gofer: ~1 core)
After this change:
(container)$ time tree linux-5.3.1 > /dev/null
real 0m22.465s
user 0m1.270s
sys 0m1.310s
(CPU usage of Gofer: ~1 core)
$ perf top -p <pid-of-gofer>
20.57% runsc [.] runtime.gcDrain
7.15% runsc [.] runtime.(*lfstack).pop
4.11% runsc [.] runtime.scanobject
3.78% runsc [.] runtime.greyobject
2.78% runsc [.] runtime.(*lfstack).push
...
(host)$ mkdir test && cd test
(host)$ for i in `seq 1 65536`; do mkdir $i; done
(container)$ time ls test/ > /dev/null
real 0m13.338s
user 0m0.190s
sys 0m3.980s
(CPU usage of Gofer: ~0.8 core)
Fixes #898
Signed-off-by: Jianfeng Tan <henry.tjf@antfin.com>
|
|
PiperOrigin-RevId: 282068093
|
|
The first use of time.Local (usually via time.Time.Date, et. al) performs
initialization of the local timezone, which involves open several tzdata files
from the host.
Since filter installation disallows open, we should explicitly force this
initialization rather than implicitly depending on the first logging (or other
time) call occurring before filter installation.
PiperOrigin-RevId: 282053121
|
|
This allows us to ensure that the correct port reservation is released.
Fixes #1217
PiperOrigin-RevId: 282048155
|
|
PiperOrigin-RevId: 282045221
|
|
PiperOrigin-RevId: 282023891
|
|
Signed-off-by: Bin Lu <bin.lu@arm.com>
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/891 from lubinszARM:pr_pagetable 2385de75a8662af3ab1ae289dd74dd0e5dcfaf66
PiperOrigin-RevId: 282013224
|
|
This is how it has to be accoding to the man page.
PiperOrigin-RevId: 281998068
|
|
PiperOrigin-RevId: 281795269
|
|
PiperOrigin-RevId: 281617882
|
|
Note that the Sentry still calls Truncate() on the file before calling Open.
A new p9 version check was added to ensure that the p9 server can handle the
the OpenTruncate flag. If not, then the flag is stripped before sending.
PiperOrigin-RevId: 281609112
|