Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp443628pxk; Thu, 24 Sep 2020 09:16:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFsqkPGrOr/dWJAvdraveJv/mp5lupJ3WaBU6lBM1usmJFQbeGJSDFuPZZ+X18rVXAjM2Q X-Received: by 2002:a17:906:e4f:: with SMTP id q15mr688879eji.155.1600964195052; Thu, 24 Sep 2020 09:16:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600964195; cv=none; d=google.com; s=arc-20160816; b=01KUZ0my1y2zzURZyfyEpKvvXkVltstV/wsHkKmkVywwOOuwjUR/e1/W+RZ4VyIAUC 2N4uT7pmrd8/009l49o/TAcqbXWReiLlsTl/vgR99fpGcUHoZdCbgJTyzIp+HMj+zCzi hILO1BlBaIMexUQU5mYZU57WphhBRnuK+/VO+tbclx+7cMsxyHGaubf8mUER/vq2qZxG k8z2ss9qIC7rSkzjboDJuNkhShyBWGEeuGmXNmqNEcIf4J+/eueUJw5HcuCAqWRo4MAE pf16c8W8C/7jF+JXutR7lQ86iwXmjk95A2yXfakkoDJXnktMiNdGhdOsPWnd0xrgaz8C 6B6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:to:from:date; bh=L/nXP3YygeyaxWwRg+hDlyZBtLemNXwL+kx4cd5AmU4=; b=tBquTKuXnfd9OuxIU5AZJy0Km0SWMCC/WgQscPSQyMZ1vwm4tLHfzuVWJcumAXpkFb lq0AJRYqCQrIyaemIamtuNH55ZxKAbwq7eCQ8owPpkJn3wdXd8RHHcmX1oH8qHIhkG/4 raEcheQFrogC8FC8g1S0HyLR4sAaPAayRebQ8siRB1cpcgQg42R+PARYwVNcMk/KGyAD 3pyNokqMmmJmaa3jaMCm9imwhoCy/I4rNrS/TMyzS9mS/smyLXTZu3ISkQok0UxfasZw u7PAgAU0BXrIk4GCciPQtIaz2wBAaWI4YxhYuBu/U2egPGHHjwdkowWK6xlYi4JjZuVe 3evA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mh6si2090694ejb.243.2020.09.24.09.16.10; Thu, 24 Sep 2020 09:16:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727555AbgIXQPE (ORCPT + 99 others); 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-kernel@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