I stumbled upon ENOMEM error from epoll_ctl() while bringing up Android-4.4 on a device that does not yet support PM_SLEEP. While looking into the problem, I found that ep_create_wakeup_source() reports ENOMEM if wakeup_source_register() returns NULL. ep_create_wakeup_source() assumes that NULL is only returned if we run into ENOMEM but NULL is also returned when CONFIG_PM_SLEEP is disabled. If CONFIG_PM_SLEEP is disabled, stripping the EPOLLWAKEUP flag seems to be a reasonable solution here, allowing the call to succeed, while dropping the wakeup logic. While returning EINVAL might also be a good solution, stripping the flag seems to follow the established behavior, as is done when the process doesn't have sufficient capabilities to block suspend. I'd appreciate any thoughts or feedback! Signed-off-by: Amit Pundir <amit.pundir@xxxxxxxxxx> --- fs/eventpoll.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 473e09d..7a83079 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1820,7 +1820,8 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd, goto error_tgt_fput; /* Check if EPOLLWAKEUP is allowed */ - if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND)) + if ((epds.events & EPOLLWAKEUP) && + (!capable(CAP_BLOCK_SUSPEND) || !IS_ENABLED(CONFIG_PM_SLEEP))) epds.events &= ~EPOLLWAKEUP; /* -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
