summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/socket
AgeCommit message (Collapse)Author
2020-08-29Merge release-20200818.0-88-g3bee863ae (automated)gVisor bot
2020-08-29Merge release-20200818.0-87-gf6ddcbefa (automated)gVisor bot
2020-08-28Fix kernfs.Dentry reference leak.Nicolas Lacasse
PiperOrigin-RevId: 329036994
2020-08-28Merge release-20200818.0-86-gd3057717d (automated)gVisor bot
2020-08-28Merge release-20200818.0-85-gd5787f628 (automated)gVisor bot
2020-08-28Merge release-20200818.0-84-gb4820e598 (automated)gVisor bot
2020-08-28Merge release-20200818.0-83-gbdd5996a7 (automated)gVisor bot
2020-08-28Merge release-20200818.0-80-g7bc9f9b47 (automated)gVisor bot
2020-08-28Merge release-20200818.0-79-g8ae0ab722 (automated)gVisor bot
2020-08-28Merge release-20200818.0-78-g421e35020 (automated)gVisor bot
2020-08-28Merge release-20200818.0-77-g84f04909c (automated)gVisor bot
2020-08-27Merge release-20200818.0-75-g57877b420 (automated)gVisor bot
2020-08-27Merge release-20200818.0-74-g6f8fb7e0d (automated)gVisor bot
2020-08-27Improve type safety for socket optionsGhanan Gowripalan
The existing implementation for {G,S}etSockOpt take arguments of an empty interface type which all types (implicitly) implement; any type may be passed to the functions. This change introduces marker interfaces for socket options that may be set or queried which socket option types implement to ensure that invalid types are caught at compile time. Different interfaces are used to allow the compiler to enforce read-only or set-only socket options. Fixes #3714. RELNOTES: n/a PiperOrigin-RevId: 328832161
2020-08-27Merge release-20200818.0-73-g29d528399 (automated)gVisor bot
2020-08-27Merge release-20200818.0-71-g26c588f06 (automated)gVisor bot
2020-08-27Merge release-20200818.0-69-gdc81eb9c3 (automated)gVisor bot
2020-08-27Add function to get error from a tcpip.EndpointGhanan Gowripalan
In an upcoming CL, socket option types are made to implement a marker interface with pointer receivers. Since this results in calling methods of an interface with a pointer, we incur an allocation when attempting to get an Endpoint's last error with the current implementation. When calling the method of an interface, the compiler is unable to determine what the interface implementation does with the pointer (since calling a method on an interface uses virtual dispatch at runtime so the compiler does not know what the interface method will do) so it allocates on the heap to be safe incase an implementation continues to hold the pointer after the functioon returns (the reference escapes the scope of the object). In the example below, the compiler does not know what b.foo does with the reference to a it allocates a on the heap as the reference to a may escape the scope of a. ``` var a int var b someInterface b.foo(&a) ``` This change removes the opportunity for that allocation. RELNOTES: n/a PiperOrigin-RevId: 328796559
2020-08-27Merge release-20200818.0-68-g01a35a2f1 (automated)gVisor bot
2020-08-27ip6tables: (de)serialize ip6tables structsKevin Krakauer
More implementation+testing to follow. #3549. PiperOrigin-RevId: 328770160
2020-08-27Merge release-20200818.0-67-g140ffb600 (automated)gVisor bot
2020-08-27Merge release-20200818.0-66-g32e7a54f7 (automated)gVisor bot
2020-08-27Merge release-20200818.0-65-ga4b1c6f5a (automated)gVisor bot
2020-08-27Merge release-20200818.0-63-g38895db3a (automated)gVisor bot
2020-08-26Merge release-20200818.0-61-g983a55aa0 (automated)gVisor bot
2020-08-26Merge release-20200818.0-60-g366f1a8f1 (automated)gVisor bot
2020-08-26Merge release-20200818.0-59-gb03e0ee80 (automated)gVisor bot
2020-08-26Merge release-20200818.0-58-g83a8b309e (automated)gVisor bot
2020-08-26Merge release-20200818.0-56-gdf3c105f4 (automated)gVisor bot
2020-08-25Use new reference count utility throughout gvisor.Dean Deng
This uses the refs_vfs2 template in vfs2 as well as objects common to vfs1 and vfs2. Note that vfs1-only refcounts are not replaced, since vfs1 will be deleted soon anyway. The following structs now use the new tool, with leak check enabled: devpts:rootInode fuse:inode kernfs:Dentry kernfs:dir kernfs:readonlyDir kernfs:StaticDirectory proc:fdDirInode proc:fdInfoDirInode proc:subtasksInode proc:taskInode proc:tasksInode vfs:FileDescription vfs:MountNamespace vfs:Filesystem sys:dir kernel:FSContext kernel:ProcessGroup kernel:Session shm:Shm mm:aioMappable mm:SpecialMappable transport:queue And the following use the template, but because they currently are not leak checked, a TODO is left instead of enabling leak check in this patch: kernel:FDTable tun:tunEndpoint Updates #1486. PiperOrigin-RevId: 328460377
2020-08-25Merge release-20200818.0-54-gcb573c8e0 (automated)gVisor bot
2020-08-25Merge release-20200818.0-51-gbee07a2d6 (automated)gVisor bot
2020-08-25Merge release-20200818.0-50-gc28bbee99 (automated)gVisor bot
2020-08-25Merge release-20200818.0-49-g1f0d23c7a (automated)gVisor bot
2020-08-25Merge release-20200818.0-47-g3cba0a41d (automated)gVisor bot
2020-08-25remove iptables sockopt special casesKevin Krakauer
iptables sockopts were kludged into an unnecessary check, this properly relegates them to the {get,set}SockOptIP functions. PiperOrigin-RevId: 328395135
2020-08-25Merge release-20200818.0-46-g3b2e50f53 (automated)gVisor bot
2020-08-25Merge release-20200818.0-45-gb0c53f847 (automated)gVisor bot
2020-08-25Merge release-20200818.0-44-gb83758cd8 (automated)gVisor bot
2020-08-25Merge release-20200818.0-42-gb26f7503b (automated)gVisor bot
2020-08-25Support SO_LINGER socket option.Nayana Bidari
When SO_LINGER option is enabled, the close will not return until all the queued messages are sent and acknowledged for the socket or linger timeout is reached. If the option is not set, close will return immediately. This option is mainly supported for connection oriented protocols such as TCP. PiperOrigin-RevId: 328350576
2020-08-25Merge release-20200818.0-40-g46485f9d4 (automated)gVisor bot
2020-08-25Merge release-20200818.0-39-gae332d96e (automated)gVisor bot
2020-08-25Fix TCP_LINGER2 behavior to match linux.Bhasker Hariharan
We still deviate a bit from linux in how long we will actually wait in FIN-WAIT-2. Linux seems to cap it with TIME_WAIT_LEN and it's not completely obvious as to why it's done that way. For now I think we can ignore that and fix it if it really is an issue. PiperOrigin-RevId: 328324922
2020-08-25Merge release-20200818.0-38-gc61f6fcf6 (automated)gVisor bot
2020-08-25Merge release-20200818.0-37-gf1821fdb6 (automated)gVisor bot
2020-08-24Merge release-20200818.0-34-g2b0b5e252 (automated)gVisor bot
2020-08-24Merge release-20200818.0-32-g339d266be (automated)gVisor bot
2020-08-22Merge release-20200810.0-90-g17bc5c1b0 (automated)gVisor bot
2020-08-21Merge release-20200810.0-87-gbd3383a7e (automated)gVisor bot
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 18:02:03 +0000