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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 8A6CBC49EA2 for ; Mon, 14 Jun 2021 23:36:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5B27560234 for ; Mon, 14 Jun 2021 23:36:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231664AbhFNXig (ORCPT ); Mon, 14 Jun 2021 19:38:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231499AbhFNXif (ORCPT ); Mon, 14 Jun 2021 19:38:35 -0400 Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA4FBC061574 for ; Mon, 14 Jun 2021 16:36:18 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id q16so14248046qkm.9 for ; Mon, 14 Jun 2021 16:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tzJYum4jPDYdUZOzxiE2EDYoA//UFqDYCYrMpSJjOzc=; b=J4coD/Yq3Y+IWgXlsye2jcl1NSGH//FV5ng79LOcvQO18tNKoWLiXcbslqFwjaJLuZ HKVIz8wuW2qkYevTBXTtBvxOGUT4MGiGBfw8WfQFYDyiRStW8P9OnseLP4+gU/NiLKLS AaOCj2p3HzGDOnFcKOCNiWhgo4b5HT5uTGUJmfo2w4fstlkYdnJTqIX/RJtWmuabYBEY gw8YBCQZqBIFrf1S8STV25xmozk1W6CGzvyP3nWcpv4mvUUWudj0BKjDDVUwQ7dxeRG/ i0ZVNQkYkIS4EskS2lifvpKtZbZYspufOcVBiLnsxyO/VNAxD+z4WkWoj+ScPHQrdFiC tnwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tzJYum4jPDYdUZOzxiE2EDYoA//UFqDYCYrMpSJjOzc=; b=TYKLV9MkEuoCQ/v2ax22tqMiYq1OMid4INLEm4cA2AHJA4DKHgNLXx/rpPMXgITk+7 Q69DgFZqr+hrfnSvOU8p6ToHvC3IJ+rOGdCXq/iF2xOr5R95k/NMFWCeGH6NZFzWIgvm 0JOBDfBugjGFLkCyS7Lf31mxKiX95jB164JxfLl3o2m4/4z53yZPyfWRaahzpsFvedg6 IOF1PuVEXEq9Mu4UPBQsRJnZKYZm3WIpDRenvMlB8id6TPIjNggNHeLixSdV1UBFPU9N s2yTf5gP6WypknKq/kW7Yj1S1A5cZhioiqe5pSkolrz2/HkNtKPASfD82zP8SZaMe3U2 L/8g== X-Gm-Message-State: AOAM533wNBhXVAwk0/Fg4T/jSBhxhVcahdG3BZ0NPWW5qrETyqoyVS5J +sHodxEvy41mBXg3zBBHqlOf488h5hR5XTWViVu7cA== X-Google-Smtp-Source: ABdhPJzHAtJv0exi/Hya7peRe/J8A+9ovUirjHPA6xZwwO4/jwWy8tb7RSIWJAMy54GQ//vqPC99EkkUlU5U4/Voa18= X-Received: by 2002:a37:c58:: with SMTP id 85mr18364587qkm.276.1623713777603; Mon, 14 Jun 2021 16:36:17 -0700 (PDT) MIME-Version: 1.0 References: <20210422120459.447350175@infradead.org> <20210422123309.039845339@infradead.org> In-Reply-To: <20210422123309.039845339@infradead.org> From: Josh Don Date: Mon, 14 Jun 2021 16:36:06 -0700 Message-ID: Subject: Re: [PATCH 18/19] sched: prctl() core-scheduling interface To: Peter Zijlstra Cc: Joel Fernandes , "Hyser,Chris" , Ingo Molnar , Vincent Guittot , Valentin Schneider , Mel Gorman , linux-kernel , Thomas Gleixner , Aubrey Li , Xiangling Kong , Benjamin Segall Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 22, 2021 at 5:36 AM Peter Zijlstra wrote: > > From: Chris Hyser > > This patch provides support for setting and copying core scheduling > 'task cookies' between threads (PID), processes (TGID), and process > groups (PGID). [snip] Internally, we have lots of trusted processes that don't have a security need for coresched cookies. However, these processes could still decide to create cookies for themselves, which will degrade machine capacity and performance for other jobs on the machine. Any thoughts on whether it would be desirable to have the ability to restrict use of SCHED_CORE_CREATE? Perhaps a new SCHED_CORE capability would be appropriate? - Josh