Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1206701ybf; Thu, 27 Feb 2020 06:48:53 -0800 (PST) X-Google-Smtp-Source: APXvYqwamG+oIyPiOeq+eAFO1oVCwz2dO99cs2A9vaI9WCllCscr8qvN7RMtzoLjOf6s/KLWyUkT X-Received: by 2002:aca:5588:: with SMTP id j130mr3496864oib.122.1582814933327; Thu, 27 Feb 2020 06:48:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582814933; cv=none; d=google.com; s=arc-20160816; b=LX9mqrKXuoJSKzbQmgP0Ny5W+YlLL3EgZHuHaT0/csjs4Z5x60sX5kNDZduPKBWvgh JFdbxVHFb15/frcYfDDX68VMYiLSDtF3AY6B5O8q80RZ8b739NhvL5G8lRTrhWtP2Ekl bfM0smkYk0BRfQjhDznHKOsTfnI3GW02lmc15V1vnUGzIZ9Z7v6y2tU+UKlxvL9jwEd4 ia/aXapjLMuQW9uvMOPzL7sXX1qGYaCNd2Wzw39UgLjQpeTT0ZEOQ2GDEJaSzbsnkqCq WCtEruwdnDioxQajThHXZXstbhmEwKK0b4gtrHGDUvWNTvg36iwDCzITw9jU5Hv8uWCH WP2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=/ZgEk1vSDex02903ZCNH3Bx69liVtQfuXUyTUho4JEk=; b=tgmbnyn07NMfGT5cLip6mM8bUVEYXqwD+Tyvg52vJ3vCv4GcZUt/dvxdbFyDdBx1xk MgM9YDuvGINagB33Phb5Cx1bJp2rccLVfr9rackOaaYyivxVikPaHrcd5TrHgIqYqteR drOgKDHbZlJfs8+9D50QhLnnH+bx4sDKJ72l/z9wrmr1PZI/+l7amLzWpaFIuMkvxu/O bNZsXeV+Vpu+h8yqv5mw+78/8S85C/1sDBBGjW5pHe9BQDFsGRkys0ho9KANllU1BJa5 Ft8Iw6z/kTvOanbGTgW1Uwb+7yx1AusWeQkB2UBuME7pshl3bhYvKIsqUXh8oJUXy5AD OzWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=G21bDkcD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q126si1631828oia.8.2020.02.27.06.48.41; Thu, 27 Feb 2020 06:48:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=G21bDkcD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730621AbgB0OsG (ORCPT + 99 others); Thu, 27 Feb 2020 09:48:06 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:43278 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729703AbgB0OsF (ORCPT ); Thu, 27 Feb 2020 09:48:05 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01REhYxi159994; Thu, 27 Feb 2020 14:46:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=/ZgEk1vSDex02903ZCNH3Bx69liVtQfuXUyTUho4JEk=; b=G21bDkcDCDnlevFJQZsO3xO4tKbePX4hRJf0fG7QQPre04ssgGM20v0J5l/DnsPaoLyF CiHBIGEQcNXwogWPH7TrcY+0Nd5z1uSfAIllXAWiivo+eqEH4pwwsznaSOaubP+6RHZ7 pLA8SSMpr1ggU5n2h6vnGSksYl8B+tSVYc5j0iRbi++XB3RXNANjIRP2NC3/NOTHDPUz QkVEe4+Yb0uHFYY6qVQhtNGiH+WIf5PsKENBNCP6sWrBm7BlcxbveBVAdA5mefUIXBxM FIiEqiy1Fvbm4QWEXVAUKufKdz3ex1N7VIoqL+6q3o+OQuPTuwaX0r0dQrHbjAZsWMoq QQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2ydcsnkd6j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Feb 2020 14:46:39 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01REiVe5006071; Thu, 27 Feb 2020 14:46:38 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 2ydcs5cf81-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Feb 2020 14:46:38 +0000 Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 01REkYMN006162; Thu, 27 Feb 2020 14:46:34 GMT Received: from [192.168.0.195] (/69.207.174.138) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Feb 2020 06:46:34 -0800 Subject: Re: [PATCH v4 4/4] sched/core: Add permission checks for setting the latency_nice value To: Qais Yousef , Parth Shah Cc: vincent.guittot@linaro.org, dietmar.eggemann@arm.com, patrick.bellasi@matbug.net, valentin.schneider@arm.com, tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, David.Laight@ACULAB.COM, pjt@google.com, pavel@ucw.cz, tj@kernel.org, dhaval.giani@oracle.com, qperret@google.com References: <20200224085918.16955-1-parth@linux.ibm.com> <20200224085918.16955-5-parth@linux.ibm.com> <20200224132905.32sdpbydnzypib47@e107158-lin.cambridge.arm.com> <9a4132f2-62cc-4132-1c6d-964ed679afc7@linux.ibm.com> <20200227114401.uz5p2e7mcomzoo5k@e107158-lin.cambridge.arm.com> From: chris hyser Message-ID: <23524cda-f2fb-b2cd-1dcb-93672022c684@oracle.com> Date: Thu, 27 Feb 2020 09:46:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20200227114401.uz5p2e7mcomzoo5k@e107158-lin.cambridge.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9543 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 malwarescore=0 mlxlogscore=906 mlxscore=0 phishscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002270117 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9543 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=962 phishscore=0 spamscore=0 adultscore=0 suspectscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002270117 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/27/20 6:44 AM, Qais Yousef wrote: > On 02/25/20 12:17, Parth Shah wrote: >> >> >> On 2/24/20 6:59 PM, Qais Yousef wrote: >>> On 02/24/20 14:29, Parth Shah wrote: >>>> Since the latency_nice uses the similar infrastructure as NICE, use the >>>> already existing CAP_SYS_NICE security checks for the latency_nice. This >>>> should return -EPERM for the non-root user when trying to set the task >>>> latency_nice value to any lower than the current value. >>>> >>>> Signed-off-by: Parth Shah >>> >>> I'm not against this, so I'm okay if it goes in as is. >>> >>> But IMO the definition of this flag is system dependent and I think it's >>> prudent to keep it an admin only configuration. >>> >>> It'd be hard to predict how normal application could use and depend on this >>> feature in the future, which could tie our hand in terms of extending it. >>> >> >> I am fine with this going in too. But just to lie down the fact on single >> page and starting the discussion, here are the pros and cons for including >> this permission checks: >> >> Pros: >> ===== >> - Having this permission checks will allow only root users to promote the >> task, meaning lowering the latency_nice of the task. This is required in >> case when the admin has increased the latency_nice value of a task and >> non-root user can not lower it. >> - In absence of this check, the non-root user can decrease the latency_nice >> value against the admin configured value. >> >> Cons: >> ===== >> - This permission check prevents the non-root user to lower the value. This >> is a problem when the user itself has increased the latency_nice value in >> the past but fails to lower it again. >> - After task fork, non-root user cannot lower the inherited child task's >> latency_nice value, which might be a problem in the future for extending >> this latency_nice ideas for different optimizations. > > Worth adding that if we start strict with root (or capable user) only, relaxing > this to allow lowering the nice would still be possible in the future. But the > opposite is not true, we can't reverse the users ability to lower its > latency_nice value once we give it away. > > Beside thinking a bit more about it now. If high latency_nice value means > cutting short the idle search for instance, does this prevent someone using > a lower latency nice to be aggressive in some code path to get higher > throughput? Short-cutting an idle cpu search reduces latency. There would be a mapping between the latency_nice values -20..-1 and the short cut. In that view 0 is the default and performs the full domain search as before and -20 presumably skips the entire search. Positive values then presumably indicate a trade-off in preference of throughput. I've not thought any about it till now, but maybe indicates that spending extra time (versus less) finding this task the perfect home to just sit and crank on throughput would be worth it. -chrish