linux-kernel - Re: [RFC][PATCH] epoll: allow EPOLLWAKEUP flag if PM

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Nov 2013 11:24:05 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Amit Pundir <amit.pundir@...aro.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
	Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [RFC][PATCH] epoll: allow EPOLLWAKEUP flag if PM_SLEEP is enabled

On Mon, Nov 11, 2013 at 1:22 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Monday, November 11, 2013 11:26:31 PM Amit Pundir wrote:
>> 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.
>
> So the error value should not be ENOMEM.

Right, ENOMEM is clearly wrong. I think its just not clear what the
right thing to do is.


>> 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.
>
> Which is a different thing.

Well, in the case of the process not having sufficient capabilities,
-EPERM seems like a reasonable return value.  But instead the wakeup
flag is silently dropped.  That's why Amit is asking if dropping the
wakeup flag is also the right approach for the !PM_SLEEP case instead
of returning EINVAL.

Dropping the wakeup flag is the easier solution, since we don't have
to then go through all the userspace code and have it handle the error
and resubmit without the wakeup flag.  I suspect this was the same
consideration for the decision in the insufficient capabilities case,
but I don't really know.

thanks
-john
--
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/