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)