Re: [PATCH v2 7/7] drm/virtio: implement userptr: add interval tree

["Huang, Honglei1" <Honglei1.Huang@amd.com>]

Hi Dmitry:

Really sorry for missed this comment. Yes it can be done in UMD, 
actually the interval tree is used with the MMU notifier normally,
it is for preventing create same MMU notifier for overlapped areas.
Cause this version patch set doesn't have MMU notifier, removing 
interval tree is reasonable.

Hi Demi:
Adding interval tree can make virtio userptr has robust check, it can be 
done in UMD. And for AMD userptr driver, it is a SVM type driver, it has
both interval tree and MMU notifier but userptr memory is moveable in 
it. No interval tree for Intel i386, not sure about the Intel XE driver.

Maybe I can remove the interval tree in next version.


On 2025/4/3 2:45, Demi Marie Obenour wrote:
> On 4/2/25 8:34 AM, Dmitry Osipenko wrote:
>> On 4/2/25 04:53, Huang, Honglei1 wrote:
>>>
>>> On 2025/3/30 19:57, Dmitry Osipenko wrote:
>>>> If the purpose of this feature is to dedup usrptr BOs of a the single
>>>> process/application, can this can be done in userspace?
>>
>> I assume it can be done in userspace, don't see why it needs to be in
>> kernel.
> 
> The kernel definitely does not need to be responsible for deduplication,
> but is it safe to allow userspace to create overlapping BOs, especially
> ones that are partially but not entirely overlapping?  If the userspace
> libraries ~everyone will be using refuse to create such BOs, then
> overlapping BOs will be tested by ~nobody, and untested kernel code is
> a good place for security vulnerabilities to linger.
> 
> If there are no legitimate use-cases for overlapping BOs, I would treat
> attempts to create them as an errors and return -EINVAL, indicating that
> the userspace code attempting to create them is buggy.  Userspace can
> deduplicate the BOs itself if necessary.  Of course, there need to be
> tests for userspace attempting to create overlapping BOs, including
> attempting to do so concurrently from multiple threads.
> 
> That said, probably the most important part is consistency with userptr
> in other (non-virtio) drivers, such as Intel and AMD.  If they allow
> overlapping userptr BOs, then virtio should too; if they do not, then
> virtio should also forbid them.