PacketData should not be modified and should be treated readonly because it
represents packet payload. The old DeleteFront method allowed callers to modify
the underlying buffer which should not be allowed.
Added a way to consume from the PacketData instead of deleting from it.
Updated call points to use that instead.
Reported-by: syzbot+faee5cb350f769a52d1b@syzkaller.appspotmail.com
PiperOrigin-RevId: 399268473
Earlier PacketBuffer.Clone() would do a shallow top level copy of the packet
buffer - which involved sharing the *buffer.Buffer between packets. Reading
or writing to the buffer in one packet would impact the other.
This caused modifications in one packet to affect the other's pkt.Views() which
is not desired. Change the clone to do a deeper copy of the underlying buffer
list and buffer pointers. The payload buffers (which are immutable) are still
shared. This change makes the Clone() operation more expensive as we now need to
allocate the entire buffer list.
Added unit test to test integrity of packet data after cloning.
Reported-by: syzbot+7ffff9a82a227b8f2e31@syzkaller.appspotmail.com
Reported-by: syzbot+7d241de0d9072b2b6075@syzkaller.appspotmail.com
Reported-by: syzbot+212bc4d75802fa461521@syzkaller.appspotmail.com
PiperOrigin-RevId: 390277713
Benchmark iperf3:
Before After
native->runsc 5.14 5.01 (Gbps)
runsc->native 4.15 4.07 (Gbps)
It did introduce overhead, mainly at the bridge between pkg/buffer and
VectorisedView, the ExtractVV method. Once endpoints start migrating away from
VV, this overhead will be gone.
Updates #2404
PiperOrigin-RevId: 373651666
This change changes `buffer.data` into a `[]byte`, from `[bufferSize]byte`.
In exchange, each `buffer` is now grouped together to reduce the number of
allocation. Plus, `View` now holds an embeded list of `buffer` (via `pool`) to
support the happy path which the number of buffer is small. Expect no extra
allocation for the happy path.
It is to enable the use case for PacketBuffer, which
* each `View` is small (way less than `defaultBufferSize`), and
* needs to dynamically transfer ownership of `[]byte` to `View`.
(to allow gradual migration)
PiperOrigin-RevId: 333197252
Fixes *.sh Java runtime tests, where splice()-ing from a pipe to /dev/zero
would not actually empty the pipe.
There was no guarantee that the data would actually be consumed on a splice
operation unless the output file's implementation of Write/PWrite actually
called VFSPipeFD.CopyIn. Now, whatever bytes are "written" are consumed
regardless of whether CopyIn is called or not.
Furthermore, the number of bytes in the IOSequence for reads is now capped at
the amount of data actually available. Before, splicing to /dev/zero would
always return the requested splice size without taking the actual available
data into account.
This change also refactors the case where an input file is spliced into an
output pipe so that it follows a similar pattern, which is arguably cleaner
anyway.
Updates #3576.
PiperOrigin-RevId: 328843954
Ayush Ranjan
Ting-Yu Wang
Dean Deng
Jamie Liu
Adin Scannell