Re: [RFC][PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.

[John Stultz]

On Thu, Jun 25, 2015 at 6:21 PM, Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote:
> On 6/25/2015 4:24 PM, John Stultz wrote:
>>
>> From: Ruchi Kandoi <kandoiruchi@xxxxxxxxxx>
>>
>> This patch has been in the Android tree for ahwile, and I've not
>> seen it posted for review. Unfortunately the PR_SET_TIMERSLACK_PID
>> value has collided many times w/ upstream (first w/
>> PR_SET_THP_DISABLE, and again w/ PR_MPX_ENABLE_MANAGEMENT).
>>
>> So to try to avoid further ABI trouble, I wanted to send this out
>> for initial review to see if there were any major objections,
>> or ideas for alternative approaches.
>>
>> Thoughts and feedback would be appreciated.
>
>
> I am wondering if it would be more natural to make this a cgroup
> property.. and have a way for threads to inherit their cgroup
> effective value.

I'm hesitant here, as I know the android cgroup usage (ie: having a
forground cgroup and background cgroup), is frowned upon by the cgroup
maintainers, since frequently migrating processes and memory between
the cgroups is costly. So  they've been suggesting (assuming I
understood their feedback properly) to use per-application cgroups
(changing the cgroup knobs to "forground settings" or "background
settings") as needed.

So if you were thinking that one could set the slack for larger
cgroups to avoid per-process adjustments, that may not be the right
way forward. But maybe you're suggesting something else?

> it'll fit more natural in many places than just a per pid setting.
> (I have nothing against it per se other than that I think the
> security check is wrong; I fully expected to be on the level of
> ptrace_may_access(PTRACE_MODE_ATTACH) or the like.. not just NICE.
> you can seriously change task behavior with this by setting a 4 second
> value or so.. much more than just with nice)

Yea, they've sort of overloaded CAP_SYS_NICE for a number of Android
specific checks.  I think using a different existing cap or
introducing a new one would be fine, but I'm not sure which cap would
really be best. Are there any other opinions here, or is
PTRACE_MODE_ATTACH ok?

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