From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 E9918C4646B for ; Wed, 26 Jun 2019 07:53:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5B89A20B7C for ; Wed, 26 Jun 2019 07:53:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="dhnixGsy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727066AbfFZHxH (ORCPT ); Wed, 26 Jun 2019 03:53:07 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:40623 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726946AbfFZHxG (ORCPT ); Wed, 26 Jun 2019 03:53:06 -0400 Received: by mail-ot1-f65.google.com with SMTP id e8so1583253otl.7 for ; Wed, 26 Jun 2019 00:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gK6sTyPGkQBsRICOrU/v96WJmqJIHrnWAm3pchdZ41g=; b=dhnixGsyA2slTRiz9/IZXqyzJj+DNdLVG1xw0yaJZotw9dcpV5jLJAP5lOCnVQaycl j14Xs78Ap7s+m7sNn+ZBOpLwEUsTo1zP8VjLSDWRxxQXbeo8lz8SaArHZJyMC6Uvo9gv EmmGw0RuonOrOcm9M0DS3CBlhVro4tLFcehNk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gK6sTyPGkQBsRICOrU/v96WJmqJIHrnWAm3pchdZ41g=; b=hWEZJLCBsMzzskINv7M6RnQMuYTLVTK/7GUtUZxn37HsThENs0ZMXcWnZPsApMyZoK w1zd0bIwmrvfxbM10/DxxegZIQL4a3ovCP+M5YAwvZSDn68/kLnJthFUz3eHs9inLfxw jljem+YWyYisLCmMXFFyWqJzpxemduraOywUqQKokXVCdi4uDJQGHRjNs/evqGf8ISMP NzMfaZgvKNavcW0Z41DB4ZLwYrIQwc6T3lJc1Rfq8q3iZwCdx8UMcCVfOjZyNi+xa0w0 gr2f6lsGN101rLnPujRgaDHERmIKI/9pzcZKRaVTNKeQX/QXxjA2qCEUVj5U9TAkBCBy fZbg== X-Gm-Message-State: APjAAAWADAL2JGdPvz31DaXxdPEuIeFPt4cmCigWtPiG8R0iY/cAzR+z YHq5dQjQmfsQPKr4Liw5Kb+7bYnKLszFFXY1dnnDJg== X-Google-Smtp-Source: APXvYqyUs3Td+S7saRzPYCnaOjLCKshI6la+7/TjmiLqpBi3SV2mdzqTgrEw6uzagAHcAMFWXHb9UganSr1nLrAuZHo= X-Received: by 2002:a9d:6e8d:: with SMTP id a13mr2161271otr.303.1561535585757; Wed, 26 Jun 2019 00:53:05 -0700 (PDT) MIME-Version: 1.0 References: <20190619020750.swzerehjbvx6sbk2@smtp.gmail.com> <20190619074856.GJ12905@phenom.ffwll.local> <20190619075059.GK12905@phenom.ffwll.local> <20190626020005.vb5gmqcvkyzgcjee@smtp.gmail.com> In-Reply-To: <20190626020005.vb5gmqcvkyzgcjee@smtp.gmail.com> From: Daniel Vetter Date: Wed, 26 Jun 2019 09:52:54 +0200 Message-ID: Subject: Re: [Intel-gfx] [PATCH V4] drm/drm_vblank: Change EINVAL by the correct errno To: Rodrigo Siqueira Cc: Maarten Lankhorst , Maxime Ripard , Sean Paul , David Airlie , dri-devel , Linux Kernel Mailing List , kernel-janitors@vger.kernel.org, intel-gfx Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 26, 2019 at 4:00 AM Rodrigo Siqueira wrote: > > On 06/19, Daniel Vetter wrote: > > On Wed, Jun 19, 2019 at 09:48:56AM +0200, Daniel Vetter wrote: > > > On Tue, Jun 18, 2019 at 11:07:50PM -0300, Rodrigo Siqueira wrote: > > > > For historical reason, the function drm_wait_vblank_ioctl always re= turn > > > > -EINVAL if something gets wrong. This scenario limits the flexibili= ty > > > > for the userspace make detailed verification of the problem and tak= e > > > > some action. In particular, the validation of =E2=80=9Cif (!dev->ir= q_enabled)=E2=80=9D > > > > in the drm_wait_vblank_ioctl is responsible for checking if the dri= ver > > > > support vblank or not. If the driver does not support VBlank, the > > > > function drm_wait_vblank_ioctl returns EINVAL which does not repres= ent > > > > the real issue; this patch changes this behavior by return EOPNOTSU= PP. > > > > Additionally, some operations are unsupported by this function, and > > > > returns EINVAL; this patch also changes the return value to EOPNOTS= UPP > > > > in this case. Lastly, the function drm_wait_vblank_ioctl is invoked= by > > > > libdrm, which is used by many compositors; because of this, it is > > > > important to check if this change breaks any compositor. In this se= nse, > > > > the following projects were examined: > > > > > > > > * Drm-hwcomposer > > > > * Kwin > > > > * Sway > > > > * Wlroots > > > > * Wayland-core > > > > * Weston > > > > * Xorg (67 different drivers) > > > > > > > > For each repository the verification happened in three steps: > > > > > > > > * Update the main branch > > > > * Look for any occurrence "drmWaitVBlank" with the command: > > > > git grep -n "drmWaitVBlank" > > > > * Look in the git history of the project with the command: > > > > git log -SdrmWaitVBlank > > > > > > > > Finally, none of the above projects validate the use of EINVAL whic= h > > > > make safe, at least for these projects, to change the return values= . > > > > > > > > Change since V3: > > > > - Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel) > > > > > > > > Change since V2: > > > > Daniel Vetter and Chris Wilson > > > > - Replace ENOTTY by EOPNOTSUPP > > > > - Return EINVAL if the parameters are wrong > > > > > > > > > > Reviewed-by: Daniel Vetter > > > > > > Apologies for the confusion on the last time around. btw if someone t= ells > > > you "r-b (or a-b) with these changes", then just apply the r-b/a-b ta= g > > > next time around. Otherwise people will re-review the same thing over= and > > > over again. > > > > btw when resending patches it's good practice to add anyone who comment= ed > > on it (or who commented on the igt test for the same patch and other wa= y > > round) onto the explicit Cc: list of the patch. That way it's easier fo= r > > them to follow the patch evolution and do a quick r-b once they're happ= y. > > Thanks for these valuable tips. > Do you think that is a good idea to resend this patch CC's everybody? Or > is it ok if I just apply it? Hm I thought I answered that on irc ... but just today I realized that we missed 2 ioctls. There's also drm_crtc_get_sequence_ioctl and drm_crtc_queue_sequence_ioctl which have the same dev->irq_enabled check and I think should be treated the same. Can you pls resend with those addressed too? Then you can also resend with the cc's all added. -Daniel > > > If you don't do that then much bigger chances your patch gets ignored. > > -Daniel > > > > > > > Signed-off-by: Rodrigo Siqueira > > > > --- > > > > drivers/gpu/drm/drm_vblank.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vbl= ank.c > > > > index 603ab105125d..bed233361614 100644 > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > @@ -1582,7 +1582,7 @@ int drm_wait_vblank_ioctl(struct drm_device *= dev, void *data, > > > > unsigned int flags, pipe, high_pipe; > > > > > > > > if (!dev->irq_enabled) > > > > - return -EINVAL; > > > > + return -EOPNOTSUPP; > > > > > > > > if (vblwait->request.type & _DRM_VBLANK_SIGNAL) > > > > return -EINVAL; > > > > -- > > > > 2.21.0 > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > -- > Rodrigo Siqueira > https://siqueira.tech > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx --=20 Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Date: Wed, 26 Jun 2019 07:52:54 +0000 Subject: Re: [Intel-gfx] [PATCH V4] drm/drm_vblank: Change EINVAL by the correct errno Message-Id: List-Id: References: <20190619020750.swzerehjbvx6sbk2@smtp.gmail.com> <20190619074856.GJ12905@phenom.ffwll.local> <20190619075059.GK12905@phenom.ffwll.local> <20190626020005.vb5gmqcvkyzgcjee@smtp.gmail.com> In-Reply-To: <20190626020005.vb5gmqcvkyzgcjee@smtp.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Rodrigo Siqueira Cc: Maxime Ripard , kernel-janitors@vger.kernel.org, intel-gfx , Linux Kernel Mailing List , dri-devel , David Airlie On Wed, Jun 26, 2019 at 4:00 AM Rodrigo Siqueira wrote: > > On 06/19, Daniel Vetter wrote: > > On Wed, Jun 19, 2019 at 09:48:56AM +0200, Daniel Vetter wrote: > > > On Tue, Jun 18, 2019 at 11:07:50PM -0300, Rodrigo Siqueira wrote: > > > > For historical reason, the function drm_wait_vblank_ioctl always return > > > > -EINVAL if something gets wrong. This scenario limits the flexibility > > > > for the userspace make detailed verification of the problem and take > > > > some action. In particular, the validation of “if (!dev->irq_enabled)” > > > > in the drm_wait_vblank_ioctl is responsible for checking if the driver > > > > support vblank or not. If the driver does not support VBlank, the > > > > function drm_wait_vblank_ioctl returns EINVAL which does not represent > > > > the real issue; this patch changes this behavior by return EOPNOTSUPP. > > > > Additionally, some operations are unsupported by this function, and > > > > returns EINVAL; this patch also changes the return value to EOPNOTSUPP > > > > in this case. Lastly, the function drm_wait_vblank_ioctl is invoked by > > > > libdrm, which is used by many compositors; because of this, it is > > > > important to check if this change breaks any compositor. In this sense, > > > > the following projects were examined: > > > > > > > > * Drm-hwcomposer > > > > * Kwin > > > > * Sway > > > > * Wlroots > > > > * Wayland-core > > > > * Weston > > > > * Xorg (67 different drivers) > > > > > > > > For each repository the verification happened in three steps: > > > > > > > > * Update the main branch > > > > * Look for any occurrence "drmWaitVBlank" with the command: > > > > git grep -n "drmWaitVBlank" > > > > * Look in the git history of the project with the command: > > > > git log -SdrmWaitVBlank > > > > > > > > Finally, none of the above projects validate the use of EINVAL which > > > > make safe, at least for these projects, to change the return values. > > > > > > > > Change since V3: > > > > - Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel) > > > > > > > > Change since V2: > > > > Daniel Vetter and Chris Wilson > > > > - Replace ENOTTY by EOPNOTSUPP > > > > - Return EINVAL if the parameters are wrong > > > > > > > > > > Reviewed-by: Daniel Vetter > > > > > > Apologies for the confusion on the last time around. btw if someone tells > > > you "r-b (or a-b) with these changes", then just apply the r-b/a-b tag > > > next time around. Otherwise people will re-review the same thing over and > > > over again. > > > > btw when resending patches it's good practice to add anyone who commented > > on it (or who commented on the igt test for the same patch and other way > > round) onto the explicit Cc: list of the patch. That way it's easier for > > them to follow the patch evolution and do a quick r-b once they're happy. > > Thanks for these valuable tips. > Do you think that is a good idea to resend this patch CC's everybody? Or > is it ok if I just apply it? Hm I thought I answered that on irc ... but just today I realized that we missed 2 ioctls. There's also drm_crtc_get_sequence_ioctl and drm_crtc_queue_sequence_ioctl which have the same dev->irq_enabled check and I think should be treated the same. Can you pls resend with those addressed too? Then you can also resend with the cc's all added. -Daniel > > > If you don't do that then much bigger chances your patch gets ignored. > > -Daniel > > > > > > > Signed-off-by: Rodrigo Siqueira > > > > --- > > > > drivers/gpu/drm/drm_vblank.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > index 603ab105125d..bed233361614 100644 > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > @@ -1582,7 +1582,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void *data, > > > > unsigned int flags, pipe, high_pipe; > > > > > > > > if (!dev->irq_enabled) > > > > - return -EINVAL; > > > > + return -EOPNOTSUPP; > > > > > > > > if (vblwait->request.type & _DRM_VBLANK_SIGNAL) > > > > return -EINVAL; > > > > -- > > > > 2.21.0 > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > -- > Rodrigo Siqueira > https://siqueira.tech > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH V4] drm/drm_vblank: Change EINVAL by the correct errno Date: Wed, 26 Jun 2019 09:52:54 +0200 Message-ID: References: <20190619020750.swzerehjbvx6sbk2@smtp.gmail.com> <20190619074856.GJ12905@phenom.ffwll.local> <20190619075059.GK12905@phenom.ffwll.local> <20190626020005.vb5gmqcvkyzgcjee@smtp.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20190626020005.vb5gmqcvkyzgcjee@smtp.gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Rodrigo Siqueira Cc: Maxime Ripard , kernel-janitors@vger.kernel.org, intel-gfx , Linux Kernel Mailing List , dri-devel , David Airlie List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBKdW4gMjYsIDIwMTkgYXQgNDowMCBBTSBSb2RyaWdvIFNpcXVlaXJhCjxyb2RyaWdv c2lxdWVpcmFtZWxvQGdtYWlsLmNvbT4gd3JvdGU6Cj4KPiBPbiAwNi8xOSwgRGFuaWVsIFZldHRl ciB3cm90ZToKPiA+IE9uIFdlZCwgSnVuIDE5LCAyMDE5IGF0IDA5OjQ4OjU2QU0gKzAyMDAsIERh bmllbCBWZXR0ZXIgd3JvdGU6Cj4gPiA+IE9uIFR1ZSwgSnVuIDE4LCAyMDE5IGF0IDExOjA3OjUw UE0gLTAzMDAsIFJvZHJpZ28gU2lxdWVpcmEgd3JvdGU6Cj4gPiA+ID4gRm9yIGhpc3RvcmljYWwg cmVhc29uLCB0aGUgZnVuY3Rpb24gZHJtX3dhaXRfdmJsYW5rX2lvY3RsIGFsd2F5cyByZXR1cm4K PiA+ID4gPiAtRUlOVkFMIGlmIHNvbWV0aGluZyBnZXRzIHdyb25nLiBUaGlzIHNjZW5hcmlvIGxp bWl0cyB0aGUgZmxleGliaWxpdHkKPiA+ID4gPiBmb3IgdGhlIHVzZXJzcGFjZSBtYWtlIGRldGFp bGVkIHZlcmlmaWNhdGlvbiBvZiB0aGUgcHJvYmxlbSBhbmQgdGFrZQo+ID4gPiA+IHNvbWUgYWN0 aW9uLiBJbiBwYXJ0aWN1bGFyLCB0aGUgdmFsaWRhdGlvbiBvZiDigJxpZiAoIWRldi0+aXJxX2Vu YWJsZWQp4oCdCj4gPiA+ID4gaW4gdGhlIGRybV93YWl0X3ZibGFua19pb2N0bCBpcyByZXNwb25z aWJsZSBmb3IgY2hlY2tpbmcgaWYgdGhlIGRyaXZlcgo+ID4gPiA+IHN1cHBvcnQgdmJsYW5rIG9y IG5vdC4gSWYgdGhlIGRyaXZlciBkb2VzIG5vdCBzdXBwb3J0IFZCbGFuaywgdGhlCj4gPiA+ID4g ZnVuY3Rpb24gZHJtX3dhaXRfdmJsYW5rX2lvY3RsIHJldHVybnMgRUlOVkFMIHdoaWNoIGRvZXMg bm90IHJlcHJlc2VudAo+ID4gPiA+IHRoZSByZWFsIGlzc3VlOyB0aGlzIHBhdGNoIGNoYW5nZXMg dGhpcyBiZWhhdmlvciBieSByZXR1cm4gRU9QTk9UU1VQUC4KPiA+ID4gPiBBZGRpdGlvbmFsbHks IHNvbWUgb3BlcmF0aW9ucyBhcmUgdW5zdXBwb3J0ZWQgYnkgdGhpcyBmdW5jdGlvbiwgYW5kCj4g PiA+ID4gcmV0dXJucyBFSU5WQUw7IHRoaXMgcGF0Y2ggYWxzbyBjaGFuZ2VzIHRoZSByZXR1cm4g dmFsdWUgdG8gRU9QTk9UU1VQUAo+ID4gPiA+IGluIHRoaXMgY2FzZS4gTGFzdGx5LCB0aGUgZnVu Y3Rpb24gZHJtX3dhaXRfdmJsYW5rX2lvY3RsIGlzIGludm9rZWQgYnkKPiA+ID4gPiBsaWJkcm0s IHdoaWNoIGlzIHVzZWQgYnkgbWFueSBjb21wb3NpdG9yczsgYmVjYXVzZSBvZiB0aGlzLCBpdCBp cwo+ID4gPiA+IGltcG9ydGFudCB0byBjaGVjayBpZiB0aGlzIGNoYW5nZSBicmVha3MgYW55IGNv bXBvc2l0b3IuIEluIHRoaXMgc2Vuc2UsCj4gPiA+ID4gdGhlIGZvbGxvd2luZyBwcm9qZWN0cyB3 ZXJlIGV4YW1pbmVkOgo+ID4gPiA+Cj4gPiA+ID4gKiBEcm0taHdjb21wb3Nlcgo+ID4gPiA+ICog S3dpbgo+ID4gPiA+ICogU3dheQo+ID4gPiA+ICogV2xyb290cwo+ID4gPiA+ICogV2F5bGFuZC1j b3JlCj4gPiA+ID4gKiBXZXN0b24KPiA+ID4gPiAqIFhvcmcgKDY3IGRpZmZlcmVudCBkcml2ZXJz KQo+ID4gPiA+Cj4gPiA+ID4gRm9yIGVhY2ggcmVwb3NpdG9yeSB0aGUgdmVyaWZpY2F0aW9uIGhh cHBlbmVkIGluIHRocmVlIHN0ZXBzOgo+ID4gPiA+Cj4gPiA+ID4gKiBVcGRhdGUgdGhlIG1haW4g YnJhbmNoCj4gPiA+ID4gKiBMb29rIGZvciBhbnkgb2NjdXJyZW5jZSAiZHJtV2FpdFZCbGFuayIg d2l0aCB0aGUgY29tbWFuZDoKPiA+ID4gPiAgIGdpdCBncmVwIC1uICJkcm1XYWl0VkJsYW5rIgo+ ID4gPiA+ICogTG9vayBpbiB0aGUgZ2l0IGhpc3Rvcnkgb2YgdGhlIHByb2plY3Qgd2l0aCB0aGUg Y29tbWFuZDoKPiA+ID4gPiAgIGdpdCBsb2cgLVNkcm1XYWl0VkJsYW5rCj4gPiA+ID4KPiA+ID4g PiBGaW5hbGx5LCBub25lIG9mIHRoZSBhYm92ZSBwcm9qZWN0cyB2YWxpZGF0ZSB0aGUgdXNlIG9m IEVJTlZBTCB3aGljaAo+ID4gPiA+IG1ha2Ugc2FmZSwgYXQgbGVhc3QgZm9yIHRoZXNlIHByb2pl Y3RzLCB0byBjaGFuZ2UgdGhlIHJldHVybiB2YWx1ZXMuCj4gPiA+ID4KPiA+ID4gPiBDaGFuZ2Ug c2luY2UgVjM6Cj4gPiA+ID4gIC0gUmV0dXJuIEVJTlZBTCBmb3IgX0RSTV9WQkxBTktfU0lHTkFM IChEYW5pZWwpCj4gPiA+ID4KPiA+ID4gPiBDaGFuZ2Ugc2luY2UgVjI6Cj4gPiA+ID4gIERhbmll bCBWZXR0ZXIgYW5kIENocmlzIFdpbHNvbgo+ID4gPiA+ICAtIFJlcGxhY2UgRU5PVFRZIGJ5IEVP UE5PVFNVUFAKPiA+ID4gPiAgLSBSZXR1cm4gRUlOVkFMIGlmIHRoZSBwYXJhbWV0ZXJzIGFyZSB3 cm9uZwo+ID4gPiA+Cj4gPiA+Cj4gPiA+IFJldmlld2VkLWJ5OiBEYW5pZWwgVmV0dGVyIDxkYW5p ZWwudmV0dGVyQGZmd2xsLmNoPgo+ID4gPgo+ID4gPiBBcG9sb2dpZXMgZm9yIHRoZSBjb25mdXNp b24gb24gdGhlIGxhc3QgdGltZSBhcm91bmQuIGJ0dyBpZiBzb21lb25lIHRlbGxzCj4gPiA+IHlv dSAici1iIChvciBhLWIpIHdpdGggdGhlc2UgY2hhbmdlcyIsIHRoZW4ganVzdCBhcHBseSB0aGUg ci1iL2EtYiB0YWcKPiA+ID4gbmV4dCB0aW1lIGFyb3VuZC4gT3RoZXJ3aXNlIHBlb3BsZSB3aWxs IHJlLXJldmlldyB0aGUgc2FtZSB0aGluZyBvdmVyIGFuZAo+ID4gPiBvdmVyIGFnYWluLgo+ID4K PiA+IGJ0dyB3aGVuIHJlc2VuZGluZyBwYXRjaGVzIGl0J3MgZ29vZCBwcmFjdGljZSB0byBhZGQg YW55b25lIHdobyBjb21tZW50ZWQKPiA+IG9uIGl0IChvciB3aG8gY29tbWVudGVkIG9uIHRoZSBp Z3QgdGVzdCBmb3IgdGhlIHNhbWUgcGF0Y2ggYW5kIG90aGVyIHdheQo+ID4gcm91bmQpIG9udG8g dGhlIGV4cGxpY2l0IENjOiBsaXN0IG9mIHRoZSBwYXRjaC4gVGhhdCB3YXkgaXQncyBlYXNpZXIg Zm9yCj4gPiB0aGVtIHRvIGZvbGxvdyB0aGUgcGF0Y2ggZXZvbHV0aW9uIGFuZCBkbyBhIHF1aWNr IHItYiBvbmNlIHRoZXkncmUgaGFwcHkuCj4KPiBUaGFua3MgZm9yIHRoZXNlIHZhbHVhYmxlIHRp cHMuCj4gRG8geW91IHRoaW5rIHRoYXQgaXMgYSBnb29kIGlkZWEgdG8gcmVzZW5kIHRoaXMgcGF0 Y2ggQ0MncyBldmVyeWJvZHk/IE9yCj4gaXMgaXQgb2sgaWYgSSBqdXN0IGFwcGx5IGl0PwoKSG0g SSB0aG91Z2h0IEkgYW5zd2VyZWQgdGhhdCBvbiBpcmMgLi4uIGJ1dCBqdXN0IHRvZGF5IEkgcmVh bGl6ZWQgdGhhdAp3ZSBtaXNzZWQgMiBpb2N0bHMuIFRoZXJlJ3MgYWxzbyBkcm1fY3J0Y19nZXRf c2VxdWVuY2VfaW9jdGwgYW5kCmRybV9jcnRjX3F1ZXVlX3NlcXVlbmNlX2lvY3RsIHdoaWNoIGhh dmUgdGhlIHNhbWUgZGV2LT5pcnFfZW5hYmxlZApjaGVjayBhbmQgSSB0aGluayBzaG91bGQgYmUg dHJlYXRlZCB0aGUgc2FtZS4KCkNhbiB5b3UgcGxzIHJlc2VuZCB3aXRoIHRob3NlIGFkZHJlc3Nl ZCB0b28/IFRoZW4geW91IGNhbiBhbHNvIHJlc2VuZAp3aXRoIHRoZSBjYydzIGFsbCBhZGRlZC4K LURhbmllbAoKPgo+ID4gSWYgeW91IGRvbid0IGRvIHRoYXQgdGhlbiBtdWNoIGJpZ2dlciBjaGFu Y2VzIHlvdXIgcGF0Y2ggZ2V0cyBpZ25vcmVkLgo+ID4gLURhbmllbAo+ID4gPgo+ID4gPiA+IFNp Z25lZC1vZmYtYnk6IFJvZHJpZ28gU2lxdWVpcmEgPHJvZHJpZ29zaXF1ZWlyYW1lbG9AZ21haWwu Y29tPgo+ID4gPiA+IC0tLQo+ID4gPiA+ICBkcml2ZXJzL2dwdS9kcm0vZHJtX3ZibGFuay5jIHwg MiArLQo+ID4gPiA+ICAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRpb24o LSkKPiA+ID4gPgo+ID4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vZHJtX3ZibGFu ay5jIGIvZHJpdmVycy9ncHUvZHJtL2RybV92YmxhbmsuYwo+ID4gPiA+IGluZGV4IDYwM2FiMTA1 MTI1ZC4uYmVkMjMzMzYxNjE0IDEwMDY0NAo+ID4gPiA+IC0tLSBhL2RyaXZlcnMvZ3B1L2RybS9k cm1fdmJsYW5rLmMKPiA+ID4gPiArKysgYi9kcml2ZXJzL2dwdS9kcm0vZHJtX3ZibGFuay5jCj4g PiA+ID4gQEAgLTE1ODIsNyArMTU4Miw3IEBAIGludCBkcm1fd2FpdF92YmxhbmtfaW9jdGwoc3Ry dWN0IGRybV9kZXZpY2UgKmRldiwgdm9pZCAqZGF0YSwKPiA+ID4gPiAgIHVuc2lnbmVkIGludCBm bGFncywgcGlwZSwgaGlnaF9waXBlOwo+ID4gPiA+Cj4gPiA+ID4gICBpZiAoIWRldi0+aXJxX2Vu YWJsZWQpCj4gPiA+ID4gLSAgICAgICAgIHJldHVybiAtRUlOVkFMOwo+ID4gPiA+ICsgICAgICAg ICByZXR1cm4gLUVPUE5PVFNVUFA7Cj4gPiA+ID4KPiA+ID4gPiAgIGlmICh2Ymx3YWl0LT5yZXF1 ZXN0LnR5cGUgJiBfRFJNX1ZCTEFOS19TSUdOQUwpCj4gPiA+ID4gICAgICAgICAgIHJldHVybiAt RUlOVkFMOwo+ID4gPiA+IC0tCj4gPiA+ID4gMi4yMS4wCj4gPiA+Cj4gPiA+IC0tCj4gPiA+IERh bmllbCBWZXR0ZXIKPiA+ID4gU29mdHdhcmUgRW5naW5lZXIsIEludGVsIENvcnBvcmF0aW9uCj4g PiA+IGh0dHA6Ly9ibG9nLmZmd2xsLmNoCj4gPgo+ID4gLS0KPiA+IERhbmllbCBWZXR0ZXIKPiA+ IFNvZnR3YXJlIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbgo+ID4gaHR0cDovL2Jsb2cuZmZ3 bGwuY2gKPgo+IC0tCj4gUm9kcmlnbyBTaXF1ZWlyYQo+IGh0dHBzOi8vc2lxdWVpcmEudGVjaAo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gSW50ZWwt Z2Z4IG1haWxpbmcgbGlzdAo+IEludGVsLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKPiBodHRw czovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludGVsLWdmeAoKCgot LSAKRGFuaWVsIFZldHRlcgpTb2Z0d2FyZSBFbmdpbmVlciwgSW50ZWwgQ29ycG9yYXRpb24KKzQx ICgwKSA3OSAzNjUgNTcgNDggLSBodHRwOi8vYmxvZy5mZndsbC5jaApfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpJbnRlbC1nZnggbWFpbGluZyBsaXN0Cklu dGVsLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5v cmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZng=