kcmp() breaks loose

Posted Feb 12, 2021 16:28 UTC (Fri) by kleptog (subscriber, #1183)
In reply to: kcmp() breaks loose by daenzer
Parent article: kcmp() breaks loose

The extra return values are needed for scale if you have lots of FDs. With the extra return values the algorithm for comparing everything to everything else goes from O(n^2) to O(n log n). Given the obfuscation described above I don't see a problem returning the extra info. I can see value in tools like lsof being able to tell if files are the same, and they need to work with lots of FDs.

kcmp() breaks loose

Posted Feb 12, 2021 17:43 UTC (Fri) by nickodell (subscriber, #125165) [Link] (6 responses)

But you only need to perform a kcmp check if the two file descriptors refer to the same file. If they refer to different files, they cannot possibly be the same FD. Is there a situation where you have lots of FDs pointing to the *same* file?

kcmp() breaks loose

Posted Feb 12, 2021 18:35 UTC (Fri) by matthias (subscriber, #94967) [Link]

Checking which FDs belong to the same file will boil down to sort them (according to some criteria) and then compare them. Without some kind of sorting you will not end up with O(n*log(n)), but with pairwise testing, i.e. O(n^2). If kcmp() can provide an order (almost) for free, this is probably much cheaper than first constructing such an order in userspace and then using kcmp() only on those files that are the same.

kcmp() breaks loose

Posted Feb 12, 2021 18:40 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (3 responses)

Isn't it trivial to open a file multiple times?

int fd1 = open("/dev/null", "r");
int fd2 = open("/dev/null", "r");
int fd3 = dup(fd1);

kcmp() breaks loose

Posted Feb 12, 2021 23:35 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

More prosaically, in the case where you need to hibernate an entire container, lots of processes are likely to have certain files open at any given time:

* Whatever systemd/sysvinit/put-your-favorite-alternative-here has attached to the average daemon's stdin/stdout/stderr inside the container.
* /dev/null, as you say.
* /dev/urandom
* Certain files in /etc
* For forking servers, some kinds of sockets and/or pipes, including named fifos and Unix domain sockets.
* Log files and other /var crap.
* Probably half a dozen other things.

kcmp() breaks loose

Posted Feb 14, 2021 4:43 UTC (Sun) by dullfire (guest, #111432) [Link] (1 responses)

Incidentally: "/dev/null" is probably one of the very few cases where userspace won't actually care if it gets restored as the same file entry as another process or not.

kcmp() breaks loose

Posted Feb 14, 2021 13:11 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

While true, one still needs to know that `/dev/null` is the backing file of a given fd to know whether to "ignore" it or not when restoring.

kcmp() breaks loose

Posted Feb 12, 2021 18:57 UTC (Fri) by cjwatson (subscriber, #7322) [Link]

I'd have thought that it would be quite common for many processes to share FDs due to fork().