From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88D8BC4363D for ; Thu, 24 Sep 2020 16:15:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36A05206C3 for ; Thu, 24 Sep 2020 16:15:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726774AbgIXQPE (ORCPT ); Thu, 24 Sep 2020 12:15:04 -0400 Received: from foss.arm.com ([217.140.110.172]:50194 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726596AbgIXQPE (ORCPT ); Thu, 24 Sep 2020 12:15:04 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B04161396; Thu, 24 Sep 2020 09:15:03 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 93BBA3F718; Thu, 24 Sep 2020 09:15:02 -0700 (PDT) Date: Thu, 24 Sep 2020 17:15:00 +0100 From: Qais Yousef To: Rob Clark , dri-devel , Rob Clark , Peter Zijlstra , linux-arm-msm , open list , Tim Murray , Tejun Heo Subject: Re: [PATCH 0/3] drm: commit_work scheduling Message-ID: <20200924161356.5kezxwiqwtbi3o2p@e107158-lin.cambridge.arm.com> References: <20200919193727.2093945-1-robdclark@gmail.com> <20200921092154.GJ438822@phenom.ffwll.local> <20200923152545.GQ438822@phenom.ffwll.local> <20200924084950.GY438822@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200924084950.GY438822@phenom.ffwll.local> User-Agent: NeoMutt/20171215 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 09/24/20 10:49, Daniel Vetter wrote: [...] > > > I also thought kernel threads can be distinguished from others, so > > > userspace shouldn't be able to sneak in and get elevated by accident. > > > > I guess maybe you could look at the parent? I still would like to > > think that we could come up with something a bit less shaking than > > matching thread names by regexp.. > > ps marks up kernel threads with [], so there is a way. But I haven't > looked at what it is exactly that tells kernel threads apart from others. > > But aside from that sounds like "match right kernel thread with regex and > set its scheduler class" is how this is currently done, if I'm > understanding what Tejun and Peter said correctly. > > Not pretty, but also *shrug* ... Isn't there a real danger that a sneaky application names its threads to match this regex and get a free promotion to RT without having the capability to do so? Cheers -- Qais Yousef From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1ED8C4727F for ; Fri, 25 Sep 2020 07:09:36 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 698D222211 for ; Fri, 25 Sep 2020 07:09:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 698D222211 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E223F6EC08; Fri, 25 Sep 2020 07:09:25 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 784E16EB2E for ; Thu, 24 Sep 2020 16:15:04 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B04161396; Thu, 24 Sep 2020 09:15:03 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 93BBA3F718; Thu, 24 Sep 2020 09:15:02 -0700 (PDT) Date: Thu, 24 Sep 2020 17:15:00 +0100 From: Qais Yousef To: Rob Clark , dri-devel , Rob Clark , Peter Zijlstra , linux-arm-msm , open list , Tim Murray , Tejun Heo Subject: Re: [PATCH 0/3] drm: commit_work scheduling Message-ID: <20200924161356.5kezxwiqwtbi3o2p@e107158-lin.cambridge.arm.com> References: <20200919193727.2093945-1-robdclark@gmail.com> <20200921092154.GJ438822@phenom.ffwll.local> <20200923152545.GQ438822@phenom.ffwll.local> <20200924084950.GY438822@phenom.ffwll.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200924084950.GY438822@phenom.ffwll.local> User-Agent: NeoMutt/20171215 X-Mailman-Approved-At: Fri, 25 Sep 2020 07:09:24 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 09/24/20 10:49, Daniel Vetter wrote: [...] > > > I also thought kernel threads can be distinguished from others, so > > > userspace shouldn't be able to sneak in and get elevated by accident. > > > > I guess maybe you could look at the parent? I still would like to > > think that we could come up with something a bit less shaking than > > matching thread names by regexp.. > > ps marks up kernel threads with [], so there is a way. But I haven't > looked at what it is exactly that tells kernel threads apart from others. > > But aside from that sounds like "match right kernel thread with regex and > set its scheduler class" is how this is currently done, if I'm > understanding what Tejun and Peter said correctly. > > Not pretty, but also *shrug* ... Isn't there a real danger that a sneaky application names its threads to match this regex and get a free promotion to RT without having the capability to do so? Cheers -- Qais Yousef _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel