public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Bijan Mottahedeh <[email protected]>
Cc: [email protected]
Subject: Re: [RFC 1/2] io_uring: disallow overlapping ranges for buffer registration
Date: Sun, 14 Jun 2020 09:56:56 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 6/12/20 12:22 PM, Bijan Mottahedeh wrote:
> On 6/12/2020 8:16 AM, Jens Axboe wrote:
>> On 6/11/20 8:23 PM, Bijan Mottahedeh wrote:
>>> Buffer registration is expensive in terms of cpu/mem overhead and there
>>> seems no good reason to allow overlapping ranges.
>> There's also no good reason to disallow it imho, so not sure we should
>> be doing that.
>>
> 
> My concern was about a malicious user without CAP_IPC_LOCK abusing its 
> memlock limit and repeatedly register the same buffer as that would tie 
> up cpu/mem resources to pin up to 1TB of memory, but maybe the argument 
> is that the user should have not been granted that large of memlock 
> limit?  Also, without any restrictions, there are a huge number of ways 
> overlapping ranges could be specified, creating a very large validation 
> matrix.  What the use cases for that flexibility are though, I don't know.

Not sure I follow, so I must be missing something. We're accounting each
buffer as it is, so how are we abusing the limit?

My concern on the overlaps is mainly that someone could be
(inadvertently, perhaps) doing it already, and now we're breaking that.
Or maybe that are doing it purposely, for some reason I just don't know
about.

-- 
Jens Axboe


  reply	other threads:[~2020-06-14 15:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12  2:23 [RFC 0/2] io_uring: disallow overlapping ranges for buffer registration Bijan Mottahedeh
2020-06-12  2:23 ` [RFC 1/2] " Bijan Mottahedeh
2020-06-12 15:16   ` Jens Axboe
2020-06-12 18:22     ` Bijan Mottahedeh
2020-06-14 15:56       ` Jens Axboe [this message]
2020-06-12  2:23 ` [RFC 2/2] io_uring: report pinned memory usage Bijan Mottahedeh
2020-06-12 15:16   ` Jens Axboe
2020-06-12 15:19     ` Jens Axboe
2020-06-12 15:50       ` Jens Axboe
2020-06-13  4:43       ` Bijan Mottahedeh
2020-06-14 15:57         ` Jens Axboe

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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