How does NewMapFromFD() work?

[notrobpike]

kernel 5.15 (Ubuntu 22.04 LTS)
go1.21.7
cilium/ebpf@0.13.2

The godoc says not to reuse the original fd after calling it.

Code inspection shows that a dup() is done and the original is closed. per @ti-mo here, this is to prevent the original fd from being closed "underneath us". I disagree with that but what do I know? (new fd can still be closed underneath you, but I digress.)

I understand that interacting with maps from userspace involves referencing a fd help open by the process. So therefore, I expect that the godoc for NewMapFromFD() means that the map you got the fd from shouldn't be used anymore. The dup/close sequence in the code seems consistent with that, and with what @ti-mo said. I may misunderstand and that's why I think it's consistent.

In this code, I expected a fail at L32, but instead I get a fail at L35. strace doesn't show a close or dup call, except there is a close where cilium is creating a "feature_test" map behind the scenes and then closing it.

What happened to the close from NewMapFromFD()? This should have occurred in internal/sys NewFD()

package main

import (
	"fmt"
	"log"

	"github.com/cilium/ebpf"
)

func main() {
	key := uint32(0)
	val := uint32(0)
	spec := ebpf.MapSpec{
		Name:       "test_map",
		Type:       ebpf.LRUHash,
		KeySize:    4,
		ValueSize:  4,
		MaxEntries: uint32(4096),
	}
	hashMap, err := ebpf.NewMap(&spec)
	if err != nil {
		log.Fatalln("Could not create map:", err)
	}
	fd := hashMap.FD()
	fmt.Println(fd)
	newMap, err := ebpf.NewMapFromFD(fd)
	if err != nil {
		log.Fatalln(err)
	}
	fmt.Println(hashMap.FD())
	if err := hashMap.Update(&key, &val, ebpf.UpdateNoExist); err != nil {
		log.Fatalln(err) // expected fail here due to referencing an old fd
	}
	if err := newMap.Update(&key, &val, ebpf.UpdateNoExist); err != nil {
		log.Fatalln(err) // got EEXIST here, as newMap also shares fd 3.
	}
}

bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=4, max_entries=1, map_flags=0, inner_map_fd=0, map_name="feature_test", map_ifindex=0, btf_fd=0, btf_key_type_id=0, btf_value_type_id=0, btf_vmlinux_value_type_id=0, map_extra=0}, 72) = 3
close(3)                                = 0
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_LRU_HASH, key_size=4, value_size=4, max_entries=4096, map_flags=0, inner_map_fd=0, map_name="test_map", map_ifindex=0, btf_fd=0, btf_key_type_id=0, btf_value_type_id=0, btf_vmlinux_value_type_id=0, map_extra=0}, 72) = 3
write(1, "3\n", 23
)                      = 2
bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=3, info_len=88 => 80, info=0xc00008c120}}, 16) = 0
write(1, "3\n", 23
)                      = 2
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0xc0000a210c, value=0xc0000a2120, flags=BPF_NOEXIST}, 32) = 0
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0xc0000a210c, value=0xc0000a2120, flags=BPF_NOEXIST}, 32) = -1 EEXIST (File exists)

[ti-mo]

@notrobpike Scratch what I said about NewMapFromFD calling dup() and close(), I didn't have the code in front of me. We have a few abstractions that take a raw fd from the caller and dup() it, but I can't find any cases where we close a user-provided fd.

The reason we warn the caller about not reusing a raw fd after passing it into e.g. NewMapFromFD() is that the underlying fd becomes bound to the lifecycle of the *Map from there on out. If the Map gets garbage collected or explicitly Close()d, that will invalidate the original fd.

[notrobpike]

thanks for following through with me here @ti-mo . yeah i see it now, it doesn't necessarily close fd. only if the fd is 0.