Hello, On Wed, Aug 07, 2019 at 12:00:37PM -0700, Andrew Morton wrote: > OK, but why is recycling a problem? For example, file descriptors > recycle as aggressively as is possible, and that doesn't cause any > trouble. Presumably recycling is a problem with cgroups because of > some sort of stale reference problem? Oh, because there are use cases where the consumers are detached from the lifetime synchronization. In this example, the benefit of using IDs is that memcgs don't need to pin foreign bdi_wb's and just look up and verify when it wants to flush them. If we use pointers, we have to pin the objects which then requires either shooting down those references with timers or somehow doing reverse lookup to shoot them down when bdi_wb is taken offline. If we use IDs which can be recycling aggressively, there can be pathological cases where remote flushes are issued on the wrong target possibly repeatedly, which may or may not be a real problem. For cgroup ID, the problem is more immediate. We give out the IDs to userspace and there is no way to shoot those references down when the cgroup goes away and the ID gets recycled, so when the user comes back and asks "I want to attach this bpf program to the cgroup identified with this ID", we can end up attaching it to the wrong cgroup if we recycle IDs. cgroup ended up with two separate IDs, which is kinda dumb. tl;dr is that it's either cumbersome or impossible to synchronize the users of these IDs, so if they get recycled, they end up identifying the wrong thing. Thanks. -- tejun
