mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Bart Van Assche <bvanassche@acm.org>,
	Khazhismel Kumykov <khazhy@google.com>,
	paolo.valente@linaro.org
Cc: linux-block@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: IOPRIO_CLASS_RT without CAP_SYS_ADMIN?
Date: Sat, 22 Aug 2020 20:14:19 -0600	[thread overview]
Message-ID: <b138bc8f-0062-3e0e-5838-bf73c09b40f0@kernel.dk> (raw)
In-Reply-To: <992ed2ed-f644-a5ad-3239-b38ddeafe28b@acm.org>

On 8/22/20 7:58 PM, Bart Van Assche wrote:
> On 2020-08-20 17:35, Khazhismel Kumykov wrote:
>> It'd be nice to allow a process to send RT requests without granting
>> it the wide capabilities of CAP_SYS_ADMIN, and we already have a
>> capability which seems to almost fit this priority idea -
>> CAP_SYS_NICE? Would this fit there?
>>
>> Being capable of setting IO priorities on per request or per thread
>> basis (be it async submission or w/ thread ioprio_set) is useful
>> especially when the userspace has its own prioritization/scheduling
>> before hitting the kernel, allowing us to signal to the kernel how to
>> order certain IOs, and it'd be nice to separate this from ADMIN for
>> non-root processes, in a way that's less error prone than e.g. having
>> a trusted launcher ionice the process and then drop priorities for
>> everything but prio requests.
> 
> Hi Khazhy,
> 
> In include/uapi/linux/capability.h I found the following:
> 
> /* Allow raising priority and setting priority on other (different
>    UID) processes */
> /* Allow use of FIFO and round-robin (realtime) scheduling on own
>    processes and setting the scheduling algorithm used by another
>    process. */
> /* Allow setting cpu affinity on other processes */
> #define CAP_SYS_NICE         23
> 
> If it is acceptable that every process that has permission to submit
> IOPRIO_CLASS_RT I/O also has permission to modify the priority of
> other processes then extending CAP_SYS_NICE is an option. Another
> possibility is to extend the block cgroup controller such that the
> capability to submit IOPRIO_CLASS_RT I/O can be enabled through the
> cgroup interface. There may be other approaches. I'm not sure what
> the best approach is.

I think CAP_SYS_NICE fits pretty nicely, and I was actually planning on
using that for the io_uring SQPOLL side as well. So there is/will be
some precedent for tying it into IO related things, too. For this use
case, I think it's perfect.

-- 
Jens Axboe


  reply	other threads:[~2020-08-23  2:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21  0:35 Khazhismel Kumykov
2020-08-23  1:58 ` Bart Van Assche
2020-08-23  2:14   ` Jens Axboe [this message]
2020-08-24 20:46     ` Khazhismel Kumykov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b138bc8f-0062-3e0e-5838-bf73c09b40f0@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=khazhy@google.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paolo.valente@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®