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:	Mon, 16 Jul 2012 13:00:15 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Michael Kerrisk <mtk.manpages@...il.com>,
	Arve Hjønnevåg <arve@...roid.com>
Cc:	NeilBrown <neilb@...e.de>,
	Linux PM list <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Magnus Damm <magnus.damm@...il.com>, markgross@...gnar.org,
	Matthew Garrett <mjg@...hat.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	John Stultz <john.stultz@...aro.org>,
	Brian Swetland <swetland@...gle.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>, mtk@....net
Subject: Re: [PATCH] epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll events are ready

On Monday, July 16, 2012, Michael Kerrisk wrote:
> Arve, Rafael,
> 
> On Tue, May 1, 2012 at 7:33 AM, Arve Hjønnevåg <arve@...roid.com> wrote:
> > When an epoll_event, that has the EPOLLWAKEUP flag set, is ready, a
> > wakeup_source will be active to prevent suspend. This can be used to
> > handle wakeup events from a driver that support poll, e.g. input, if
> > that driver wakes up the waitqueue passed to epoll before allowing
> > suspend.
> 
> It's late it the -rc series,

Well, exactly. :-)

> but it strikes me that CAP_EPOLLWAKEUP is
> a poor name for the capability that governs the use of EPOLLWAKEUP.
> While on the one hand some capabilities are overloaded
> (https://lwn.net/Articles/486306/), on the other hand we should avoid
> adding individual capabilities for each new API feature (otherwise
> capabilities become administratively unwieldy).
> 
> This capability is not really about "EPOLL". It's about the ability to
> block system suspend. Therefore, IMO, a better name would be something
> like: CAP_BLOCK_SUSPEND. This name is better because there might be
> some other API feature that is later added that also has the effect of
> preventing system suspends, and we could reasonably govern that
> feature with the same capability.
> 
> Does that seem sensible to you? I can send a patch for the name change.

I'm not sure what Arve thinks about that, but I'd be fine with that.

Arve, what do you think?

Rafael
--
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