From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751999AbbFZBWK (ORCPT ); Thu, 25 Jun 2015 21:22:10 -0400 Received: from mga02.intel.com ([134.134.136.20]:15688 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751123AbbFZBWA (ORCPT ); Thu, 25 Jun 2015 21:22:00 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,681,1427785200"; d="scan'208";a="594986578" Message-ID: <558CA92A.50707@linux.intel.com> Date: Thu, 25 Jun 2015 18:21:46 -0700 From: Arjan van de Ven User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John Stultz , lkml CC: Ruchi Kandoi , Thomas Gleixner , Oren Laadan , Micha Kalfon , Rom Lemarchand , Android Kernel Team Subject: Re: [RFC][PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread. References: <1435274682-9425-1-git-send-email-john.stultz@linaro.org> In-Reply-To: <1435274682-9425-1-git-send-email-john.stultz@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/25/2015 4:24 PM, John Stultz wrote: > From: Ruchi Kandoi > > 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. 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)