Am 08.05.24 um 13:51 schrieb David Laight:

From: Christian König

Sent: 07 May 2024 15:05

...

I actually have been telling people to (ab)use the epoll behavior to
check if two file descriptors point to the same underlying file when
KCMP isn't available.

In what way?

Something like this:

fd_e = epoll_create1(EPOLL_CLOEXEC);

tmp = dup(fd_A)
epoll_ctl(fd_e, EPOLL_CTL_ADD, tmp, ....);
dup2(fd_B, tmp);

/* If this return -EEXISTS then the fd_A and fd_B are pointing to the same struct file */
epoll_ctl(fd_e, EPOLL_CTL_ADD, tmp, ....);

close (tmp);
close (fd_e

You can add both fd to the same epoll fd.
Relying on the implicit EPOLL_CTL_DEL not happening until both fd are
closed is a recipe for disaster.
(And I can't see an obvious way of testing it.)

Q6/A6 on epoll(7) should always have had a caveat that it is an
'implementation detail' and shouldn't be relied on.
(it is written as a 'beware of' ...)

The other point is that there are two ways to get multiple fd that
reference the same underlying file.
dup() fork() etc share the file offset, but open("/dev/fd/n") adds
a reference count later and has a separate file offset.

No it doesn't.

Accessing /dev/fd/n or /proc/*/fd/n ideally accesses the same inode, but gives you a new struct file.

dup(), fork() etc.. make you actually reference the same struct file inside the kernel.

That turned out to be a rather important distinction when working with device drivers and DMA-buf.

Regards,
Christian.


I don't know which structure epoll is using, but I suspect it is
the former.
So it may not tell you what you want to know.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)