Rename CAP_EPOLLWAKEUP to CAL_BLOCK_SUSPEND

PATCH In review Michael Kerrisk 3 participants 5 messages Jul 17, 2012

Subsystems (2)

VFS Capabilities

lore

Share & tools

lore

Michael Kerrisk

author

2012-07-17 04:37 UTC #0 lore raw

PATCH 1/1 Rename CAP_EPOLLWAKEUP to CAL_BLOCK_SUSPEND

Rafael,

As discussed in
http://thread.gmane.org/gmane.linux.kernel/1249726/focus=1288990,
the capability introduced in 4d7e30d98939a0340022ccd49325a3d70f7e0238 to govern EPOLLWAKEUP seems misnamed: this capability is about governing the ability to suspend the system, not using a particular API flag (EPOLLWAKEUP). We should make the name of the capability more general to encourage reuse in related cases. (Whether or not this capability should also be used to govern the use of /sys/power/wake_lock is a question that needs to be separately resolved.)

This patch renames the capability to CAP_BLOCK_SUSPEND. In order to ensure that the old capability name doesn't make it out into the wild, could you please apply and push up the tree to ensure that it is incorporated for the 3.5 release.

Thanks,

Michael

Signed-off-by Michael Kerrisk <[email protected]>

---
 fs/eventpoll.c             |    2 +-
 include/linux/capability.h |    6 +++---
 include/linux/eventpoll.h  |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

fs/eventpoll.c +1 -1

index 74598f6..1c8b556 100644
@@ -1710,7 +1710,7 @@ 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_EPOLLWAKEUP))
+	if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
 		epds.events &= ~EPOLLWAKEUP;
 
 	/*

include/linux/capability.h +3 -3

index 68d56ef..d10b7ed 100644
@@ -360,11 +360,11 @@ struct cpu_vfs_cap_data {
 
 #define CAP_WAKE_ALARM            35
 
-/* Allow preventing system suspends while epoll events are pending */
+/* Allow preventing system suspends */
 
-#define CAP_EPOLLWAKEUP      36
+#define CAP_BLOCK_SUSPEND    36
 
-#define CAP_LAST_CAP         CAP_EPOLLWAKEUP
+#define CAP_LAST_CAP         CAP_BLOCK_SUSPEND
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)

include/linux/eventpoll.h +1 -1

index 6f8be32..f4bb378 100644
@@ -34,7 +34,7 @@
  * re-allowed until epoll_wait is called again after consuming the wakeup
  * event(s).
  *
- * Requires CAP_EPOLLWAKEUP
+ * Requires CAP_BLOCK_SUSPEND
  */
 #define EPOLLWAKEUP (1 << 29)

Serge E. Hallyn

maintainer Acked-by Serge Hallyn on v1 1/1

2012-07-17 13:46 UTC #1 lore raw

Quoted 17 lines · Michael Kerrisk

Rafael,
As discussed in
http://thread.gmane.org/gmane.linux.kernel/1249726/focus=1288990,
the capability introduced in 4d7e30d98939a0340022ccd49325a3d70f7e0238 to govern EPOLLWAKEUP seems misnamed: this capability is about governing the ability to suspend the system, not using a particular API flag (EPOLLWAKEUP). We should make the name of the capability more general to encourage reuse in related cases. (Whether or not this capability should also be used to govern the use of /sys/power/wake_lock is a question that needs to be separately resolved.)
This patch renames the capability to CAP_BLOCK_SUSPEND. In order to ensure that the old capability name doesn't make it out into the wild, could you please apply and push up the tree to ensure that it is incorporated for the 3.5 release.

Quoted 5 lines

Thanks,
Michael
Signed-off-by Michael Kerrisk <[email protected]>

I definately like that name better, thanks. Don't know if renaming it without an alias could cause trouble for some bleeding edge userspaces? Would it be worth keeping the

#define CAP_EPOLLWAKEUP 36

line? If this is deemed early enough I do prefer not to complicate with a duplicate name.

Acked-by Serge Hallyn <[email protected]>

Quoted 57 lines

---
 fs/eventpoll.c             |    2 +-
 include/linux/capability.h |    6 +++---
 include/linux/eventpoll.h  |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

fs/eventpoll.c +1 -1

index 74598f6..1c8b556 100644
@@ -1710,7 +1710,7 @@ 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_EPOLLWAKEUP))
+	if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
 		epds.events &= ~EPOLLWAKEUP;
 
 	/*

include/linux/capability.h +3 -3

index 68d56ef..d10b7ed 100644
@@ -360,11 +360,11 @@ struct cpu_vfs_cap_data {
 
 #define CAP_WAKE_ALARM            35
 
-/* Allow preventing system suspends while epoll events are pending */
+/* Allow preventing system suspends */
 
-#define CAP_EPOLLWAKEUP      36
+#define CAP_BLOCK_SUSPEND    36
 
-#define CAP_LAST_CAP         CAP_EPOLLWAKEUP
+#define CAP_LAST_CAP         CAP_BLOCK_SUSPEND
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)

include/linux/eventpoll.h +1 -2

index 6f8be32..f4bb378 100644
@@ -34,7 +34,7 @@
  * re-allowed until epoll_wait is called again after consuming the wakeup
  * event(s).
  *
- * Requires CAP_EPOLLWAKEUP
+ * Requires CAP_BLOCK_SUSPEND
  */
 #define EPOLLWAKEUP (1 << 29)
 
--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Michael Kerrisk (man-pages)

author

2012-07-17 13:54 UTC #2 lore raw

Quoted 24 lines · Serge E. Hallyn

Quoted 17 lines · Michael Kerrisk
Rafael,
As discussed in
http://thread.gmane.org/gmane.linux.kernel/1249726/focus=1288990,
the capability introduced in 4d7e30d98939a0340022ccd49325a3d70f7e0238 to govern EPOLLWAKEUP seems misnamed: this capability is about governing the ability to suspend the system, not using a particular API flag (EPOLLWAKEUP). We should make the name of the capability more general to encourage reuse in related cases. (Whether or not this capability should also be used to govern the use of /sys/power/wake_lock is a question that needs to be separately resolved.)
This patch renames the capability to CAP_BLOCK_SUSPEND. In order to ensure that the old capability name doesn't make it out into the wild, could you please apply and push up the tree to ensure that it is incorporated for the 3.5 release.
Quoted 5 lines
Thanks,
Michael
Signed-off-by Michael Kerrisk <[email protected]>

Quoted 8 lines

I definately like that name better, thanks. Don't know if renaming it without an alias could cause trouble for some bleeding edge userspaces? Would it be worth keeping the
#define CAP_EPOLLWAKEUP 36
line? If this is deemed early enough I do prefer not to complicate with a duplicate name.

Maybe I'm too ignorant. Are there userspaces that bleed with the -rc series? I'd have thought this renaming would be a fairly safe change at this point.

Quoted 1 line

Acked-by Serge Hallyn <[email protected]>

Thanks,

Michael

Signature · 3 lines

Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

Serge E. Hallyn

maintainer

2012-07-17 13:59 UTC #3 lore raw

Quoted 29 lines · Michael Kerrisk

Quoted 28 lines · Serge E. Hallyn
Quoted 17 lines · Michael Kerrisk
Rafael,
As discussed in
http://thread.gmane.org/gmane.linux.kernel/1249726/focus=1288990,
the capability introduced in 4d7e30d98939a0340022ccd49325a3d70f7e0238 to govern EPOLLWAKEUP seems misnamed: this capability is about governing the ability to suspend the system, not using a particular API flag (EPOLLWAKEUP). We should make the name of the capability more general to encourage reuse in related cases. (Whether or not this capability should also be used to govern the use of /sys/power/wake_lock is a question that needs to be separately resolved.)
This patch renames the capability to CAP_BLOCK_SUSPEND. In order to ensure that the old capability name doesn't make it out into the wild, could you please apply and push up the tree to ensure that it is incorporated for the 3.5 release.
Quoted 5 lines
Thanks,
Michael
Signed-off-by Michael Kerrisk <[email protected]>
I definately like that name better, thanks. Don't know if renaming it without an alias could cause trouble for some bleeding edge userspaces? Would it be worth keeping the

Quoted 8 lines

Quoted 4 lines
#define CAP_EPOLLWAKEUP 36
line? If this is deemed early enough I do prefer not to complicate with a duplicate name.
Maybe I'm too ignorant. Are there userspaces that bleed with the -rc series? I'd have thought this renaming would be a fairly safe change at this point.

I'm sure there are, but I'm not sure what we've promised them.

Like I say if at all possible I do prefer not to keep CAP_EPOLLWAKEUP.

-serge

Rafael J. Wysocki

2012-07-17 18:59 UTC #4 lore raw

Quoted 30 lines · Serge E. Hallyn

Quoted 29 lines · Michael Kerrisk
Quoted 28 lines · Serge E. Hallyn
Quoted 17 lines · Michael Kerrisk
Rafael,
As discussed in
http://thread.gmane.org/gmane.linux.kernel/1249726/focus=1288990,
the capability introduced in 4d7e30d98939a0340022ccd49325a3d70f7e0238 to govern EPOLLWAKEUP seems misnamed: this capability is about governing the ability to suspend the system, not using a particular API flag (EPOLLWAKEUP). We should make the name of the capability more general to encourage reuse in related cases. (Whether or not this capability should also be used to govern the use of /sys/power/wake_lock is a question that needs to be separately resolved.)
This patch renames the capability to CAP_BLOCK_SUSPEND. In order to ensure that the old capability name doesn't make it out into the wild, could you please apply and push up the tree to ensure that it is incorporated for the 3.5 release.
Quoted 5 lines
Thanks,
Michael
Signed-off-by Michael Kerrisk <[email protected]>
I definately like that name better, thanks. Don't know if renaming it without an alias could cause trouble for some bleeding edge userspaces? Would it be worth keeping the

Quoted 8 lines

Quoted 8 lines
Quoted 4 lines
#define CAP_EPOLLWAKEUP 36
line? If this is deemed early enough I do prefer not to complicate with a duplicate name.
Maybe I'm too ignorant. Are there userspaces that bleed with the -rc series? I'd have thought this renaming would be a fairly safe change at this point.

I'm not so sure of that, but then I think it will be less painful to do it now rather than later.

Quoted 1 line

I'm sure there are, but I'm not sure what we've promised them.

I can't recall making any promises to anyone in that respect, but then people have had quite enough time to get used to the existing name already.

Quoted 1 line

Like I say if at all possible I do prefer not to keep CAP_EPOLLWAKEUP.

I will push the Michael's patch to Linus for v3.5, if it's not too late, but I'm not pleased by the timing of this, to put it lightly.

Thanks,
Rafael