[Intel-xe] ✗ CI.checkpatch: warning for drm/xe: Support optional pinning of userptr pages

[Patchwork]

== Series Details ==

Series: drm/xe: Support optional pinning of userptr pages
URL   : https://patchwork.freedesktop.org/series/122637/
State : warning

== Summary ==

+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
e700ea2f248a75138759bcb443affeef4a2d1991
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 8baf16a1dcffe185d2cf67ef735f96d3155d57db
Author: Thomas Hellström <thomas.hellstrom at linux.intel.com>
Date:   Fri Aug 18 17:08:45 2023 +0200

    drm/xe/uapi: Support pinning of userptr vmas
    
    Support pinning of vmas using XE_VM_BIND_FLAG_PIN, initially for userptr
    only. Pinned memory becomes accounted against RLIMIT_MEMLOCK and processes
    with CAP_IPC_LOCK will not apply the limit. This is pretty similar to
    mlock()'ing userptr memory with the added benefit that the driver is
    aware and can ignore some actions in the MMU invalidation notifier.
    
    This will initially become useful for compute VMs on hardware without
    mid-thread-preemption capability since with pinned pages, the MMU
    invalidation notifier never tries to preempt a running compute kernel.
    
    If that were the only usage we could restrict this to a flag that always
    pins userptr VMAs on compute VMs on such hardware, but there are
    indications that this may become needed in other situations as well.
    
    From a more general point of view, the usage pattern of a system may be
    such that in most cases it only ever runs a single workload per system
    and then the sysadmin would want to configure the system to allow
    extensive pinning for performance reasons.
    
    Hence we might want to extend the pinning capability to bo-backed VMAs
    as well. How that pinning will be accounted remains an open but to build
    on the current drm CGROUP work would be an option.
    
    Signed-off-by: Thomas Hellström <thomas.hellstrom at linux.intel.com>
+ /mt/dim checkpatch 9112bca10116fdc4c33220478c47aa92f95832fe drm-intel
/mt/dim: line 50: /root/.dimrc: No such file or directory