Age | Commit message (Collapse) | Author |
|
|
|
This GitHub action has been failing since 4e963c9.
PiperOrigin-RevId: 349327675
|
|
PiperOrigin-RevId: 349314945
|
|
The buildkite syscall tests start with a lot of C++ warnings. This
cleans that up a little.
|
|
open() has to return ENXIO in this case.
O_PATH isn't supported by vfs1.
PiperOrigin-RevId: 348820478
|
|
PiperOrigin-RevId: 348720223
|
|
PiperOrigin-RevId: 348710397
|
|
PiperOrigin-RevId: 348696094
|
|
This condition was inverted in 360006d.
PiperOrigin-RevId: 348679088
|
|
Removes the period of time in which subseqeuent traffic to a Failed neighbor
immediately fails with ErrNoLinkAddress. A Failed neighbor is one in which
address resolution fails; or in other words, the neighbor's IP address cannot
be translated to a MAC address.
This means removing the Failed state for linkAddrCache and allowing transitiong
out of Failed into Incomplete for neighborCache. Previously, both caches would
transition entries to Failed after address resolution fails. In this state, any
subsequent traffic requested within an unreachable time would immediately fail
with ErrNoLinkAddress. This does not follow RFC 4861 section 7.3.3:
If address resolution fails, the entry SHOULD be deleted, so that subsequent
traffic to that neighbor invokes the next-hop determination procedure again.
Invoking next-hop determination at this point ensures that alternate default
routers are tried.
The API for getting a link address for a given address, whether through the link
address cache or the neighbor table, is updated to optionally take a callback
which will be called when address resolution completes. This allows `Route` to
handle completing link resolution internally, so callers of (*Route).Resolve
(e.g. endpoints) don’t have to keep track of when it completes and update the
Route accordingly.
This change also removes the wakers from LinkAddressCache, NeighborCache, and
Route in favor of the callbacks, and callers that previously used a waker can
now just pass a callback to (*Route).Resolve that will notify the waker on
resolution completion.
Fixes #4796
Startblock:
has LGTM from sbalana
and then
add reviewer ghanan
PiperOrigin-RevId: 348597478
|
|
...when performing source address selection for IPv6.
These are defined in RFC 6724 section 5 rule 6 (prefer matching label)
and rule 8 (use longest matching prefix).
This change also considers ULA of global scope instead of its own scope,
as per RFC 6724 section 3.1:
Also, note that ULAs are considered as global, not
site-local, scope but are handled via the prefix policy table as
discussed in Section 10.6.
Test: stack_test.TestIPv6SourceAddressSelectionScope
Startblock:
has LGTM from peterjohnston
and then
add reviewer brunodalbo
PiperOrigin-RevId: 348580996
|
|
Reported-by: syzbot+48c43f82fe7738fceae9@syzkaller.appspotmail.com
PiperOrigin-RevId: 348540796
|
|
PiperOrigin-RevId: 348530530
|
|
PiperOrigin-RevId: 348106699
|
|
PiperOrigin-RevId: 348092999
|
|
PiperOrigin-RevId: 348089449
|
|
If not set, the cached result is used even when runtime options
are changed, because they are not visible to blaze/bazel.
PiperOrigin-RevId: 348074339
|
|
PiperOrigin-RevId: 348056159
|
|
PiperOrigin-RevId: 348055514
|
|
Closes #5128
PiperOrigin-RevId: 348052446
|
|
This allows to find all containers inside a sandbox more efficiently.
This operation is required every time a container starts and stops,
and previously required loading *all* container state files to check
whether the container belonged to the sandbox.
Apert from being inneficient, it has caused problems when state files
are stale or corrupt, causing inavalability to create any container.
Also adjust commands `list` and `debug` to skip over files that fail
to load.
Resolves #5052
PiperOrigin-RevId: 348050637
|
|
Closes #5048
PiperOrigin-RevId: 348050472
|
|
Introduces the per-socket error queue and the necessary cmsg mechanisms.
PiperOrigin-RevId: 348028508
|
|
PiperOrigin-RevId: 347974624
|
|
Startblock:
has LGTM from asfez
and then
add reviewer tamird
PiperOrigin-RevId: 347928471
|
|
PiperOrigin-RevId: 347911316
|
|
PiperOrigin-RevId: 347890782
|
|
sacked_out is required in RACK to check the number of duplicate
acknowledgements during updating the reorder window. If there is no reordering
and the value for sacked_out is greater than the classic threshold value 3,
then reorder window is set to zero.
It is calculated by counting the number of segments sacked in the ACK and is
reduced when a cumulative ACK is received which covers the SACK blocks. This
value is set to zero when the connection enters recovery.
PiperOrigin-RevId: 347872246
|
|
PiperOrigin-RevId: 347864621
|
|
When the scaled receive window size > 65535 (max uint16), we advertise
the scaled value as 65535, but are not adjusting the saved receive
window value when doing so. This would keep our current window
calculation logic to be incorrect, as the saved receive window value
is different from what was advertised.
Fixes #4903
PiperOrigin-RevId: 347771340
|
|
RFC 2711 specifies that the router alert's length field is always 2
so we should make sure only 2 bytes are read from a router alert
option's data field.
Test: header.TestIPv6OptionsExtHdrIterErr
PiperOrigin-RevId: 347727876
|
|
PiperOrigin-RevId: 347720083
|
|
Startblock:
has LGTM from asfez
and then
add reviewer brunodalbo
PiperOrigin-RevId: 347716242
|
|
PiperOrigin-RevId: 347711998
|
|
PiperOrigin-RevId: 347706953
|
|
syzkaller reported the closing of a nil channel. This is only possible when the
AIOContext was destroyed twice.
Some scenarios that could lead to this:
- It died and then some called aioCtx.Prepare() on it and then killed it again
which could cause the double destroy. The context could have been destroyed
in between the call to LookupAIOContext() and Prepare().
- aioManager was destroyed but it did not update the contexts map. So
Lookup could still return a dead AIOContext and then someone could call
Prepare on it and kill it again.
So added a check in aioCtx.Prepare() for the context being dead. This will
prevent a dead context from resurrecting.
Also refactored code to destroy the aioContext consistently. Earlier we were not
munmapping the aioContexts that were destroyed upon aioManager destruction.
Reported-by: syzbot+ef6a588d0ce6059991d2@syzkaller.appspotmail.com
PiperOrigin-RevId: 347704347
|
|
We want to make the recvmsg syscall to the host regardless of if the dst is
empty or not so that:
- Host can populate the control messages if necessary.
- Host can return sender address.
- Host can return appropriate errors.
Earlier because we were using the IOSequence.CopyOutFrom() API, the usermem
package does not even call the Reader function if the destination is empty (as
an optimization).
PiperOrigin-RevId: 347684566
|
|
PiperOrigin-RevId: 347671070
|
|
- Skip chown call in case owner change is not needed
- Skip filepath.Clean() calls when joining paths
- Pass unix.Stat_t by value to reduce runtime.duffcopy calls.
This change allows for better inlining in localFile.walk().
Change Baseline Improvement
BenchmarkWalkOne-6 2912 ns/op 3082 ns/op 5.5%
BenchmarkCreate-6 15915 ns/op 19126 ns/op 16.8%
BenchmarkCreateDiffOwner-6 18795 ns/op 19741 ns/op 4.8%
PiperOrigin-RevId: 347667833
|
|
PiperOrigin-RevId: 347660920
|
|
PiperOrigin-RevId: 347650354
|
|
Also, drop the pull_request template, since this has not proved to be
helpful, and just results in a commit message the includes the list.
PiperOrigin-RevId: 347636507
|
|
|
|
packetEPs may get into a state that `len < cap`, casuing append() modifying the
original slice storage.
Reported-by: syzbot+978dd0e9c2600ab7a76b@syzkaller.appspotmail.com
PiperOrigin-RevId: 347634351
|
|
|
|
PiperOrigin-RevId: 347532687
|
|
|
|
There are surprisingly few syscall tests that run with hostinet. For example
running the following command only returns two results:
`bazel query test/syscalls:all | grep hostnet`
I think as a result, as our control messages evolved, hostinet was left
behind. Update it to support all control messages netstack supports.
This change also updates sentry's control message parsing logic to make it up to
date with all the control messages we support.
PiperOrigin-RevId: 347508892
|
|
|
|
PiperOrigin-RevId: 347437786
|