Re: [PATCH v2 1/2] epoll: introduce POLLFREE to flush ->signalfd_wqhbefore kfree()

[Andy Lutomirski]

On 02/24/2012 11:07 AM, Oleg Nesterov wrote:
> This patch is intentionally incomplete to simplify the review.
> It ignores ep_unregister_pollwait() which plays with the same wqh.
> See the next change.
> 
> epoll assumes that the EPOLL_CTL_ADD'ed file controls everything
> f_op->poll() needs. In particular it assumes that the wait queue
> can't go away until eventpoll_release(). This is not true in case
> of signalfd, the task which does EPOLL_CTL_ADD uses its ->sighand
> which is not connected to the file.
> 
> This patch adds the special event, POLLFREE, currently only for
> epoll. It expects that init_poll_funcptr()'ed hook should do the
> necessary cleanup. Perhaps it should be defined as EPOLLFREE in
> eventpoll.

> [lots of kernel-internal technical stuff]

I have a bunch of userspace code that uses signalfd via epoll.  Does
this affect the ABI?  Will epoll_wait ever set POLLFREE?  Does
EPOLL_CTL_MOD accept POLLFREE?

IOW, from a userspace point of view, wtf does this do?  I don't want to
end up with another POLLRDHUP-like* special case in my code.

--Andy

* IMO the right fix would have been to make EPOLLET fire POLLIN again
when the read point advances to EOF but before EOF is actually seen when
read() returns zero.  Then POLLRDHUP would be unnecessary and user code
could do its thing in blissful ignorance.  I hope POLLFREE isn't like that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/