lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 24 Feb 2009 15:36:24 -0500
From:	Tony Battersby <tonyb@...ernetics.com>
To:	Eric Dumazet <dada1@...mosbay.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Davide Libenzi <davidel@...ilserver.org>,
	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] [2.6.29] epoll: fix for epoll_wait sometimes returning
 events on closed fds

Eric Dumazet wrote:
> I believe Davide already said that close() meant the real close, not
> the file descriptor freeing. 
>
> And current documentations clearly states it, maybe your man page is too old ?
>
> ---
>
> Q6  Will closing a file descriptor cause it to be removed from all epoll sets automatically?
>
> A6  Yes,  but  be  aware  of  the  following  point.   A  file descriptor is a reference to an open file description (see
>     open(2)).  Whenever a descriptor is duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, or fork(2), a new file descriptor  referring  to  the same open file description is created.  An open file description continues to exist until all
>     file descriptors referring to it have been closed.  A file descriptor is removed from an epoll set only after all the
>     file  descriptors  referring to the underlying open file description have been closed (or before if the descriptor is
>     explicitly removed using epoll_ctl() EPOLL_CTL_DEL).  This means that even after a file descriptor that is part of an
>     epoll set has been closed, events may be reported for that file descriptor if other file descriptors referring to the
>     same underlying file description remain open.
>
>
>
>
>   
Ugh.  The manpage on Ubuntu 8.04 that I am using doesn't contain this
lengthy caveat; it just says "A6     Yes."  To me it sounds like the
(newer) manpage is just documenting away a bug/misfeature with "It's
supposed to do that.  Gives it character." rather than expecting the
kernel developers to make the API behave in a more reasonable way.  Just
my opinion; others may agree or disagree.

If the officially-sanctioned epoll interface is supposed to report
events on fds that were added, duped, and then the original fd closed,
then my patch will probably break that behavior.  In that case, it will
be more difficult to fix problem that my patch is trying to fix (which
doesn't involve dup, dup2, fcntl, fork, etc.).  So before I try to think
of another way, let me ask: do we want to fix the problem that I am
reporting, or just document it away in the manpage as (apparently) has
been done before?

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ