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]
Message-ID: <CALAqxLXL_rE=1BanFyR=4iTLsSoZttAu72aXraQnWBRr9HxYvw@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ