From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=gItQ=AO=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1
	autolearn=ham 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 82F63C433E0
	for <linux-kernel@archiver.kernel.org>; Fri,  3 Jul 2020 06:01:54 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 4E1A3208FE
	for <linux-kernel@archiver.kernel.org>; Fri,  3 Jul 2020 06:01:54 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="MNpH087T"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726074AbgGCGBw (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 3 Jul 2020 02:01:52 -0400
Received: from hqnvemgate25.nvidia.com ([216.228.121.64]:10873 "EHLO
        hqnvemgate25.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1725648AbgGCGBw (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 3 Jul 2020 02:01:52 -0400
Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA)
        id <B5efec99c0000>; Thu, 02 Jul 2020 23:01:00 -0700
Received: from hqmail.nvidia.com ([172.20.161.6])
  by hqpgpgate101.nvidia.com (PGP Universal service);
  Thu, 02 Jul 2020 23:01:51 -0700
X-PGP-Universal: processed;
        by hqpgpgate101.nvidia.com on Thu, 02 Jul 2020 23:01:51 -0700
Received: from [172.20.40.54] (172.20.13.39) by HQMAIL107.nvidia.com
 (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 3 Jul
 2020 06:01:51 +0000
Subject: Re: [git pull] drm for 5.8-rc1
From:   James Jones <jajones@nvidia.com>
To:     Daniel Stone <daniel@fooishbar.org>
CC:     "Kirill A. Shutemov" <kirill@shutemov.name>,
        LKML <linux-kernel@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        Ben Skeggs <bskeggs@redhat.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        Linus Torvalds <torvalds@linux-foundation.org>
References: <CAPM=9txGww+omvateOTizZRV9_wLdAbq6uAz3DRa_S6bn1jQuQ@mail.gmail.com>
 <20200630230808.wj2xlt44vrszqfzx@box>
 <ef7816b4-72ee-9e0e-8cac-4d80d8343f9f@nvidia.com>
 <20200701075719.p7h5zypdtlhqxtgv@box> <20200701075902.hhmaskxtjsm4bcx7@box>
 <77e744b9-b5e2-9e9b-44c1-98584d2ae2f3@nvidia.com>
 <CAPj87rOrUHBZZR3cw+iqUMtZL1ZQyjd=RoM2yHt5oUeRO5uDTA@mail.gmail.com>
 <5ffa32db-4383-80f6-c0cf-a9bb12e729aa@nvidia.com>
X-Nvconfidentiality: public
Message-ID: <a3d331e9-d17e-9135-68c7-8e3e10df184d@nvidia.com>
Date:   Thu, 2 Jul 2020 23:01:54 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <5ffa32db-4383-80f6-c0cf-a9bb12e729aa@nvidia.com>
X-Originating-IP: [172.20.13.39]
X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To
 HQMAIL107.nvidia.com (172.20.187.13)
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
        t=1593756060; bh=oey+lAcqjyvtPJCijFnrSu5cD1hCcZdlv0Qpemv2n5g=;
        h=X-PGP-Universal:Subject:From:To:CC:References:X-Nvconfidentiality:
         Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:
         X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language:
         Content-Transfer-Encoding;
        b=MNpH087ToCVSf2E1woo+gOhwKNnLwwmyP5dNaRXSCmmnzsRwSS9I9Iaex2v+2Alh+
         dztiqsiU+4thD0DK8NPqqihMwtXAntz1bnQRG85WZq/vlbn78KZ+iRXwDhhjJx69xw
         MGrlm1z5T8IKwdV5BJxExHAdCklx66RgwMV5KARhUSkuRNcw+dASGzoBTU7SiNFKZi
         zU6ZQ0O3W+EYoeDztWzbS17i/M+9hsv6EChdDx85FiAf9tvoKiTrVwZadUzAA7rrHp
         nZbeTMF7dCDsBf4rkqmRqP7Bmh5HRgUDE/FvRZNsUTeBUr02EdBaMO5yi53IyZzx65
         U8RT9QToM7UHQ==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 7/2/20 2:14 PM, James Jones wrote:
> On 7/2/20 1:22 AM, Daniel Stone wrote:
>> Hi,
>>
>> On Wed, 1 Jul 2020 at 20:45, James Jones <jajones@nvidia.com> wrote:
>>> OK, I think I see what's going on.=C2=A0 In the Xorg modesetting driver=
, the
>>> logic is basically:
>>>
>>> if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS !=3D 0) {
>>> =C2=A0=C2=A0=C2=A0 drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(=
bo->gbm));
>>> } else {
>>> =C2=A0=C2=A0=C2=A0 drmModeAddFB(...);
>>> }
>>
>> I read this thread expecting to explain the correct behaviour we
>> implement in Weston and how modesetting needs to be fixed, but ...
>> that seems OK to me? As long as `gbm_has_modifiers` is a proxy for 'we
>> used gbm_(bo|surface)_create_with_modifiers to allocate the buffer'.
>=20
> Yes, the hazards of reporting findings before verifying.=C2=A0 I now see=
=20
> modesetting does query the DRM-KMS modifiers and attempt to allocate=20
> with them if it found any.=C2=A0 However, I still see a lot of ways thing=
s=20
> can go wrong, but I'm not going to share my speculation again until I've=
=20
> actually verified it, which is taking a frustratingly long time.=C2=A0 Th=
e=20
> modesetting driver is not my friend right now.

OK, several hours of dumb build+config mistakes later, I was actually=20
able to reproduce the failure and walk through things.  There is a=20
trivial fix for the issues in the X modesetting driver, working off=20
Daniel Stone's claim that gbm_bo_get_modifier() should only be called=20
when the allocation was made with gbm_bo_create_with_modifiers().=20
modeset doesn't respect that requirement now in the case that the atomic=20
modesetting path is disabled, which is always the case currently because=20
that path is broken.  Respecting that requirement is a half-liner and=20
allows X to start properly.

If I force modeset to use the atomic path, X still fails to start with=20
the above fix, validating the second theory I'd had:

-Current Mesa nouveau code basically ignores the modifier list passed in=20
unless it is a single modifier requesting linear layout, and goes about=20
allocating whatever layout it sees fit, and succeeds the allocation=20
despite being passed a list of modifiers it knows nothing about.  Not=20
great, fixed in my pending patches, obviously doesn't help existing=20
deployed userspace.

-Current Mesa nouveau code, when asked what modifier it used for the=20
above allocation, returns one of the "legacy" modifiers nouveau DRM-KMS=20
knows nothing about.

-When the modeset driver tries to create an FB for that BO with the=20
returned modifier, the nouveau kernel driver of course refuses.

I think it's probably worth fixing the modesetting driver for the=20
reasons Daniel Vetter mentioned.  Then if I get my Mesa patches in=20
before a new modesetting driver with working Atomic support is released,=20
there'll be no need for long-term workarounds in the kernel.

Down to the real question of what to do in the kernel to support current=20
userspace code: I still think the best fix is to accept the old=20
modifiers but not advertise them.  However, Daniel Stone and others, if=20
you think this will actually break userspace in other ways (Could you=20
describe in a bit more detail or point me to test cases if so?), I=20
suppose the only option would be to advertise & accept the old modifiers=20
for now, and I suppose at a config option at some point to phase the old=20
ones out, eventually drop them entirely.  This would be unfortunate,=20
because as I mentioned, it could sometimes result in situations where=20
apps think they can share a buffer between two devices but will get=20
garbled data in practice.

I've included an initial version of the kernel patch inline below.=20
Needs more testing, but I wanted to share it in case anyone has feedback=20
on the idea, wants to see the general workflow, or wants to help test.

>>> There's no attempt to verify the DRM-KMS device supports the modifier,
>>> but then, why would there be?=C2=A0 GBM presumably chose a supported mo=
difier
>>> at buffer creation time, and we don't know which plane the FB is going
>>> to be used with yet.=C2=A0 GBM doesn't actually ask the kernel which
>>> modifiers it supports here either though.
>>
>> Right, it doesn't ask, because userspace tells it which modifiers to
>> use. The correct behaviour is to take the list from the KMS
>> `IN_FORMATS` property and then pass that to
>> `gbm_(bo|surface)_create_with_modifiers`; GBM must then select from
>> that list and only that list. If that call does not succeed and Xorg
>> falls back to `gbm_surface_create`, then it must not call
>> `gbm_bo_get_modifier` - so that would be a modesetting bug. If that
>> call does succeed and `gbm_bo_get_modifier` subsequently reports a
>> modifier which was not in the list, that's a Mesa driver bug.
>>
>>> It just goes into Mesa via
>>> DRI and reports the modifier (unpatched) Mesa chose on its own.=C2=A0 M=
esa
>>> just hard-codes the modifiers in its driver backends since its thinking
>>> in terms of a device's 3D engine, not display.=C2=A0 In theory, Mesa's =
DRI
>>> drivers could query KMS for supported modifiers if allocating from GBM
>>> using the non-modifiers path and the SCANOUT flag is set (perhaps some
>>> drivers do this or its equivalent?=C2=A0 Haven't checked.), but that se=
ems
>>> pretty gnarly and doesn't fix the modifier-based GBM allocation path
>>> AFAIK.=C2=A0 Bit of a mess.
>>
>> Two options for GBM users:
>> * call gbm_*_create_with_modifiers, it succeeds, call
>> gbm_bo_get_modifier, pass modifier into AddFB
>> * call gbm_*_create (without modifiers), it succeeds, do not call
>> gbm_bo_get_modifier, do not pass a modifier into AddFB
>>
>> Anything else is a bug in the user. Note that falling back from 1 to 2
>> is fine: if `gbm_*_create_with_modifiers()` fails, you can fall back
>> to the non-modifier path, provided you don't later try to get a
>> modifier back out.
>>
>>> For a quick userspace fix that could probably be pushed out everywhere
>>> (Only affects Xorg server 1.20+ AFAIK), just retrying
>>> drmModeAddFB2WithModifiers() without the DRM_MODE_FB_MODIFIERS flag on
>>> failure should be sufficient.
>>
>> This would break other drivers.
>=20
> I think this could be done in a way that wouldn't, though it wouldn't be=
=20
> quite as simple.=C2=A0 Let's see what the true root cause is first though=
.
>=20
>>> Still need to verify as I'm having
>>> trouble wrangling my Xorg build at the moment and I'm pressed for time.
>>> A more complete fix would be quite involved, as modesetting isn't reall=
y
>>> properly plumbed to validate GBM's modifiers against KMS planes, and it
>>> doesn't seem like GBM/Mesa/DRI should be responsible for this as noted
>>> above given the general modifier workflow/design.
>>>
>>> Most importantly, options I've considered for fixing from the kernel=20
>>> side:
>>>
>>> -Accept "legacy" modifiers in nouveau in addition to the new modifiers,
>>> though avoid reporting them to userspace as supported to avoid further
>>> proliferation.=C2=A0 This is pretty straightforward.=C2=A0 I'll need to=
 modify
>>> both the AddFB2 handler (nouveau_validate_decode_mod) and the mode set
>>> plane validation logic (nv50_plane_format_mod_supported), but it should
>>> end up just being a few lines of code.
>>
>> I do think that they should also be reported to userspace if they are
>> accepted. Other users can and do look at the modifier list to see if
>> the buffer is acceptable for a given plane, so the consistency is good
>> here. Of course, in Mesa you would want to prioritise the new
>> modifiers over the legacy ones, and not allocate or return the legacy
>> ones unless that was all you were asked for. This would involve
>> tracking the used modifier explicitly through Mesa, rather than
>> throwing it away at alloc time and then later divining it from the
>> tiling mode.
>=20
> Reporting them as supported is equivalent to reporting support for a=20
> memory layout the chips don't actually support (It corresponds to a=20
> valid layout on Tegra chips, but not on discrete NV chips).=C2=A0 This is=
=20
> what the new modifiers are trying to avoid in the first place: Implying=20
> buffers can be shared between these Tegra chips and discrete NV GPUs.
>=20
> Thanks,
> -James
>=20
>> Cheers,
>> Daniel
>>

nouveau: Accept 'legacy' format modifiers

Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
---
  drivers/gpu/drm/nouveau/nouveau_display.c | 26 +++++++++++++++++++++--
  1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c=20
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 496c4621cc78..31543086254b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
  		   uint32_t *tile_mode,
  		   uint8_t *kind)
  {
+	struct nouveau_display *disp =3D nouveau_display(drm->dev);
  	BUG_ON(!tile_mode || !kind);

+	if ((modifier & (0xffull << 12)) =3D=3D 0ull) {
+		/* Legacy modifier.  Translate to this device's 'kind.' */
+		modifier |=3D disp->format_modifiers[0] & (0xffull << 12);
+	}
+
  	if (modifier =3D=3D DRM_FORMAT_MOD_LINEAR) {
  		/* tile_mode will not be used in this case */
  		*tile_mode =3D 0;
@@ -227,6 +233,16 @@ nouveau_framebuffer_get_layout(struct=20
drm_framebuffer *fb,
  	}
  }

+static const u64 legacy_modifiers[] =3D {
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0),
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1),
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2),
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3),
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4),
+	DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5),
+	DRM_FORMAT_MOD_INVALID
+};
+
  static int
  nouveau_validate_decode_mod(struct nouveau_drm *drm,
  			    uint64_t modifier,
@@ -247,8 +263,14 @@ nouveau_validate_decode_mod(struct nouveau_drm *drm,
  	     (disp->format_modifiers[mod] !=3D modifier);
  	     mod++);

-	if (disp->format_modifiers[mod] =3D=3D DRM_FORMAT_MOD_INVALID)
-		return -EINVAL;
+	if (disp->format_modifiers[mod] =3D=3D DRM_FORMAT_MOD_INVALID) {
+		for (mod =3D 0;
+		     (legacy_modifiers[mod] !=3D DRM_FORMAT_MOD_INVALID) &&
+		     (legacy_modifiers[mod] !=3D modifier);
+		     mod++);
+		if (legacy_modifiers[mod] =3D=3D DRM_FORMAT_MOD_INVALID)
+			return -EINVAL;
+	}

  	nouveau_decode_mod(drm, modifier, tile_mode, kind);

--=20
2.17.1


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=GbPa=AO=lists.freedesktop.org=dri-devel-bounces@kernel.org>
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=-5.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 49C78C433DF
	for <dri-devel@archiver.kernel.org>; Fri,  3 Jul 2020 06:01:54 +0000 (UTC)
Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id 169F22075D
	for <dri-devel@archiver.kernel.org>; Fri,  3 Jul 2020 06:01:53 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=fail reason="signature verification failed" (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="MNpH087T"
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 169F22075D
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org
Received: from gabe.freedesktop.org (localhost [127.0.0.1])
	by gabe.freedesktop.org (Postfix) with ESMTP id ED0D06E8C5;
	Fri,  3 Jul 2020 06:01:52 +0000 (UTC)
Received: from hqnvemgate25.nvidia.com (hqnvemgate25.nvidia.com
 [216.228.121.64])
 by gabe.freedesktop.org (Postfix) with ESMTPS id 2AFAE6E8C5
 for <dri-devel@lists.freedesktop.org>; Fri,  3 Jul 2020 06:01:52 +0000 (UTC)
Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by
 hqnvemgate25.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA)
 id <B5efec99c0000>; Thu, 02 Jul 2020 23:01:00 -0700
Received: from hqmail.nvidia.com ([172.20.161.6])
 by hqpgpgate101.nvidia.com (PGP Universal service);
 Thu, 02 Jul 2020 23:01:51 -0700
X-PGP-Universal: processed;
 by hqpgpgate101.nvidia.com on Thu, 02 Jul 2020 23:01:51 -0700
Received: from [172.20.40.54] (172.20.13.39) by HQMAIL107.nvidia.com
 (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 3 Jul
 2020 06:01:51 +0000
Subject: Re: [git pull] drm for 5.8-rc1
From: James Jones <jajones@nvidia.com>
To: Daniel Stone <daniel@fooishbar.org>
References: <CAPM=9txGww+omvateOTizZRV9_wLdAbq6uAz3DRa_S6bn1jQuQ@mail.gmail.com>
 <20200630230808.wj2xlt44vrszqfzx@box>
 <ef7816b4-72ee-9e0e-8cac-4d80d8343f9f@nvidia.com>
 <20200701075719.p7h5zypdtlhqxtgv@box> <20200701075902.hhmaskxtjsm4bcx7@box>
 <77e744b9-b5e2-9e9b-44c1-98584d2ae2f3@nvidia.com>
 <CAPj87rOrUHBZZR3cw+iqUMtZL1ZQyjd=RoM2yHt5oUeRO5uDTA@mail.gmail.com>
 <5ffa32db-4383-80f6-c0cf-a9bb12e729aa@nvidia.com>
X-Nvconfidentiality: public
Message-ID: <a3d331e9-d17e-9135-68c7-8e3e10df184d@nvidia.com>
Date: Thu, 2 Jul 2020 23:01:54 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <5ffa32db-4383-80f6-c0cf-a9bb12e729aa@nvidia.com>
X-Originating-IP: [172.20.13.39]
X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To
 HQMAIL107.nvidia.com (172.20.187.13)
Content-Language: en-US
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
 t=1593756060; bh=oey+lAcqjyvtPJCijFnrSu5cD1hCcZdlv0Qpemv2n5g=;
 h=X-PGP-Universal:Subject:From:To:CC:References:X-Nvconfidentiality:
 Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:
 X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language:
 Content-Transfer-Encoding;
 b=MNpH087ToCVSf2E1woo+gOhwKNnLwwmyP5dNaRXSCmmnzsRwSS9I9Iaex2v+2Alh+
 dztiqsiU+4thD0DK8NPqqihMwtXAntz1bnQRG85WZq/vlbn78KZ+iRXwDhhjJx69xw
 MGrlm1z5T8IKwdV5BJxExHAdCklx66RgwMV5KARhUSkuRNcw+dASGzoBTU7SiNFKZi
 zU6ZQ0O3W+EYoeDztWzbS17i/M+9hsv6EChdDx85FiAf9tvoKiTrVwZadUzAA7rrHp
 nZbeTMF7dCDsBf4rkqmRqP7Bmh5HRgUDE/FvRZNsUTeBUr02EdBaMO5yi53IyZzx65
 U8RT9QToM7UHQ==
X-BeenThere: dri-devel@lists.freedesktop.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Direct Rendering Infrastructure - Development
 <dri-devel.lists.freedesktop.org>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, LKML <linux-kernel@vger.kernel.org>,
 dri-devel <dri-devel@lists.freedesktop.org>, Ben Skeggs <bskeggs@redhat.com>,
 "Kirill A. Shutemov" <kirill@shutemov.name>,
 Linus Torvalds <torvalds@linux-foundation.org>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel" <dri-devel-bounces@lists.freedesktop.org>

T24gNy8yLzIwIDI6MTQgUE0sIEphbWVzIEpvbmVzIHdyb3RlOgo+IE9uIDcvMi8yMCAxOjIyIEFN
LCBEYW5pZWwgU3RvbmUgd3JvdGU6Cj4+IEhpLAo+Pgo+PiBPbiBXZWQsIDEgSnVsIDIwMjAgYXQg
MjA6NDUsIEphbWVzIEpvbmVzIDxqYWpvbmVzQG52aWRpYS5jb20+IHdyb3RlOgo+Pj4gT0ssIEkg
dGhpbmsgSSBzZWUgd2hhdCdzIGdvaW5nIG9uLsKgIEluIHRoZSBYb3JnIG1vZGVzZXR0aW5nIGRy
aXZlciwgdGhlCj4+PiBsb2dpYyBpcyBiYXNpY2FsbHk6Cj4+Pgo+Pj4gaWYgKGdibV9oYXNfbW9k
aWZpZXJzICYmIERSTV9DQVBfQURERkIyX01PRElGSUVSUyAhPSAwKSB7Cj4+PiDCoMKgwqAgZHJt
TW9kZUFkZEZCMldpdGhNb2RpZmllcnMoLi4uLCBnYm1fYm9fZ2V0X21vZGlmaWVyKGJvLT5nYm0p
KTsKPj4+IH0gZWxzZSB7Cj4+PiDCoMKgwqAgZHJtTW9kZUFkZEZCKC4uLik7Cj4+PiB9Cj4+Cj4+
IEkgcmVhZCB0aGlzIHRocmVhZCBleHBlY3RpbmcgdG8gZXhwbGFpbiB0aGUgY29ycmVjdCBiZWhh
dmlvdXIgd2UKPj4gaW1wbGVtZW50IGluIFdlc3RvbiBhbmQgaG93IG1vZGVzZXR0aW5nIG5lZWRz
IHRvIGJlIGZpeGVkLCBidXQgLi4uCj4+IHRoYXQgc2VlbXMgT0sgdG8gbWU/IEFzIGxvbmcgYXMg
YGdibV9oYXNfbW9kaWZpZXJzYCBpcyBhIHByb3h5IGZvciAnd2UKPj4gdXNlZCBnYm1fKGJvfHN1
cmZhY2UpX2NyZWF0ZV93aXRoX21vZGlmaWVycyB0byBhbGxvY2F0ZSB0aGUgYnVmZmVyJy4KPiAK
PiBZZXMsIHRoZSBoYXphcmRzIG9mIHJlcG9ydGluZyBmaW5kaW5ncyBiZWZvcmUgdmVyaWZ5aW5n
LsKgIEkgbm93IHNlZSAKPiBtb2Rlc2V0dGluZyBkb2VzIHF1ZXJ5IHRoZSBEUk0tS01TIG1vZGlm
aWVycyBhbmQgYXR0ZW1wdCB0byBhbGxvY2F0ZSAKPiB3aXRoIHRoZW0gaWYgaXQgZm91bmQgYW55
LsKgIEhvd2V2ZXIsIEkgc3RpbGwgc2VlIGEgbG90IG9mIHdheXMgdGhpbmdzIAo+IGNhbiBnbyB3
cm9uZywgYnV0IEknbSBub3QgZ29pbmcgdG8gc2hhcmUgbXkgc3BlY3VsYXRpb24gYWdhaW4gdW50
aWwgSSd2ZSAKPiBhY3R1YWxseSB2ZXJpZmllZCBpdCwgd2hpY2ggaXMgdGFraW5nIGEgZnJ1c3Ry
YXRpbmdseSBsb25nIHRpbWUuwqAgVGhlIAo+IG1vZGVzZXR0aW5nIGRyaXZlciBpcyBub3QgbXkg
ZnJpZW5kIHJpZ2h0IG5vdy4KCk9LLCBzZXZlcmFsIGhvdXJzIG9mIGR1bWIgYnVpbGQrY29uZmln
IG1pc3Rha2VzIGxhdGVyLCBJIHdhcyBhY3R1YWxseSAKYWJsZSB0byByZXByb2R1Y2UgdGhlIGZh
aWx1cmUgYW5kIHdhbGsgdGhyb3VnaCB0aGluZ3MuICBUaGVyZSBpcyBhIAp0cml2aWFsIGZpeCBm
b3IgdGhlIGlzc3VlcyBpbiB0aGUgWCBtb2Rlc2V0dGluZyBkcml2ZXIsIHdvcmtpbmcgb2ZmIApE
YW5pZWwgU3RvbmUncyBjbGFpbSB0aGF0IGdibV9ib19nZXRfbW9kaWZpZXIoKSBzaG91bGQgb25s
eSBiZSBjYWxsZWQgCndoZW4gdGhlIGFsbG9jYXRpb24gd2FzIG1hZGUgd2l0aCBnYm1fYm9fY3Jl
YXRlX3dpdGhfbW9kaWZpZXJzKCkuIAptb2Rlc2V0IGRvZXNuJ3QgcmVzcGVjdCB0aGF0IHJlcXVp
cmVtZW50IG5vdyBpbiB0aGUgY2FzZSB0aGF0IHRoZSBhdG9taWMgCm1vZGVzZXR0aW5nIHBhdGgg
aXMgZGlzYWJsZWQsIHdoaWNoIGlzIGFsd2F5cyB0aGUgY2FzZSBjdXJyZW50bHkgYmVjYXVzZSAK
dGhhdCBwYXRoIGlzIGJyb2tlbi4gIFJlc3BlY3RpbmcgdGhhdCByZXF1aXJlbWVudCBpcyBhIGhh
bGYtbGluZXIgYW5kIAphbGxvd3MgWCB0byBzdGFydCBwcm9wZXJseS4KCklmIEkgZm9yY2UgbW9k
ZXNldCB0byB1c2UgdGhlIGF0b21pYyBwYXRoLCBYIHN0aWxsIGZhaWxzIHRvIHN0YXJ0IHdpdGgg
CnRoZSBhYm92ZSBmaXgsIHZhbGlkYXRpbmcgdGhlIHNlY29uZCB0aGVvcnkgSSdkIGhhZDoKCi1D
dXJyZW50IE1lc2Egbm91dmVhdSBjb2RlIGJhc2ljYWxseSBpZ25vcmVzIHRoZSBtb2RpZmllciBs
aXN0IHBhc3NlZCBpbiAKdW5sZXNzIGl0IGlzIGEgc2luZ2xlIG1vZGlmaWVyIHJlcXVlc3Rpbmcg
bGluZWFyIGxheW91dCwgYW5kIGdvZXMgYWJvdXQgCmFsbG9jYXRpbmcgd2hhdGV2ZXIgbGF5b3V0
IGl0IHNlZXMgZml0LCBhbmQgc3VjY2VlZHMgdGhlIGFsbG9jYXRpb24gCmRlc3BpdGUgYmVpbmcg
cGFzc2VkIGEgbGlzdCBvZiBtb2RpZmllcnMgaXQga25vd3Mgbm90aGluZyBhYm91dC4gIE5vdCAK
Z3JlYXQsIGZpeGVkIGluIG15IHBlbmRpbmcgcGF0Y2hlcywgb2J2aW91c2x5IGRvZXNuJ3QgaGVs
cCBleGlzdGluZyAKZGVwbG95ZWQgdXNlcnNwYWNlLgoKLUN1cnJlbnQgTWVzYSBub3V2ZWF1IGNv
ZGUsIHdoZW4gYXNrZWQgd2hhdCBtb2RpZmllciBpdCB1c2VkIGZvciB0aGUgCmFib3ZlIGFsbG9j
YXRpb24sIHJldHVybnMgb25lIG9mIHRoZSAibGVnYWN5IiBtb2RpZmllcnMgbm91dmVhdSBEUk0t
S01TIAprbm93cyBub3RoaW5nIGFib3V0LgoKLVdoZW4gdGhlIG1vZGVzZXQgZHJpdmVyIHRyaWVz
IHRvIGNyZWF0ZSBhbiBGQiBmb3IgdGhhdCBCTyB3aXRoIHRoZSAKcmV0dXJuZWQgbW9kaWZpZXIs
IHRoZSBub3V2ZWF1IGtlcm5lbCBkcml2ZXIgb2YgY291cnNlIHJlZnVzZXMuCgpJIHRoaW5rIGl0
J3MgcHJvYmFibHkgd29ydGggZml4aW5nIHRoZSBtb2Rlc2V0dGluZyBkcml2ZXIgZm9yIHRoZSAK
cmVhc29ucyBEYW5pZWwgVmV0dGVyIG1lbnRpb25lZC4gIFRoZW4gaWYgSSBnZXQgbXkgTWVzYSBw
YXRjaGVzIGluIApiZWZvcmUgYSBuZXcgbW9kZXNldHRpbmcgZHJpdmVyIHdpdGggd29ya2luZyBB
dG9taWMgc3VwcG9ydCBpcyByZWxlYXNlZCwgCnRoZXJlJ2xsIGJlIG5vIG5lZWQgZm9yIGxvbmct
dGVybSB3b3JrYXJvdW5kcyBpbiB0aGUga2VybmVsLgoKRG93biB0byB0aGUgcmVhbCBxdWVzdGlv
biBvZiB3aGF0IHRvIGRvIGluIHRoZSBrZXJuZWwgdG8gc3VwcG9ydCBjdXJyZW50IAp1c2Vyc3Bh
Y2UgY29kZTogSSBzdGlsbCB0aGluayB0aGUgYmVzdCBmaXggaXMgdG8gYWNjZXB0IHRoZSBvbGQg
Cm1vZGlmaWVycyBidXQgbm90IGFkdmVydGlzZSB0aGVtLiAgSG93ZXZlciwgRGFuaWVsIFN0b25l
IGFuZCBvdGhlcnMsIGlmIAp5b3UgdGhpbmsgdGhpcyB3aWxsIGFjdHVhbGx5IGJyZWFrIHVzZXJz
cGFjZSBpbiBvdGhlciB3YXlzIChDb3VsZCB5b3UgCmRlc2NyaWJlIGluIGEgYml0IG1vcmUgZGV0
YWlsIG9yIHBvaW50IG1lIHRvIHRlc3QgY2FzZXMgaWYgc28/KSwgSSAKc3VwcG9zZSB0aGUgb25s
eSBvcHRpb24gd291bGQgYmUgdG8gYWR2ZXJ0aXNlICYgYWNjZXB0IHRoZSBvbGQgbW9kaWZpZXJz
IApmb3Igbm93LCBhbmQgSSBzdXBwb3NlIGF0IGEgY29uZmlnIG9wdGlvbiBhdCBzb21lIHBvaW50
IHRvIHBoYXNlIHRoZSBvbGQgCm9uZXMgb3V0LCBldmVudHVhbGx5IGRyb3AgdGhlbSBlbnRpcmVs
eS4gIFRoaXMgd291bGQgYmUgdW5mb3J0dW5hdGUsIApiZWNhdXNlIGFzIEkgbWVudGlvbmVkLCBp
dCBjb3VsZCBzb21ldGltZXMgcmVzdWx0IGluIHNpdHVhdGlvbnMgd2hlcmUgCmFwcHMgdGhpbmsg
dGhleSBjYW4gc2hhcmUgYSBidWZmZXIgYmV0d2VlbiB0d28gZGV2aWNlcyBidXQgd2lsbCBnZXQg
CmdhcmJsZWQgZGF0YSBpbiBwcmFjdGljZS4KCkkndmUgaW5jbHVkZWQgYW4gaW5pdGlhbCB2ZXJz
aW9uIG9mIHRoZSBrZXJuZWwgcGF0Y2ggaW5saW5lIGJlbG93LiAKTmVlZHMgbW9yZSB0ZXN0aW5n
LCBidXQgSSB3YW50ZWQgdG8gc2hhcmUgaXQgaW4gY2FzZSBhbnlvbmUgaGFzIGZlZWRiYWNrIApv
biB0aGUgaWRlYSwgd2FudHMgdG8gc2VlIHRoZSBnZW5lcmFsIHdvcmtmbG93LCBvciB3YW50cyB0
byBoZWxwIHRlc3QuCgo+Pj4gVGhlcmUncyBubyBhdHRlbXB0IHRvIHZlcmlmeSB0aGUgRFJNLUtN
UyBkZXZpY2Ugc3VwcG9ydHMgdGhlIG1vZGlmaWVyLAo+Pj4gYnV0IHRoZW4sIHdoeSB3b3VsZCB0
aGVyZSBiZT/CoCBHQk0gcHJlc3VtYWJseSBjaG9zZSBhIHN1cHBvcnRlZCBtb2RpZmllcgo+Pj4g
YXQgYnVmZmVyIGNyZWF0aW9uIHRpbWUsIGFuZCB3ZSBkb24ndCBrbm93IHdoaWNoIHBsYW5lIHRo
ZSBGQiBpcyBnb2luZwo+Pj4gdG8gYmUgdXNlZCB3aXRoIHlldC7CoCBHQk0gZG9lc24ndCBhY3R1
YWxseSBhc2sgdGhlIGtlcm5lbCB3aGljaAo+Pj4gbW9kaWZpZXJzIGl0IHN1cHBvcnRzIGhlcmUg
ZWl0aGVyIHRob3VnaC4KPj4KPj4gUmlnaHQsIGl0IGRvZXNuJ3QgYXNrLCBiZWNhdXNlIHVzZXJz
cGFjZSB0ZWxscyBpdCB3aGljaCBtb2RpZmllcnMgdG8KPj4gdXNlLiBUaGUgY29ycmVjdCBiZWhh
dmlvdXIgaXMgdG8gdGFrZSB0aGUgbGlzdCBmcm9tIHRoZSBLTVMKPj4gYElOX0ZPUk1BVFNgIHBy
b3BlcnR5IGFuZCB0aGVuIHBhc3MgdGhhdCB0bwo+PiBgZ2JtXyhib3xzdXJmYWNlKV9jcmVhdGVf
d2l0aF9tb2RpZmllcnNgOyBHQk0gbXVzdCB0aGVuIHNlbGVjdCBmcm9tCj4+IHRoYXQgbGlzdCBh
bmQgb25seSB0aGF0IGxpc3QuIElmIHRoYXQgY2FsbCBkb2VzIG5vdCBzdWNjZWVkIGFuZCBYb3Jn
Cj4+IGZhbGxzIGJhY2sgdG8gYGdibV9zdXJmYWNlX2NyZWF0ZWAsIHRoZW4gaXQgbXVzdCBub3Qg
Y2FsbAo+PiBgZ2JtX2JvX2dldF9tb2RpZmllcmAgLSBzbyB0aGF0IHdvdWxkIGJlIGEgbW9kZXNl
dHRpbmcgYnVnLiBJZiB0aGF0Cj4+IGNhbGwgZG9lcyBzdWNjZWVkIGFuZCBgZ2JtX2JvX2dldF9t
b2RpZmllcmAgc3Vic2VxdWVudGx5IHJlcG9ydHMgYQo+PiBtb2RpZmllciB3aGljaCB3YXMgbm90
IGluIHRoZSBsaXN0LCB0aGF0J3MgYSBNZXNhIGRyaXZlciBidWcuCj4+Cj4+PiBJdCBqdXN0IGdv
ZXMgaW50byBNZXNhIHZpYQo+Pj4gRFJJIGFuZCByZXBvcnRzIHRoZSBtb2RpZmllciAodW5wYXRj
aGVkKSBNZXNhIGNob3NlIG9uIGl0cyBvd24uwqAgTWVzYQo+Pj4ganVzdCBoYXJkLWNvZGVzIHRo
ZSBtb2RpZmllcnMgaW4gaXRzIGRyaXZlciBiYWNrZW5kcyBzaW5jZSBpdHMgdGhpbmtpbmcKPj4+
IGluIHRlcm1zIG9mIGEgZGV2aWNlJ3MgM0QgZW5naW5lLCBub3QgZGlzcGxheS7CoCBJbiB0aGVv
cnksIE1lc2EncyBEUkkKPj4+IGRyaXZlcnMgY291bGQgcXVlcnkgS01TIGZvciBzdXBwb3J0ZWQg
bW9kaWZpZXJzIGlmIGFsbG9jYXRpbmcgZnJvbSBHQk0KPj4+IHVzaW5nIHRoZSBub24tbW9kaWZp
ZXJzIHBhdGggYW5kIHRoZSBTQ0FOT1VUIGZsYWcgaXMgc2V0IChwZXJoYXBzIHNvbWUKPj4+IGRy
aXZlcnMgZG8gdGhpcyBvciBpdHMgZXF1aXZhbGVudD/CoCBIYXZlbid0IGNoZWNrZWQuKSwgYnV0
IHRoYXQgc2VlbXMKPj4+IHByZXR0eSBnbmFybHkgYW5kIGRvZXNuJ3QgZml4IHRoZSBtb2RpZmll
ci1iYXNlZCBHQk0gYWxsb2NhdGlvbiBwYXRoCj4+PiBBRkFJSy7CoCBCaXQgb2YgYSBtZXNzLgo+
Pgo+PiBUd28gb3B0aW9ucyBmb3IgR0JNIHVzZXJzOgo+PiAqIGNhbGwgZ2JtXypfY3JlYXRlX3dp
dGhfbW9kaWZpZXJzLCBpdCBzdWNjZWVkcywgY2FsbAo+PiBnYm1fYm9fZ2V0X21vZGlmaWVyLCBw
YXNzIG1vZGlmaWVyIGludG8gQWRkRkIKPj4gKiBjYWxsIGdibV8qX2NyZWF0ZSAod2l0aG91dCBt
b2RpZmllcnMpLCBpdCBzdWNjZWVkcywgZG8gbm90IGNhbGwKPj4gZ2JtX2JvX2dldF9tb2RpZmll
ciwgZG8gbm90IHBhc3MgYSBtb2RpZmllciBpbnRvIEFkZEZCCj4+Cj4+IEFueXRoaW5nIGVsc2Ug
aXMgYSBidWcgaW4gdGhlIHVzZXIuIE5vdGUgdGhhdCBmYWxsaW5nIGJhY2sgZnJvbSAxIHRvIDIK
Pj4gaXMgZmluZTogaWYgYGdibV8qX2NyZWF0ZV93aXRoX21vZGlmaWVycygpYCBmYWlscywgeW91
IGNhbiBmYWxsIGJhY2sKPj4gdG8gdGhlIG5vbi1tb2RpZmllciBwYXRoLCBwcm92aWRlZCB5b3Ug
ZG9uJ3QgbGF0ZXIgdHJ5IHRvIGdldCBhCj4+IG1vZGlmaWVyIGJhY2sgb3V0Lgo+Pgo+Pj4gRm9y
IGEgcXVpY2sgdXNlcnNwYWNlIGZpeCB0aGF0IGNvdWxkIHByb2JhYmx5IGJlIHB1c2hlZCBvdXQg
ZXZlcnl3aGVyZQo+Pj4gKE9ubHkgYWZmZWN0cyBYb3JnIHNlcnZlciAxLjIwKyBBRkFJSyksIGp1
c3QgcmV0cnlpbmcKPj4+IGRybU1vZGVBZGRGQjJXaXRoTW9kaWZpZXJzKCkgd2l0aG91dCB0aGUg
RFJNX01PREVfRkJfTU9ESUZJRVJTIGZsYWcgb24KPj4+IGZhaWx1cmUgc2hvdWxkIGJlIHN1ZmZp
Y2llbnQuCj4+Cj4+IFRoaXMgd291bGQgYnJlYWsgb3RoZXIgZHJpdmVycy4KPiAKPiBJIHRoaW5r
IHRoaXMgY291bGQgYmUgZG9uZSBpbiBhIHdheSB0aGF0IHdvdWxkbid0LCB0aG91Z2ggaXQgd291
bGRuJ3QgYmUgCj4gcXVpdGUgYXMgc2ltcGxlLsKgIExldCdzIHNlZSB3aGF0IHRoZSB0cnVlIHJv
b3QgY2F1c2UgaXMgZmlyc3QgdGhvdWdoLgo+IAo+Pj4gU3RpbGwgbmVlZCB0byB2ZXJpZnkgYXMg
SSdtIGhhdmluZwo+Pj4gdHJvdWJsZSB3cmFuZ2xpbmcgbXkgWG9yZyBidWlsZCBhdCB0aGUgbW9t
ZW50IGFuZCBJJ20gcHJlc3NlZCBmb3IgdGltZS4KPj4+IEEgbW9yZSBjb21wbGV0ZSBmaXggd291
bGQgYmUgcXVpdGUgaW52b2x2ZWQsIGFzIG1vZGVzZXR0aW5nIGlzbid0IHJlYWxseQo+Pj4gcHJv
cGVybHkgcGx1bWJlZCB0byB2YWxpZGF0ZSBHQk0ncyBtb2RpZmllcnMgYWdhaW5zdCBLTVMgcGxh
bmVzLCBhbmQgaXQKPj4+IGRvZXNuJ3Qgc2VlbSBsaWtlIEdCTS9NZXNhL0RSSSBzaG91bGQgYmUg
cmVzcG9uc2libGUgZm9yIHRoaXMgYXMgbm90ZWQKPj4+IGFib3ZlIGdpdmVuIHRoZSBnZW5lcmFs
IG1vZGlmaWVyIHdvcmtmbG93L2Rlc2lnbi4KPj4+Cj4+PiBNb3N0IGltcG9ydGFudGx5LCBvcHRp
b25zIEkndmUgY29uc2lkZXJlZCBmb3IgZml4aW5nIGZyb20gdGhlIGtlcm5lbCAKPj4+IHNpZGU6
Cj4+Pgo+Pj4gLUFjY2VwdCAibGVnYWN5IiBtb2RpZmllcnMgaW4gbm91dmVhdSBpbiBhZGRpdGlv
biB0byB0aGUgbmV3IG1vZGlmaWVycywKPj4+IHRob3VnaCBhdm9pZCByZXBvcnRpbmcgdGhlbSB0
byB1c2Vyc3BhY2UgYXMgc3VwcG9ydGVkIHRvIGF2b2lkIGZ1cnRoZXIKPj4+IHByb2xpZmVyYXRp
b24uwqAgVGhpcyBpcyBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkLsKgIEknbGwgbmVlZCB0byBtb2Rp
ZnkKPj4+IGJvdGggdGhlIEFkZEZCMiBoYW5kbGVyIChub3V2ZWF1X3ZhbGlkYXRlX2RlY29kZV9t
b2QpIGFuZCB0aGUgbW9kZSBzZXQKPj4+IHBsYW5lIHZhbGlkYXRpb24gbG9naWMgKG52NTBfcGxh
bmVfZm9ybWF0X21vZF9zdXBwb3J0ZWQpLCBidXQgaXQgc2hvdWxkCj4+PiBlbmQgdXAganVzdCBi
ZWluZyBhIGZldyBsaW5lcyBvZiBjb2RlLgo+Pgo+PiBJIGRvIHRoaW5rIHRoYXQgdGhleSBzaG91
bGQgYWxzbyBiZSByZXBvcnRlZCB0byB1c2Vyc3BhY2UgaWYgdGhleSBhcmUKPj4gYWNjZXB0ZWQu
IE90aGVyIHVzZXJzIGNhbiBhbmQgZG8gbG9vayBhdCB0aGUgbW9kaWZpZXIgbGlzdCB0byBzZWUg
aWYKPj4gdGhlIGJ1ZmZlciBpcyBhY2NlcHRhYmxlIGZvciBhIGdpdmVuIHBsYW5lLCBzbyB0aGUg
Y29uc2lzdGVuY3kgaXMgZ29vZAo+PiBoZXJlLiBPZiBjb3Vyc2UsIGluIE1lc2EgeW91IHdvdWxk
IHdhbnQgdG8gcHJpb3JpdGlzZSB0aGUgbmV3Cj4+IG1vZGlmaWVycyBvdmVyIHRoZSBsZWdhY3kg
b25lcywgYW5kIG5vdCBhbGxvY2F0ZSBvciByZXR1cm4gdGhlIGxlZ2FjeQo+PiBvbmVzIHVubGVz
cyB0aGF0IHdhcyBhbGwgeW91IHdlcmUgYXNrZWQgZm9yLiBUaGlzIHdvdWxkIGludm9sdmUKPj4g
dHJhY2tpbmcgdGhlIHVzZWQgbW9kaWZpZXIgZXhwbGljaXRseSB0aHJvdWdoIE1lc2EsIHJhdGhl
ciB0aGFuCj4+IHRocm93aW5nIGl0IGF3YXkgYXQgYWxsb2MgdGltZSBhbmQgdGhlbiBsYXRlciBk
aXZpbmluZyBpdCBmcm9tIHRoZQo+PiB0aWxpbmcgbW9kZS4KPiAKPiBSZXBvcnRpbmcgdGhlbSBh
cyBzdXBwb3J0ZWQgaXMgZXF1aXZhbGVudCB0byByZXBvcnRpbmcgc3VwcG9ydCBmb3IgYSAKPiBt
ZW1vcnkgbGF5b3V0IHRoZSBjaGlwcyBkb24ndCBhY3R1YWxseSBzdXBwb3J0IChJdCBjb3JyZXNw
b25kcyB0byBhIAo+IHZhbGlkIGxheW91dCBvbiBUZWdyYSBjaGlwcywgYnV0IG5vdCBvbiBkaXNj
cmV0ZSBOViBjaGlwcykuwqAgVGhpcyBpcyAKPiB3aGF0IHRoZSBuZXcgbW9kaWZpZXJzIGFyZSB0
cnlpbmcgdG8gYXZvaWQgaW4gdGhlIGZpcnN0IHBsYWNlOiBJbXBseWluZyAKPiBidWZmZXJzIGNh
biBiZSBzaGFyZWQgYmV0d2VlbiB0aGVzZSBUZWdyYSBjaGlwcyBhbmQgZGlzY3JldGUgTlYgR1BV
cy4KPiAKPiBUaGFua3MsCj4gLUphbWVzCj4gCj4+IENoZWVycywKPj4gRGFuaWVsCj4+Cgpub3V2
ZWF1OiBBY2NlcHQgJ2xlZ2FjeScgZm9ybWF0IG1vZGlmaWVycwoKQWNjZXB0IHRoZSBEUk1fRk9S
TUFUX01PRF9OVklESUFfMTZCWDJfQkxPQ0soKQpmYW1pbHkgb2YgbW9kaWZpZXJzIHRvIGhhbmRs
ZSBicm9rZW4gdXNlcnNwYWNlClhvcmcgbW9kZXNldHRpbmcgYW5kIE1lc2EgZHJpdmVycy4KLS0t
CiAgZHJpdmVycy9ncHUvZHJtL25vdXZlYXUvbm91dmVhdV9kaXNwbGF5LmMgfCAyNiArKysrKysr
KysrKysrKysrKysrKystLQogIDEgZmlsZSBjaGFuZ2VkLCAyNCBpbnNlcnRpb25zKCspLCAyIGRl
bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1L2RybS9ub3V2ZWF1L25vdXZlYXVf
ZGlzcGxheS5jIApiL2RyaXZlcnMvZ3B1L2RybS9ub3V2ZWF1L25vdXZlYXVfZGlzcGxheS5jCmlu
ZGV4IDQ5NmM0NjIxY2M3OC4uMzE1NDMwODYyNTRiIDEwMDY0NAotLS0gYS9kcml2ZXJzL2dwdS9k
cm0vbm91dmVhdS9ub3V2ZWF1X2Rpc3BsYXkuYworKysgYi9kcml2ZXJzL2dwdS9kcm0vbm91dmVh
dS9ub3V2ZWF1X2Rpc3BsYXkuYwpAQCAtMTkxLDggKzE5MSwxNCBAQCBub3V2ZWF1X2RlY29kZV9t
b2Qoc3RydWN0IG5vdXZlYXVfZHJtICpkcm0sCiAgCQkgICB1aW50MzJfdCAqdGlsZV9tb2RlLAog
IAkJICAgdWludDhfdCAqa2luZCkKICB7CisJc3RydWN0IG5vdXZlYXVfZGlzcGxheSAqZGlzcCA9
IG5vdXZlYXVfZGlzcGxheShkcm0tPmRldik7CiAgCUJVR19PTighdGlsZV9tb2RlIHx8ICFraW5k
KTsKCisJaWYgKChtb2RpZmllciAmICgweGZmdWxsIDw8IDEyKSkgPT0gMHVsbCkgeworCQkvKiBM
ZWdhY3kgbW9kaWZpZXIuICBUcmFuc2xhdGUgdG8gdGhpcyBkZXZpY2UncyAna2luZC4nICovCisJ
CW1vZGlmaWVyIHw9IGRpc3AtPmZvcm1hdF9tb2RpZmllcnNbMF0gJiAoMHhmZnVsbCA8PCAxMik7
CisJfQorCiAgCWlmIChtb2RpZmllciA9PSBEUk1fRk9STUFUX01PRF9MSU5FQVIpIHsKICAJCS8q
IHRpbGVfbW9kZSB3aWxsIG5vdCBiZSB1c2VkIGluIHRoaXMgY2FzZSAqLwogIAkJKnRpbGVfbW9k
ZSA9IDA7CkBAIC0yMjcsNiArMjMzLDE2IEBAIG5vdXZlYXVfZnJhbWVidWZmZXJfZ2V0X2xheW91
dChzdHJ1Y3QgCmRybV9mcmFtZWJ1ZmZlciAqZmIsCiAgCX0KICB9Cgorc3RhdGljIGNvbnN0IHU2
NCBsZWdhY3lfbW9kaWZpZXJzW10gPSB7CisJRFJNX0ZPUk1BVF9NT0RfTlZJRElBXzE2QlgyX0JM
T0NLKDApLAorCURSTV9GT1JNQVRfTU9EX05WSURJQV8xNkJYMl9CTE9DSygxKSwKKwlEUk1fRk9S
TUFUX01PRF9OVklESUFfMTZCWDJfQkxPQ0soMiksCisJRFJNX0ZPUk1BVF9NT0RfTlZJRElBXzE2
QlgyX0JMT0NLKDMpLAorCURSTV9GT1JNQVRfTU9EX05WSURJQV8xNkJYMl9CTE9DSyg0KSwKKwlE
Uk1fRk9STUFUX01PRF9OVklESUFfMTZCWDJfQkxPQ0soNSksCisJRFJNX0ZPUk1BVF9NT0RfSU5W
QUxJRAorfTsKKwogIHN0YXRpYyBpbnQKICBub3V2ZWF1X3ZhbGlkYXRlX2RlY29kZV9tb2Qoc3Ry
dWN0IG5vdXZlYXVfZHJtICpkcm0sCiAgCQkJICAgIHVpbnQ2NF90IG1vZGlmaWVyLApAQCAtMjQ3
LDggKzI2MywxNCBAQCBub3V2ZWF1X3ZhbGlkYXRlX2RlY29kZV9tb2Qoc3RydWN0IG5vdXZlYXVf
ZHJtICpkcm0sCiAgCSAgICAgKGRpc3AtPmZvcm1hdF9tb2RpZmllcnNbbW9kXSAhPSBtb2RpZmll
cik7CiAgCSAgICAgbW9kKyspOwoKLQlpZiAoZGlzcC0+Zm9ybWF0X21vZGlmaWVyc1ttb2RdID09
IERSTV9GT1JNQVRfTU9EX0lOVkFMSUQpCi0JCXJldHVybiAtRUlOVkFMOworCWlmIChkaXNwLT5m
b3JtYXRfbW9kaWZpZXJzW21vZF0gPT0gRFJNX0ZPUk1BVF9NT0RfSU5WQUxJRCkgeworCQlmb3Ig
KG1vZCA9IDA7CisJCSAgICAgKGxlZ2FjeV9tb2RpZmllcnNbbW9kXSAhPSBEUk1fRk9STUFUX01P
RF9JTlZBTElEKSAmJgorCQkgICAgIChsZWdhY3lfbW9kaWZpZXJzW21vZF0gIT0gbW9kaWZpZXIp
OworCQkgICAgIG1vZCsrKTsKKwkJaWYgKGxlZ2FjeV9tb2RpZmllcnNbbW9kXSA9PSBEUk1fRk9S
TUFUX01PRF9JTlZBTElEKQorCQkJcmV0dXJuIC1FSU5WQUw7CisJfQoKICAJbm91dmVhdV9kZWNv
ZGVfbW9kKGRybSwgbW9kaWZpZXIsIHRpbGVfbW9kZSwga2luZCk7CgotLSAKMi4xNy4xCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFp
bGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m
cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK