LWN: Comments on "Namespace reference counting and listns()"

How is this an API quirk? It's normal and expected behaviour with file-handles in Unix.

corbet — Wed, 05 Nov 2025 15:46:33 +0000

They are new with regard to namespaces, but file handles are a fairly old concept; I think they had their origin with NFS many years ago.

How is this an API quirk? It's normal and expected behaviour with file-handles in Unix.

paulj — Wed, 05 Nov 2025 15:26:44 +0000

I stand corrected. So these are a new class of handles, distinct from file descriptors, as per open_by_handle_at, and with a separate struct in the kernel it appears. I didn't realise. Thanks.

How is this an API quirk? It's normal and expected behaviour with file-handles in Unix.

corbet — Wed, 05 Nov 2025 13:55:26 +0000

Please, do not confuse file handles with file descriptors. A file handle is best thought of, perhaps, as an alternative name for the file. Just as the possession of a file's name does not cause its persistence, holding a file handle doesn't keep a file around.

How is this an API quirk? It's normal and expected behaviour with file-handles in Unix.

paulj — Wed, 05 Nov 2025 11:19:08 +0000

> That is the sort of API quirk that nobody asked for and nobody intended to implement.

Isn't it entirely the expected and long-standing behaviour of filehandles? A user-space programme can acquire a file-handle for something, the object itself can be removed from any indexes that make it visible (e.g., where the file-handle references a file, the programme itself or another can delete the file-name entr{y,ies} from the filesystem), and the programme could if it wishes make the referred to object visible again (adding a file-name in the filesystem again for the file-handle).

This is entirely normal, expected behaviour with file-handles, the referenced object, and whatever generally queryable indices there may be of such objects (e.g. filesystems).

I think, at best, the author means this *normal behaviour* is - for some reason - not desired for namespaces. And the reason why namespaces are special, compared to other objects, should then have been explained.

Finally!

SPYFF — Wed, 05 Nov 2025 08:41:31 +0000

I'm glad someone is walking the walk and introducing a simple yet powerful API for listing namespaces. Christian is doing great work, and this will be a game changer for many hacky applications. Time to time, I have to list network namespaces, but iproute2's ip netns only lists the ones it created with ip, not the ones created with, for example, unshare -n.

Namespace namespace

Fowl — Tue, 04 Nov 2025 08:24:08 +0000

Beginning my count down until we get a namespace for namespaces ;p

(I guess figuring that out was part of why this wasn’t a /dev file or directory)

Give the man a medal

mathstuf — Tue, 04 Nov 2025 03:58:41 +0000

It is commendable. If reviewers were more…discerning about such things, maybe more would do so. Same goes for the "rigorously undocumented" features noted in the merge window roundups here.

Give the man a medal

smurf — Mon, 03 Nov 2025 21:19:56 +0000

> patches 22 through 72 are all tests

If only everybody was that diligent.

Pagination in syscalls?

johill — Mon, 03 Nov 2025 16:55:39 +0000

Every netlink dump also has pagination.

In netlink, to solve this, a "generation" number is included in each partial dump (and updated by other code if the list changes.) If it changed anywhere while you were dumping, you know the list might be incomplete or list stale objects. In many cases, this doesn't really matter since an object might as well disappear just _after_ you created the list, etc.

Pagination in syscalls?

corbet — Mon, 03 Nov 2025 16:44:55 +0000

getdents() has had pagination since forever; it's pretty much necessary for any interface that could return an arbitrary amount of data.

Pagination in syscalls?

hDF — Mon, 03 Nov 2025 16:34:43 +0000

Not an expert, but I haven't seen pagination in syscalls before. What happens when the list of namespaces changes in between the `listns()` calls?