From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D0093976AD for ; Sat, 30 May 2026 11:35:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780140937; cv=none; b=LU1Wfqc17F0AsgIyHnjUDL9du8wCxkVoNgkeFeqFz+maNUVc7urLduwqPfyzJcOWwW4qbV4oZMoOx1iRxX+2mbFjyXP1fLj+gqboplZtOd4cjpX0q7rs7+etUXNTd9G8couTyDDruUbtvOP9eUSLiB+FIBuE5rVrA++JO8XWWRY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780140937; c=relaxed/simple; bh=ytS7JyxlwcLHZAEPMzHJnVt194rCC1t3+gtEKLOaRMQ=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=mEVR/tioaFOJAELxsVVeRMsVVnIvI08XvvcV4U1P+DAxrlPWVEDS/d9z0SyEro9SIN9fIzzimImAcJgUZ+OiKewO84boOHZUIppoD112fIt1c/R7VxmAnu412vzl92DmWBJTLuOpUqusheAIG8bAa31+Z7Orj/L3M2kp1QkX6Ls= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TSWS4knb; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TSWS4knb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D3611F00893; Sat, 30 May 2026 11:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780140935; bh=Yc77usDQiigwdpgTMTiMuOA07l23X/cNQcNayeUOeQo=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=TSWS4knbk7cSeJgo8H+6wyxrc2ivB7BhmdvAMtz2WDM8wLsnbhmKQQcg4bu/E4UJA rGbg80Nwk3QGAlCfUDgXUq9A2EJflkbesc0Lf1TMlWDVc3QpNQeuAxd3vtC27nWpnq ADfgt9dbpulnjY58BfcHxk4w2W3V2HNQQG0sB+mkO6QBu8G9rbERADWrtyD1/LYssQ Rt8gk+hkJGoLScYGC3vD3dP+FLlzBNmTzOVfOlAknA8aUej1b29Dj9evKYE+0mim4n o6VSLHIvpAdG+0NHfbV6h8jZ7gTsmfFHuWDL93cNnk4gO6xrPjhQDoXrr80asD76sF 8P6sBT6VpqZmw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v6 8/8] gpu: drm: meson: Fix DMA max segment size for DMABUF imports Reply-To: sashiko-reviews@lists.linux.dev To: "Anand Moon" Cc: neil.armstrong@linaro.org, linux-media@vger.kernel.org, linux-amlogic@lists.infradead.org In-Reply-To: <20260530094326.11892-9-linux.amoon@gmail.com> References: <20260530094326.11892-9-linux.amoon@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 30 May 2026 11:35:34 +0000 Message-Id: <20260530113535.1D3611F00893@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: Pre-existing issues: - [High] Dereferencing a NULL `priv` pointer on the `devm_kzalloc` error pa= th. - [High] Missing `drm_bridge_remove()` on encoder probe error paths leaves = a dangling bridge in the global DRM list, leading to a Use-After-Free. - [High] Prematurely dropping the canvas device reference without a device = link causes a Use-After-Free if the canvas driver is unbound. -- commit a3547c6366bfd30d17cb91e687b8ed0c53c24146 Author: Anand Moon gpu: drm: meson: Fix DMA max segment size for DMABUF imports When using hardware-accelerated video decoding via v4l2m2m-copy with mpv or similar players, the video decoder driver (meson_vdec) exports contiguous memory allocations as DMABUFs. When these buffers are subsequently imported by the display controller driver (meson-drm) for rendering via the GPU or compositor, the DMA API throws constraint validation warnings. > diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/me= son_drv.c > index 49ff9f1f16d32..8570add8b8315 100644 > --- a/drivers/gpu/drm/meson/meson_drv.c > +++ b/drivers/gpu/drm/meson/meson_drv.c > @@ -247,6 +247,8 @@ static int meson_drv_bind_master(struct device *dev, = bool has_components) > goto free_drm; > } [Severity: High] This is a pre-existing issue, but does the error path in meson_drv_bind_master() cause a NULL pointer dereference? If devm_kzalloc() fails earlier in this function: drivers/gpu/drm/meson/meson_drv.c:meson_drv_bind_master() { ... priv =3D devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); if (!priv) { ret =3D -ENOMEM; goto free_drm; } ... } It jumps to the free_drm label with priv set to NULL. The cleanup path sequentially calls meson_encoder_dsi_remove(priv), meson_encoder_hdmi_remove(priv), and meson_encoder_cvbs_remove(priv). Can this cause a kernel panic when these functions unconditionally derefere= nce priv, such as here in meson_encoder_dsi_remove()? drivers/gpu/drm/meson/meson_encoder_dsi.c:meson_encoder_dsi_remove() { ... if (priv->encoders[MESON_ENC_DSI]) { ... } [Severity: High] This is a pre-existing issue, but does meson_canvas_get() leave the system vulnerable to a use-after-free? Looking at meson_canvas_get() in drivers/soc/amlogic/meson-canvas.c, the device reference is dropped after extracting the canvas pointer: drivers/soc/amlogic/meson-canvas.c:meson_canvas_get() { ... canvas =3D dev_get_drvdata(&canvas_pdev->dev); put_device(&canvas_pdev->dev); if (!canvas) ... } Since no device_link_add() is used to track the dependency between the DRM driver and the canvas driver, the driver core permits unbinding the amlogic-canvas driver. Would doing so free its devm-managed memory and leave meson-drm with a dangling pointer that causes a use-after-free when dereferenced later, such as when locking canvas->lock in meson_canvas_alloc()? [Severity: High] This is a pre-existing issue, but does meson_encoder_cvbs_probe() leak a bridge reference on error paths? In drivers/gpu/drm/meson/meson_encoder_cvbs.c, the bridge is added globally: drivers/gpu/drm/meson/meson_encoder_cvbs.c:meson_encoder_cvbs_probe() { ... drm_bridge_add(&meson_encoder_cvbs->bridge); meson_encoder_cvbs->priv =3D priv; /* Encoder */ ret =3D drm_simple_encoder_init(priv->drm, &meson_encoder_cvbs->encoder, DRM_MODE_ENCODER_TVDAC); if (ret) return dev_err_probe(priv->dev, ret, "Failed to init CVBS encoder\n"); ... } If a subsequent initialization step fails, the function returns an error without calling drm_bridge_remove(). The master cleanup function fails to remove it because priv->encoders[MESON_ENC_CVBS] is only populated upon successful probe completion. During devres teardown, the reference count drops to 1, but the bridge is not freed. Can this leave the bridge accessible in the global bridge_list with dangling pointers to the freed priv structure, leading to memory corruption if accessed by other DRM subsystems? > =20 > + dma_set_max_seg_size(dev, UINT_MAX); > + > ret =3D meson_canvas_alloc(priv->canvas, &priv->canvas_id_osd1); > if (ret) > goto free_drm; --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260530094326.1189= 2-1-linux.amoon@gmail.com?part=3D8 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0333FCD6E4A for ; Sat, 30 May 2026 11:35:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: References:In-Reply-To:Cc:To:Subject:From:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3Rah/MJm6OJ/G4qHC+Vcb9e43uZFMMf8mVIM/7GYaNw=; b=cDByKbk2HBI8cu NATHdslv7DGwWPffoeChDKz3R3v80XKkj/hBaOc+9INFbVTXiIn146Zbr/Bk9GIT7U/c0axvLqptW Gb/Fbi6mDAe3SasEbfJ7QxKAwrEWhibpfc6F0XPjt6puIb/toFy/vaX5R08cIApOuS6MkEQ8BzHsn EPu8S98TwiASumEuIPHYjl1swBmHA0KvdIepGVw2QcWNaxhH2Qv5FqBP1UmNTyl06uukVMTWDHXH2 RIdLJDIrLj+ma5s7HG/hAM3veSYMbv6nOLHiTm3zpqv/OydUs6LQk9jDNWjHdjNFtBT8crRpLssv1 qTGlzRqPWqYpy9q9uVuA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wTHyc-00000008gex-0tdT; Sat, 30 May 2026 11:35:38 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wTHya-00000008geZ-3xFi for linux-amlogic@lists.infradead.org; Sat, 30 May 2026 11:35:37 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 1062C600AB; Sat, 30 May 2026 11:35:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D3611F00893; Sat, 30 May 2026 11:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780140935; bh=Yc77usDQiigwdpgTMTiMuOA07l23X/cNQcNayeUOeQo=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=TSWS4knbk7cSeJgo8H+6wyxrc2ivB7BhmdvAMtz2WDM8wLsnbhmKQQcg4bu/E4UJA rGbg80Nwk3QGAlCfUDgXUq9A2EJflkbesc0Lf1TMlWDVc3QpNQeuAxd3vtC27nWpnq ADfgt9dbpulnjY58BfcHxk4w2W3V2HNQQG0sB+mkO6QBu8G9rbERADWrtyD1/LYssQ Rt8gk+hkJGoLScYGC3vD3dP+FLlzBNmTzOVfOlAknA8aUej1b29Dj9evKYE+0mim4n o6VSLHIvpAdG+0NHfbV6h8jZ7gTsmfFHuWDL93cNnk4gO6xrPjhQDoXrr80asD76sF 8P6sBT6VpqZmw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v6 8/8] gpu: drm: meson: Fix DMA max segment size for DMABUF imports To: "Anand Moon" Cc: neil.armstrong@linaro.org, linux-media@vger.kernel.org, linux-amlogic@lists.infradead.org In-Reply-To: <20260530094326.11892-9-linux.amoon@gmail.com> References: <20260530094326.11892-9-linux.amoon@gmail.com> Date: Sat, 30 May 2026 11:35:34 +0000 Message-Id: <20260530113535.1D3611F00893@smtp.kernel.org> X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MyBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpQcmUtZXhpc3RpbmcgaXNzdWVzOgot IFtIaWdoXSBEZXJlZmVyZW5jaW5nIGEgTlVMTCBgcHJpdmAgcG9pbnRlciBvbiB0aGUgYGRldm1f a3phbGxvY2AgZXJyb3IgcGF0aC4KLSBbSGlnaF0gTWlzc2luZyBgZHJtX2JyaWRnZV9yZW1vdmUo KWAgb24gZW5jb2RlciBwcm9iZSBlcnJvciBwYXRocyBsZWF2ZXMgYSBkYW5nbGluZyBicmlkZ2Ug aW4gdGhlIGdsb2JhbCBEUk0gbGlzdCwgbGVhZGluZyB0byBhIFVzZS1BZnRlci1GcmVlLgotIFtI aWdoXSBQcmVtYXR1cmVseSBkcm9wcGluZyB0aGUgY2FudmFzIGRldmljZSByZWZlcmVuY2Ugd2l0 aG91dCBhIGRldmljZSBsaW5rIGNhdXNlcyBhIFVzZS1BZnRlci1GcmVlIGlmIHRoZSBjYW52YXMg ZHJpdmVyIGlzIHVuYm91bmQuCi0tCgpjb21taXQgYTM1NDdjNjM2NmJmZDMwZDE3Y2I5MWU2ODdi OGVkMGM1M2MyNDE0NgpBdXRob3I6IEFuYW5kIE1vb24gPGxpbnV4LmFtb29uQGdtYWlsLmNvbT4K CmdwdTogZHJtOiBtZXNvbjogRml4IERNQSBtYXggc2VnbWVudCBzaXplIGZvciBETUFCVUYgaW1w b3J0cwoKV2hlbiB1c2luZyBoYXJkd2FyZS1hY2NlbGVyYXRlZCB2aWRlbyBkZWNvZGluZyB2aWEg djRsMm0ybS1jb3B5IHdpdGggbXB2IG9yCnNpbWlsYXIgcGxheWVycywgdGhlIHZpZGVvIGRlY29k ZXIgZHJpdmVyIChtZXNvbl92ZGVjKSBleHBvcnRzIGNvbnRpZ3VvdXMKbWVtb3J5IGFsbG9jYXRp b25zIGFzIERNQUJVRnMuIFdoZW4gdGhlc2UgYnVmZmVycyBhcmUgc3Vic2VxdWVudGx5IGltcG9y dGVkCmJ5IHRoZSBkaXNwbGF5IGNvbnRyb2xsZXIgZHJpdmVyIChtZXNvbi1kcm0pIGZvciByZW5k ZXJpbmcgdmlhIHRoZSBHUFUgb3IKY29tcG9zaXRvciwgdGhlIERNQSBBUEkgdGhyb3dzIGNvbnN0 cmFpbnQgdmFsaWRhdGlvbiB3YXJuaW5ncy4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1L2Ry bS9tZXNvbi9tZXNvbl9kcnYuYyBiL2RyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9kcnYuYwo+ IGluZGV4IDQ5ZmY5ZjFmMTZkMzIuLjg1NzBhZGQ4YjgzMTUgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVy cy9ncHUvZHJtL21lc29uL21lc29uX2Rydi5jCj4gKysrIGIvZHJpdmVycy9ncHUvZHJtL21lc29u L21lc29uX2Rydi5jCj4gQEAgLTI0Nyw2ICsyNDcsOCBAQCBzdGF0aWMgaW50IG1lc29uX2Rydl9i aW5kX21hc3RlcihzdHJ1Y3QgZGV2aWNlICpkZXYsIGJvb2wgaGFzX2NvbXBvbmVudHMpCj4gIAkJ Z290byBmcmVlX2RybTsKPiAgCX0KCltTZXZlcml0eTogSGlnaF0KVGhpcyBpcyBhIHByZS1leGlz dGluZyBpc3N1ZSwgYnV0IGRvZXMgdGhlIGVycm9yIHBhdGggaW4KbWVzb25fZHJ2X2JpbmRfbWFz dGVyKCkgY2F1c2UgYSBOVUxMIHBvaW50ZXIgZGVyZWZlcmVuY2U/CgpJZiBkZXZtX2t6YWxsb2Mo KSBmYWlscyBlYXJsaWVyIGluIHRoaXMgZnVuY3Rpb246Cgpkcml2ZXJzL2dwdS9kcm0vbWVzb24v bWVzb25fZHJ2LmM6bWVzb25fZHJ2X2JpbmRfbWFzdGVyKCkgewogICAgLi4uCglwcml2ID0gZGV2 bV9remFsbG9jKGRldiwgc2l6ZW9mKCpwcml2KSwgR0ZQX0tFUk5FTCk7CglpZiAoIXByaXYpIHsK CQlyZXQgPSAtRU5PTUVNOwoJCWdvdG8gZnJlZV9kcm07Cgl9CiAgICAuLi4KfQoKSXQganVtcHMg dG8gdGhlIGZyZWVfZHJtIGxhYmVsIHdpdGggcHJpdiBzZXQgdG8gTlVMTC4gVGhlIGNsZWFudXAg cGF0aApzZXF1ZW50aWFsbHkgY2FsbHMgbWVzb25fZW5jb2Rlcl9kc2lfcmVtb3ZlKHByaXYpLApt ZXNvbl9lbmNvZGVyX2hkbWlfcmVtb3ZlKHByaXYpLCBhbmQgbWVzb25fZW5jb2Rlcl9jdmJzX3Jl bW92ZShwcml2KS4KCkNhbiB0aGlzIGNhdXNlIGEga2VybmVsIHBhbmljIHdoZW4gdGhlc2UgZnVu Y3Rpb25zIHVuY29uZGl0aW9uYWxseSBkZXJlZmVyZW5jZQpwcml2LCBzdWNoIGFzIGhlcmUgaW4g bWVzb25fZW5jb2Rlcl9kc2lfcmVtb3ZlKCk/Cgpkcml2ZXJzL2dwdS9kcm0vbWVzb24vbWVzb25f ZW5jb2Rlcl9kc2kuYzptZXNvbl9lbmNvZGVyX2RzaV9yZW1vdmUoKSB7CiAgICAuLi4KCWlmIChw cml2LT5lbmNvZGVyc1tNRVNPTl9FTkNfRFNJXSkgewogICAgLi4uCn0KCltTZXZlcml0eTogSGln aF0KVGhpcyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGRvZXMgbWVzb25fY2FudmFzX2dl dCgpIGxlYXZlIHRoZSBzeXN0ZW0KdnVsbmVyYWJsZSB0byBhIHVzZS1hZnRlci1mcmVlPwoKTG9v a2luZyBhdCBtZXNvbl9jYW52YXNfZ2V0KCkgaW4gZHJpdmVycy9zb2MvYW1sb2dpYy9tZXNvbi1j YW52YXMuYywgdGhlCmRldmljZSByZWZlcmVuY2UgaXMgZHJvcHBlZCBhZnRlciBleHRyYWN0aW5n IHRoZSBjYW52YXMgcG9pbnRlcjoKCmRyaXZlcnMvc29jL2FtbG9naWMvbWVzb24tY2FudmFzLmM6 bWVzb25fY2FudmFzX2dldCgpIHsKICAgIC4uLgoJY2FudmFzID0gZGV2X2dldF9kcnZkYXRhKCZj YW52YXNfcGRldi0+ZGV2KTsKCXB1dF9kZXZpY2UoJmNhbnZhc19wZGV2LT5kZXYpOwoJaWYgKCFj YW52YXMpCiAgICAuLi4KfQoKU2luY2Ugbm8gZGV2aWNlX2xpbmtfYWRkKCkgaXMgdXNlZCB0byB0 cmFjayB0aGUgZGVwZW5kZW5jeSBiZXR3ZWVuIHRoZSBEUk0KZHJpdmVyIGFuZCB0aGUgY2FudmFz IGRyaXZlciwgdGhlIGRyaXZlciBjb3JlIHBlcm1pdHMgdW5iaW5kaW5nIHRoZQphbWxvZ2ljLWNh bnZhcyBkcml2ZXIuCgpXb3VsZCBkb2luZyBzbyBmcmVlIGl0cyBkZXZtLW1hbmFnZWQgbWVtb3J5 IGFuZCBsZWF2ZSBtZXNvbi1kcm0gd2l0aCBhCmRhbmdsaW5nIHBvaW50ZXIgdGhhdCBjYXVzZXMg YSB1c2UtYWZ0ZXItZnJlZSB3aGVuIGRlcmVmZXJlbmNlZCBsYXRlciwgc3VjaAphcyB3aGVuIGxv Y2tpbmcgY2FudmFzLT5sb2NrIGluIG1lc29uX2NhbnZhc19hbGxvYygpPwoKW1NldmVyaXR5OiBI aWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5nIGlzc3VlLCBidXQgZG9lcyBtZXNvbl9lbmNvZGVy X2N2YnNfcHJvYmUoKSBsZWFrIGEKYnJpZGdlIHJlZmVyZW5jZSBvbiBlcnJvciBwYXRocz8KCklu IGRyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9lbmNvZGVyX2N2YnMuYywgdGhlIGJyaWRnZSBp cyBhZGRlZCBnbG9iYWxseToKCmRyaXZlcnMvZ3B1L2RybS9tZXNvbi9tZXNvbl9lbmNvZGVyX2N2 YnMuYzptZXNvbl9lbmNvZGVyX2N2YnNfcHJvYmUoKSB7CiAgICAuLi4KCWRybV9icmlkZ2VfYWRk KCZtZXNvbl9lbmNvZGVyX2N2YnMtPmJyaWRnZSk7CgoJbWVzb25fZW5jb2Rlcl9jdmJzLT5wcml2 ID0gcHJpdjsKCgkvKiBFbmNvZGVyICovCglyZXQgPSBkcm1fc2ltcGxlX2VuY29kZXJfaW5pdChw cml2LT5kcm0sICZtZXNvbl9lbmNvZGVyX2N2YnMtPmVuY29kZXIsCgkJCQkgICAgICBEUk1fTU9E RV9FTkNPREVSX1RWREFDKTsKCWlmIChyZXQpCgkJcmV0dXJuIGRldl9lcnJfcHJvYmUocHJpdi0+ ZGV2LCByZXQsCgkJCQkgICAgICJGYWlsZWQgdG8gaW5pdCBDVkJTIGVuY29kZXJcbiIpOwogICAg Li4uCn0KCklmIGEgc3Vic2VxdWVudCBpbml0aWFsaXphdGlvbiBzdGVwIGZhaWxzLCB0aGUgZnVu Y3Rpb24gcmV0dXJucyBhbiBlcnJvcgp3aXRob3V0IGNhbGxpbmcgZHJtX2JyaWRnZV9yZW1vdmUo KS4gVGhlIG1hc3RlciBjbGVhbnVwIGZ1bmN0aW9uIGZhaWxzIHRvCnJlbW92ZSBpdCBiZWNhdXNl IHByaXYtPmVuY29kZXJzW01FU09OX0VOQ19DVkJTXSBpcyBvbmx5IHBvcHVsYXRlZCB1cG9uCnN1 Y2Nlc3NmdWwgcHJvYmUgY29tcGxldGlvbi4KCkR1cmluZyBkZXZyZXMgdGVhcmRvd24sIHRoZSBy ZWZlcmVuY2UgY291bnQgZHJvcHMgdG8gMSwgYnV0IHRoZSBicmlkZ2UgaXMKbm90IGZyZWVkLiBD YW4gdGhpcyBsZWF2ZSB0aGUgYnJpZGdlIGFjY2Vzc2libGUgaW4gdGhlIGdsb2JhbCBicmlkZ2Vf bGlzdAp3aXRoIGRhbmdsaW5nIHBvaW50ZXJzIHRvIHRoZSBmcmVlZCBwcml2IHN0cnVjdHVyZSwg bGVhZGluZyB0byBtZW1vcnkKY29ycnVwdGlvbiBpZiBhY2Nlc3NlZCBieSBvdGhlciBEUk0gc3Vi c3lzdGVtcz8KCj4gIAo+ICsJZG1hX3NldF9tYXhfc2VnX3NpemUoZGV2LCBVSU5UX01BWCk7Cj4g Kwo+ICAJcmV0ID0gbWVzb25fY2FudmFzX2FsbG9jKHByaXYtPmNhbnZhcywgJnByaXYtPmNhbnZh c19pZF9vc2QxKTsKPiAgCWlmIChyZXQpCj4gIAkJZ290byBmcmVlX2RybTsKCi0tIApTYXNoaWtv IEFJIHJldmlldyDCtyBodHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA1MzAwOTQz MjYuMTE4OTItMS1saW51eC5hbW9vbkBnbWFpbC5jb20/cGFydD04CgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hbWxvZ2ljIG1haWxpbmcgbGlz dApsaW51eC1hbWxvZ2ljQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVh ZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hbWxvZ2ljCg==