From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794228649; b=XQkWN+AlUTgwZOSExttGbMi/fYpY32+ab6j7uEts1I22sLXFu3ahxxNqXVAH1vp2nqNc Tm3lzxIJZrYV+3baFHPJNjitwt/OeIfXw1XoD4u+6aF6rcuAMeQGyI+nKwhqdfkJFIb5H ugYvdiEJANv0+gWoE6ThkaiZdXZVLSQhgetel7u/KanFAkZqY2N/OXJ2P8k/1nY9OOfZz ZwIDR/7A4SMO6JwIG5Vku89M9/S88n0XRIDAcP6630J8q8x3UnQRZKHOXPVPMoOQZUH7D OnrGBjo6qeLVaH8H/pdYQcPXOeLLuAu8fGTUtGGMlNw9Q+82PjixDjlmYikFGWPhawQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794228649; h=Received:DKIM-Signature:Subject:From:To:Cc:Date:Message-ID: In-Reply-To:References:X-sashiko-severity:Content-Type: Content-Transfer-Encoding:MIME-Version; bh=JjNSwO4mZ69wgWNuljj9jgcvdRQfwcVoIjX8RvCsKvM=; b=yj9JA2eGqcKrllWdXRwsET4KApHoRgEjakvBNDPNZXt+D3bREB844XnAJzG19TxjDWnp u3LODZVjyavZugVECIyW355PXQubOFSUotfcqXdkbtk90uoM+8GzNEDxAoR2IWduNFzks R1IQNH35B6JfJgFx2+MJWweBip9kdXnr/5BriT1QNxY09pjPDDaC21XvNTyx+f+DfJmKg td1eiL9SnY4Kt+i35jJD/tP4RgFxYNbosCFLjNBsK835RbLH+M1BnRQTcCjWWixA9QZFv mGb9ecj8oPTDJaLcmX7dY8ccpMQr/ZJq9owfCcrTYxZ/dAnuTPRCwmTJB1Zc87can0g== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=AMcdWkPh; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 753EC606A322; Mon, 9 Nov 2026 12:50:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=AMcdWkPh Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BF081F0089F; Mon, 9 Nov 2026 12:50:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794228649; bh=JjNSwO4mZ69wgWNuljj9jgcvdRQfwcVoIjX8RvCsKvM=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=AMcdWkPhAWKw4Kty4An/ZtOYneJtvpJDr03C4k9f4tW0Mo6sgerdBVpzfABUh/Izz RkYVqnfH+aQq6TxHIcOTPO9nHVxllQqqI5DJZKjTmZy/zYILGN0a0xlyY4h0Dr8/aa 5EmkN/gp8IT7gS80cbk7N/hnq86JwIN+KeT5TLtD/1Pp8NgR8gNeuWqLWiOxlArV98 lf9ViQfLIxjFbx23pEDq01GJDwvSkGChDztuhHnw56pwxwZMe40GVH5SoxrMhAFFpy ZdM2Q1b4RIxcK6EUM6ZOYnd80/6fgCvOEJUEB5mFrxshCiSW9wYfunJjU88fCRa7cI Cw5wlVwLKqaug== Subject: Re: [PATCH net] net: spacemit: Hold RTNL lock in emac_resume() and emac_suspend() From: netdev-bot+sashiko@kernel.org To: alitariq45892@gmail.com Cc: netdev@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, dlan@kernel.org, troy.mitchell@linux.spacemit.com, wangruikang@iscas.ac.cn, amadeus@jmu.edu.cn, s-vadapalli@ti.com, tmshlvck@gmail.com, meatuni001@gmail.com, vadim.fedorenko@linux.dev, maxime.chevallier@bootlin.com, linux-riscv@lists.infradead.org, spacemit@lists.linux.dev, linux-kernel@vger.kernel.org Date: Mon, 09 Nov 2026 12:50:47 +0000 Message-ID: <179422864754.994134.12281861683384047552@kernel.org> In-Reply-To: <20261105123441.2524171-1-alitariq45892@gmail.com> References: <20261105123441.2524171-1-alitariq45892@gmail.com> X-sashiko-severity: Medium Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider. Critical: 0 · High: 0 (2) · Medium: 2 · Low: 0 If you believe none of the issues are legitimate, please reply to each issue of Medium severity or higher and explain why the AI is wrong. If any of them are legitimate and you plan to respin, please let patchwork know by including "pw-bot: cr" as a separate line at the end of your reply (one such reply per series is enough). - [Medium] Possible ABBA deadlock between rtnl_mutex and the TX-timeout work, added to the suspend path. - [Medium] The new RTNL section does not cover the netif_running() check that decides whether to call emac_stop()/emac_open(). Pre-existing issues: - [High] This problem wasn't introduced by this patch, but it is High severity and involves the same work/RTNL pair. - [High] This problem wasn't introduced by this patch, but it is High severity and sits in the function the patch modifies. -- net: spacemit: Hold RTNL lock in emac_resume() and emac_suspend() This patch takes rtnl_lock() around the emac_open() call in emac_resume() and around the emac_stop() call in emac_suspend(). The aim is to silence a lockdep "suspicious RCU usage" warning from phy_disconnect(), which reads a pointer with rtnl_dereference(). > diff --git a/drivers/net/ethernet/spacemit/k1_emac.c b/drivers/net/ethernet/spacemit/k1_emac.c > index 71a80838bffd0..aca25a9e1e9ef 100644 > --- a/drivers/net/ethernet/spacemit/k1_emac.c > +++ b/drivers/net/ethernet/spacemit/k1_emac.c > @@ -2033,7 +2033,10 @@ static int emac_resume(struct device *dev) > if (!netif_running(ndev)) > return 0; > > + rtnl_lock(); > ret = emac_open(ndev); > + rtnl_unlock(); > + > if (ret) { > clk_disable_unprepare(priv->bus_clk); > return ret; [Severity: High] This is a pre-existing issue, not one introduced by this patch. It sits in the function being changed, though. What state is the device left in when emac_open() fails here? By this point the unwind in emac_open() has freed the TX/RX rings. One of two things has also happened: - emac_up() failed, and its error path called phy_disconnect() and pm_runtime_put_sync(). - emac_phy_connect() failed, and ndev->phydev is still NULL from the previous suspend. The IRQ is not requested and NAPI is disabled. emac_resume() then gates bus_clk and returns, but __LINK_STATE_START and IFF_UP are still set. The next "ip link set down", unregister, or emac_suspend() (which sees netif_running() as true) would then run: emac_stop() emac_down() phy_disconnect(ndev->phydev) <- phydev is NULL phy_is_started(phydev) <- dereferences phydev->state Can this oops? Past that point, emac_down() would: - write MAC registers with the bus clock gated - call free_irq() on an IRQ that is not requested - call napi_disable() on a NAPI that is already disabled - underflow the runtime PM usage count Also, emac_clean_rx_desc_ring() would index the NULL rx_desc_buf, and emac_suspend() would call clk_disable_unprepare(priv->bus_clk) a second time. Separately, emac_alloc_tx_resources() and emac_alloc_rx_resources() kfree() the buffer array when dma_alloc_coherent() fails, but they do not set the pointer to NULL: if (!tx_ring->desc_addr) { kfree(tx_ring->tx_desc_buf); return -ENOMEM; } Could a later teardown free tx_desc_buf (or rx_desc_buf) a second time through that stale pointer? > @@ -2056,7 +2059,9 @@ static int emac_suspend(struct device *dev) > return 0; > } > > + rtnl_lock(); > emac_stop(ndev); > + rtnl_unlock(); [Severity: Medium] emac_suspend() checks netif_running() to decide whether to call emac_stop(). That check runs before rtnl_lock() and is not repeated under the lock: if (!ndev || !netif_running(ndev)) { clk_disable_unprepare(priv->bus_clk); return 0; } rtnl_lock(); emac_stop(ndev); Can another RTNL holder close the device in between? Here is one example. The netdev is moved into a netns, and that netns is torn down as system sleep starts. cleanup_net runs on netns_wq, which is not freezable. It holds RTNL and calls dev_close(), which calls emac_stop(). Meanwhile emac_suspend() has already seen netif_running() as true. It blocks in rtnl_lock(), then runs emac_stop() a second time. There, emac_down() calls phy_disconnect(ndev->phydev) with phydev already NULL, and phy_is_started() dereferences it. emac_resume() has the mirror case. It also tests netif_running() before rtnl_lock(), so it could call emac_open() on a device that was just closed. That would leak the rings, the IRQ and the PHY attach. Would it make sense to take rtnl_lock() before the netif_running() test, with netif_device_detach() / netif_device_attach() inside the same locked section? [Severity: Medium] Does holding RTNL here invert the lock order with tx_timeout_task? emac_stop()->emac_down() does: cancel_work_sync(&priv->tx_timeout_task); and the work handler takes RTNL first: emac_tx_timeout_task() { ... rtnl_lock(); ... } emac_tx_timeout() queues the work with schedule_work(). That uses the system workqueue, which is not freezable, so the work can run during system suspend: CPU1 (worker) CPU2 (suspend) emac_tx_timeout_task() emac_suspend() rtnl_lock() rtnl_lock() <- blocks emac_stop() emac_down() cancel_work_sync() <- waits for CPU1 cancel_work_sync() goes through __flush_work()->start_flush_work(). That finds the executing worker with find_worker_executing_work() and waits on a barrier queued behind it. Can this hang suspend? Lockdep may also report a circular dependency between rtnl_mutex and the work's lockdep_map, which would swap one splat for another. The ndo_stop path (dev_close() under RTNL, then emac_stop()) already has this pattern. This patch adds it to the system sleep path too. Could the synchronous cancel be kept out of any RTNL-held section? Options include cancelling the work before taking RTNL, using rtnl_trylock() and requeueing in the work, or a disable_work() based scheme. [Severity: High] This isn't a bug introduced by this patch, but it involves the same work and RTNL pair. Can emac_tx_timeout_task() wait on itself? emac_tx_timeout_task() <- running as priv->tx_timeout_task rtnl_lock() dev_close(ndev) __dev_close_many() emac_stop() <- ndo_stop emac_down() cancel_work_sync(&priv->tx_timeout_task) At this point the work is executing, not queued. start_flush_work() finds the calling worker itself through find_worker_executing_work(). It then inserts a barrier that can only run after the current work returns, so wait_for_completion() in __flush_work() never returns. Would every TX timeout recovery leave the worker stuck while holding rtnl_mutex? That would block every RTNL user. With this patch, the next emac_suspend() would also block forever in its new rtnl_lock(). -- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261105123441.2524171-1-alitariq45892%40gmail.com From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C255606A322 for ; Mon, 9 Nov 2026 12:50:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=WBJ7AIdR; dkim=fail reason="signature verification failed" (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=AMcdWkPh 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:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Cc:To:From:Subject:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=/WK6+GFVtDZxH5x5YzkpknHJ5MgtdwsGqE/yOwVSPsc=; b=WBJ7AIdRKtxdJrSkBEyRl8lLFv B9rQlHC4tOXbJq3i9ENfiSMD8tyWp7nXUYZZ4ckrjNa0Lh7/lGsORpUC6IUCYhOn+wrbojqnjcHoi A7dfTcDrkviug3xzPjNBvg4f/Jtw4zmSFxNwd5IPnLRToBh86DRyODx3SlL/lzSeq4tBtZNpuNtIn io28VIabk5fx4TWxSRs9UxjQiHdr/+vQbkYsxi73SPWXxx23VuCE28m9oQfNfiobSnZzOhlg/ZdPB NW3QpTl9+Xp38761nljMMejIvmTBTmLfHZlV9SfpkrunVrIysF02jQ6BqjOt3AgUPlahLcXG9+Uy6 XTzhGrzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xQOpn-00000000kId-0cVy; Mon, 09 Nov 2026 12:50:51 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xQOpm-00000000kIJ-1OKt for linux-riscv@lists.infradead.org; Mon, 09 Nov 2026 12:50:50 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 5E3EA6328A; Mon, 9 Nov 2026 12:50:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BF081F0089F; Mon, 9 Nov 2026 12:50:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794228649; bh=JjNSwO4mZ69wgWNuljj9jgcvdRQfwcVoIjX8RvCsKvM=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=AMcdWkPhAWKw4Kty4An/ZtOYneJtvpJDr03C4k9f4tW0Mo6sgerdBVpzfABUh/Izz RkYVqnfH+aQq6TxHIcOTPO9nHVxllQqqI5DJZKjTmZy/zYILGN0a0xlyY4h0Dr8/aa 5EmkN/gp8IT7gS80cbk7N/hnq86JwIN+KeT5TLtD/1Pp8NgR8gNeuWqLWiOxlArV98 lf9ViQfLIxjFbx23pEDq01GJDwvSkGChDztuhHnw56pwxwZMe40GVH5SoxrMhAFFpy ZdM2Q1b4RIxcK6EUM6ZOYnd80/6fgCvOEJUEB5mFrxshCiSW9wYfunJjU88fCRa7cI Cw5wlVwLKqaug== Subject: Re: [PATCH net] net: spacemit: Hold RTNL lock in emac_resume() and emac_suspend() From: netdev-bot+sashiko@kernel.org To: alitariq45892@gmail.com Cc: netdev@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, dlan@kernel.org, troy.mitchell@linux.spacemit.com, wangruikang@iscas.ac.cn, amadeus@jmu.edu.cn, s-vadapalli@ti.com, tmshlvck@gmail.com, meatuni001@gmail.com, vadim.fedorenko@linux.dev, maxime.chevallier@bootlin.com, linux-riscv@lists.infradead.org, spacemit@lists.linux.dev, linux-kernel@vger.kernel.org Date: Mon, 09 Nov 2026 12:50:47 +0000 Message-ID: <179422864754.994134.12281861683384047552@kernel.org> In-Reply-To: <20261105123441.2524171-1-alitariq45892@gmail.com> References: <20261105123441.2524171-1-alitariq45892@gmail.com> X-sashiko-severity: Medium X-Archived-By: MIME-Version: 1.0 X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" X-Spam-Status: No, score=-8.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MiBwb3RlbnRpYWwKaXNzdWUocykgdG8gY29uc2lkZXIuCgpDcml0aWNhbDogMCDCtyBIaWdoOiAw ICgyKSDCtyBNZWRpdW06IDIgwrcgTG93OiAwCgpJZiB5b3UgYmVsaWV2ZSBub25lIG9mIHRoZSBp c3N1ZXMgYXJlIGxlZ2l0aW1hdGUsIHBsZWFzZSByZXBseSB0byBlYWNoCmlzc3VlIG9mIE1lZGl1 bSBzZXZlcml0eSBvciBoaWdoZXIgYW5kIGV4cGxhaW4gd2h5IHRoZSBBSSBpcyB3cm9uZy4KSWYg YW55IG9mIHRoZW0gYXJlIGxlZ2l0aW1hdGUgYW5kIHlvdSBwbGFuIHRvIHJlc3BpbiwgcGxlYXNl IGxldCBwYXRjaHdvcmsKa25vdyBieSBpbmNsdWRpbmcgInB3LWJvdDogY3IiIGFzIGEgc2VwYXJh dGUgbGluZSBhdCB0aGUgZW5kIG9mIHlvdXIgcmVwbHkKKG9uZSBzdWNoIHJlcGx5IHBlciBzZXJp ZXMgaXMgZW5vdWdoKS4KCi0gW01lZGl1bV0gUG9zc2libGUgQUJCQSBkZWFkbG9jayBiZXR3ZWVu IHJ0bmxfbXV0ZXggYW5kIHRoZSBUWC10aW1lb3V0CiAgd29yaywgYWRkZWQgdG8gdGhlIHN1c3Bl bmQgcGF0aC4KLSBbTWVkaXVtXSBUaGUgbmV3IFJUTkwgc2VjdGlvbiBkb2VzIG5vdCBjb3ZlciB0 aGUgbmV0aWZfcnVubmluZygpIGNoZWNrCiAgdGhhdCBkZWNpZGVzIHdoZXRoZXIgdG8gY2FsbCBl bWFjX3N0b3AoKS9lbWFjX29wZW4oKS4KClByZS1leGlzdGluZyBpc3N1ZXM6Ci0gW0hpZ2hdIFRo aXMgcHJvYmxlbSB3YXNuJ3QgaW50cm9kdWNlZCBieSB0aGlzIHBhdGNoLCBidXQgaXQgaXMgSGln aAogIHNldmVyaXR5IGFuZCBpbnZvbHZlcyB0aGUgc2FtZSB3b3JrL1JUTkwgcGFpci4KLSBbSGln aF0gVGhpcyBwcm9ibGVtIHdhc24ndCBpbnRyb2R1Y2VkIGJ5IHRoaXMgcGF0Y2gsIGJ1dCBpdCBp cyBIaWdoCiAgc2V2ZXJpdHkgYW5kIHNpdHMgaW4gdGhlIGZ1bmN0aW9uIHRoZSBwYXRjaCBtb2Rp Zmllcy4KCi0tCgpuZXQ6IHNwYWNlbWl0OiBIb2xkIFJUTkwgbG9jayBpbiBlbWFjX3Jlc3VtZSgp IGFuZCBlbWFjX3N1c3BlbmQoKQoKVGhpcyBwYXRjaCB0YWtlcyBydG5sX2xvY2soKSBhcm91bmQg dGhlIGVtYWNfb3BlbigpIGNhbGwgaW4gZW1hY19yZXN1bWUoKQphbmQgYXJvdW5kIHRoZSBlbWFj X3N0b3AoKSBjYWxsIGluIGVtYWNfc3VzcGVuZCgpLiBUaGUgYWltIGlzIHRvIHNpbGVuY2UKYSBs b2NrZGVwICJzdXNwaWNpb3VzIFJDVSB1c2FnZSIgd2FybmluZyBmcm9tIHBoeV9kaXNjb25uZWN0 KCksIHdoaWNoCnJlYWRzIGEgcG9pbnRlciB3aXRoIHJ0bmxfZGVyZWZlcmVuY2UoKS4KCj4gZGlm ZiAtLWdpdCBhL2RyaXZlcnMvbmV0L2V0aGVybmV0L3NwYWNlbWl0L2sxX2VtYWMuYyBiL2RyaXZl cnMvbmV0L2V0aGVybmV0L3NwYWNlbWl0L2sxX2VtYWMuYwo+IGluZGV4IDcxYTgwODM4YmZmZDAu LmFjYTI1YTllMWU5ZWYgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9uZXQvZXRoZXJuZXQvc3BhY2Vt aXQvazFfZW1hYy5jCj4gKysrIGIvZHJpdmVycy9uZXQvZXRoZXJuZXQvc3BhY2VtaXQvazFfZW1h Yy5jCj4gQEAgLTIwMzMsNyArMjAzMywxMCBAQCBzdGF0aWMgaW50IGVtYWNfcmVzdW1lKHN0cnVj dCBkZXZpY2UgKmRldikKPiAgCWlmICghbmV0aWZfcnVubmluZyhuZGV2KSkKPiAgCQlyZXR1cm4g MDsKPiAgCj4gKwlydG5sX2xvY2soKTsKPiAgCXJldCA9IGVtYWNfb3BlbihuZGV2KTsKPiArCXJ0 bmxfdW5sb2NrKCk7Cj4gKwo+ICAJaWYgKHJldCkgewo+ICAJCWNsa19kaXNhYmxlX3VucHJlcGFy ZShwcml2LT5idXNfY2xrKTsKPiAgCQlyZXR1cm4gcmV0OwoKW1NldmVyaXR5OiBIaWdoXQpUaGlz IGlzIGEgcHJlLWV4aXN0aW5nIGlzc3VlLCBub3Qgb25lIGludHJvZHVjZWQgYnkgdGhpcyBwYXRj aC4gSXQgc2l0cwppbiB0aGUgZnVuY3Rpb24gYmVpbmcgY2hhbmdlZCwgdGhvdWdoLiBXaGF0IHN0 YXRlIGlzIHRoZSBkZXZpY2UgbGVmdAppbiB3aGVuIGVtYWNfb3BlbigpIGZhaWxzIGhlcmU/CgpC eSB0aGlzIHBvaW50IHRoZSB1bndpbmQgaW4gZW1hY19vcGVuKCkgaGFzIGZyZWVkIHRoZSBUWC9S WCByaW5ncy4gT25lCm9mIHR3byB0aGluZ3MgaGFzIGFsc28gaGFwcGVuZWQ6CgotIGVtYWNfdXAo KSBmYWlsZWQsIGFuZCBpdHMgZXJyb3IgcGF0aCBjYWxsZWQgcGh5X2Rpc2Nvbm5lY3QoKSBhbmQK ICBwbV9ydW50aW1lX3B1dF9zeW5jKCkuCi0gZW1hY19waHlfY29ubmVjdCgpIGZhaWxlZCwgYW5k IG5kZXYtPnBoeWRldiBpcyBzdGlsbCBOVUxMIGZyb20gdGhlCiAgcHJldmlvdXMgc3VzcGVuZC4K ClRoZSBJUlEgaXMgbm90IHJlcXVlc3RlZCBhbmQgTkFQSSBpcyBkaXNhYmxlZC4gZW1hY19yZXN1 bWUoKSB0aGVuIGdhdGVzCmJ1c19jbGsgYW5kIHJldHVybnMsIGJ1dCBfX0xJTktfU1RBVEVfU1RB UlQgYW5kIElGRl9VUCBhcmUgc3RpbGwgc2V0LgoKVGhlIG5leHQgImlwIGxpbmsgc2V0IGRvd24i LCB1bnJlZ2lzdGVyLCBvciBlbWFjX3N1c3BlbmQoKSAod2hpY2ggc2VlcwpuZXRpZl9ydW5uaW5n KCkgYXMgdHJ1ZSkgd291bGQgdGhlbiBydW46CgplbWFjX3N0b3AoKQogIGVtYWNfZG93bigpCiAg ICBwaHlfZGlzY29ubmVjdChuZGV2LT5waHlkZXYpICAgPC0gcGh5ZGV2IGlzIE5VTEwKICAgICAg cGh5X2lzX3N0YXJ0ZWQocGh5ZGV2KSAgICAgICA8LSBkZXJlZmVyZW5jZXMgcGh5ZGV2LT5zdGF0 ZQoKQ2FuIHRoaXMgb29wcz8KClBhc3QgdGhhdCBwb2ludCwgZW1hY19kb3duKCkgd291bGQ6Cgot IHdyaXRlIE1BQyByZWdpc3RlcnMgd2l0aCB0aGUgYnVzIGNsb2NrIGdhdGVkCi0gY2FsbCBmcmVl X2lycSgpIG9uIGFuIElSUSB0aGF0IGlzIG5vdCByZXF1ZXN0ZWQKLSBjYWxsIG5hcGlfZGlzYWJs ZSgpIG9uIGEgTkFQSSB0aGF0IGlzIGFscmVhZHkgZGlzYWJsZWQKLSB1bmRlcmZsb3cgdGhlIHJ1 bnRpbWUgUE0gdXNhZ2UgY291bnQKCkFsc28sIGVtYWNfY2xlYW5fcnhfZGVzY19yaW5nKCkgd291 bGQgaW5kZXggdGhlIE5VTEwgcnhfZGVzY19idWYsIGFuZAplbWFjX3N1c3BlbmQoKSB3b3VsZCBj YWxsIGNsa19kaXNhYmxlX3VucHJlcGFyZShwcml2LT5idXNfY2xrKSBhIHNlY29uZAp0aW1lLgoK U2VwYXJhdGVseSwgZW1hY19hbGxvY190eF9yZXNvdXJjZXMoKSBhbmQgZW1hY19hbGxvY19yeF9y ZXNvdXJjZXMoKQprZnJlZSgpIHRoZSBidWZmZXIgYXJyYXkgd2hlbiBkbWFfYWxsb2NfY29oZXJl bnQoKSBmYWlscywgYnV0IHRoZXkgZG8Kbm90IHNldCB0aGUgcG9pbnRlciB0byBOVUxMOgoKCWlm ICghdHhfcmluZy0+ZGVzY19hZGRyKSB7CgkJa2ZyZWUodHhfcmluZy0+dHhfZGVzY19idWYpOwoJ CXJldHVybiAtRU5PTUVNOwoJfQoKQ291bGQgYSBsYXRlciB0ZWFyZG93biBmcmVlIHR4X2Rlc2Nf YnVmIChvciByeF9kZXNjX2J1ZikgYSBzZWNvbmQgdGltZQp0aHJvdWdoIHRoYXQgc3RhbGUgcG9p bnRlcj8KCj4gQEAgLTIwNTYsNyArMjA1OSw5IEBAIHN0YXRpYyBpbnQgZW1hY19zdXNwZW5kKHN0 cnVjdCBkZXZpY2UgKmRldikKPiAgCQlyZXR1cm4gMDsKPiAgCX0KPiAgCj4gKwlydG5sX2xvY2so KTsKPiAgCWVtYWNfc3RvcChuZGV2KTsKPiArCXJ0bmxfdW5sb2NrKCk7CgpbU2V2ZXJpdHk6IE1l ZGl1bV0KZW1hY19zdXNwZW5kKCkgY2hlY2tzIG5ldGlmX3J1bm5pbmcoKSB0byBkZWNpZGUgd2hl dGhlciB0byBjYWxsCmVtYWNfc3RvcCgpLiBUaGF0IGNoZWNrIHJ1bnMgYmVmb3JlIHJ0bmxfbG9j aygpIGFuZCBpcyBub3QgcmVwZWF0ZWQKdW5kZXIgdGhlIGxvY2s6CgoJaWYgKCFuZGV2IHx8ICFu ZXRpZl9ydW5uaW5nKG5kZXYpKSB7CgkJY2xrX2Rpc2FibGVfdW5wcmVwYXJlKHByaXYtPmJ1c19j bGspOwoJCXJldHVybiAwOwoJfQoKCXJ0bmxfbG9jaygpOwoJZW1hY19zdG9wKG5kZXYpOwoKQ2Fu IGFub3RoZXIgUlROTCBob2xkZXIgY2xvc2UgdGhlIGRldmljZSBpbiBiZXR3ZWVuPwoKSGVyZSBp cyBvbmUgZXhhbXBsZS4gVGhlIG5ldGRldiBpcyBtb3ZlZCBpbnRvIGEgbmV0bnMsIGFuZCB0aGF0 IG5ldG5zCmlzIHRvcm4gZG93biBhcyBzeXN0ZW0gc2xlZXAgc3RhcnRzLiBjbGVhbnVwX25ldCBy dW5zIG9uIG5ldG5zX3dxLAp3aGljaCBpcyBub3QgZnJlZXphYmxlLiBJdCBob2xkcyBSVE5MIGFu ZCBjYWxscyBkZXZfY2xvc2UoKSwgd2hpY2gKY2FsbHMgZW1hY19zdG9wKCkuCgpNZWFud2hpbGUg ZW1hY19zdXNwZW5kKCkgaGFzIGFscmVhZHkgc2VlbiBuZXRpZl9ydW5uaW5nKCkgYXMgdHJ1ZS4g SXQKYmxvY2tzIGluIHJ0bmxfbG9jaygpLCB0aGVuIHJ1bnMgZW1hY19zdG9wKCkgYSBzZWNvbmQg dGltZS4gVGhlcmUsCmVtYWNfZG93bigpIGNhbGxzIHBoeV9kaXNjb25uZWN0KG5kZXYtPnBoeWRl dikgd2l0aCBwaHlkZXYgYWxyZWFkeQpOVUxMLCBhbmQgcGh5X2lzX3N0YXJ0ZWQoKSBkZXJlZmVy ZW5jZXMgaXQuCgplbWFjX3Jlc3VtZSgpIGhhcyB0aGUgbWlycm9yIGNhc2UuIEl0IGFsc28gdGVz dHMgbmV0aWZfcnVubmluZygpIGJlZm9yZQpydG5sX2xvY2soKSwgc28gaXQgY291bGQgY2FsbCBl bWFjX29wZW4oKSBvbiBhIGRldmljZSB0aGF0IHdhcyBqdXN0CmNsb3NlZC4gVGhhdCB3b3VsZCBs ZWFrIHRoZSByaW5ncywgdGhlIElSUSBhbmQgdGhlIFBIWSBhdHRhY2guCgpXb3VsZCBpdCBtYWtl IHNlbnNlIHRvIHRha2UgcnRubF9sb2NrKCkgYmVmb3JlIHRoZSBuZXRpZl9ydW5uaW5nKCkKdGVz dCwgd2l0aCBuZXRpZl9kZXZpY2VfZGV0YWNoKCkgLyBuZXRpZl9kZXZpY2VfYXR0YWNoKCkgaW5z aWRlIHRoZQpzYW1lIGxvY2tlZCBzZWN0aW9uPwoKW1NldmVyaXR5OiBNZWRpdW1dCkRvZXMgaG9s ZGluZyBSVE5MIGhlcmUgaW52ZXJ0IHRoZSBsb2NrIG9yZGVyIHdpdGggdHhfdGltZW91dF90YXNr PwplbWFjX3N0b3AoKS0+ZW1hY19kb3duKCkgZG9lczoKCgljYW5jZWxfd29ya19zeW5jKCZwcml2 LT50eF90aW1lb3V0X3Rhc2spOwoKYW5kIHRoZSB3b3JrIGhhbmRsZXIgdGFrZXMgUlROTCBmaXJz dDoKCmVtYWNfdHhfdGltZW91dF90YXNrKCkgewoJLi4uCglydG5sX2xvY2soKTsKCS4uLgp9Cgpl bWFjX3R4X3RpbWVvdXQoKSBxdWV1ZXMgdGhlIHdvcmsgd2l0aCBzY2hlZHVsZV93b3JrKCkuIFRo YXQgdXNlcyB0aGUKc3lzdGVtIHdvcmtxdWV1ZSwgd2hpY2ggaXMgbm90IGZyZWV6YWJsZSwgc28g dGhlIHdvcmsgY2FuIHJ1biBkdXJpbmcKc3lzdGVtIHN1c3BlbmQ6CgpDUFUxICh3b3JrZXIpICAg ICAgICAgICAgICAgICAgICAgIENQVTIgKHN1c3BlbmQpCmVtYWNfdHhfdGltZW91dF90YXNrKCkK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbWFjX3N1c3BlbmQoKQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnRubF9sb2NrKCkKICBydG5sX2xvY2soKSAg PC0gYmxvY2tzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbWFjX3N0b3Ao KQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbWFjX2Rvd24oKQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhbmNlbF93b3JrX3N5bmMoKQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0gd2FpdHMgZm9yIENQ VTEKCmNhbmNlbF93b3JrX3N5bmMoKSBnb2VzIHRocm91Z2ggX19mbHVzaF93b3JrKCktPnN0YXJ0 X2ZsdXNoX3dvcmsoKS4KVGhhdCBmaW5kcyB0aGUgZXhlY3V0aW5nIHdvcmtlciB3aXRoIGZpbmRf d29ya2VyX2V4ZWN1dGluZ193b3JrKCkgYW5kCndhaXRzIG9uIGEgYmFycmllciBxdWV1ZWQgYmVo aW5kIGl0LgoKQ2FuIHRoaXMgaGFuZyBzdXNwZW5kPyBMb2NrZGVwIG1heSBhbHNvIHJlcG9ydCBh IGNpcmN1bGFyIGRlcGVuZGVuY3kKYmV0d2VlbiBydG5sX211dGV4IGFuZCB0aGUgd29yaydzIGxv Y2tkZXBfbWFwLCB3aGljaCB3b3VsZCBzd2FwIG9uZQpzcGxhdCBmb3IgYW5vdGhlci4KClRoZSBu ZG9fc3RvcCBwYXRoIChkZXZfY2xvc2UoKSB1bmRlciBSVE5MLCB0aGVuIGVtYWNfc3RvcCgpKSBh bHJlYWR5CmhhcyB0aGlzIHBhdHRlcm4uIFRoaXMgcGF0Y2ggYWRkcyBpdCB0byB0aGUgc3lzdGVt IHNsZWVwIHBhdGggdG9vLgoKQ291bGQgdGhlIHN5bmNocm9ub3VzIGNhbmNlbCBiZSBrZXB0IG91 dCBvZiBhbnkgUlROTC1oZWxkIHNlY3Rpb24/Ck9wdGlvbnMgaW5jbHVkZSBjYW5jZWxsaW5nIHRo ZSB3b3JrIGJlZm9yZSB0YWtpbmcgUlROTCwgdXNpbmcKcnRubF90cnlsb2NrKCkgYW5kIHJlcXVl dWVpbmcgaW4gdGhlIHdvcmssIG9yIGEgZGlzYWJsZV93b3JrKCkgYmFzZWQKc2NoZW1lLgoKW1Nl dmVyaXR5OiBIaWdoXQpUaGlzIGlzbid0IGEgYnVnIGludHJvZHVjZWQgYnkgdGhpcyBwYXRjaCwg YnV0IGl0IGludm9sdmVzIHRoZSBzYW1lCndvcmsgYW5kIFJUTkwgcGFpci4gQ2FuIGVtYWNfdHhf dGltZW91dF90YXNrKCkgd2FpdCBvbiBpdHNlbGY/CgplbWFjX3R4X3RpbWVvdXRfdGFzaygpICAg ICAgICAgIDwtIHJ1bm5pbmcgYXMgcHJpdi0+dHhfdGltZW91dF90YXNrCiAgcnRubF9sb2NrKCkK ICBkZXZfY2xvc2UobmRldikKICAgIF9fZGV2X2Nsb3NlX21hbnkoKQogICAgICBlbWFjX3N0b3Ao KSAgICAgICAgICAgICAgIDwtIG5kb19zdG9wCiAgICAgICAgZW1hY19kb3duKCkKICAgICAgICAg IGNhbmNlbF93b3JrX3N5bmMoJnByaXYtPnR4X3RpbWVvdXRfdGFzaykKCkF0IHRoaXMgcG9pbnQg dGhlIHdvcmsgaXMgZXhlY3V0aW5nLCBub3QgcXVldWVkLiBzdGFydF9mbHVzaF93b3JrKCkKZmlu ZHMgdGhlIGNhbGxpbmcgd29ya2VyIGl0c2VsZiB0aHJvdWdoIGZpbmRfd29ya2VyX2V4ZWN1dGlu Z193b3JrKCkuCkl0IHRoZW4gaW5zZXJ0cyBhIGJhcnJpZXIgdGhhdCBjYW4gb25seSBydW4gYWZ0 ZXIgdGhlIGN1cnJlbnQgd29yawpyZXR1cm5zLCBzbyB3YWl0X2Zvcl9jb21wbGV0aW9uKCkgaW4g X19mbHVzaF93b3JrKCkgbmV2ZXIgcmV0dXJucy4KCldvdWxkIGV2ZXJ5IFRYIHRpbWVvdXQgcmVj b3ZlcnkgbGVhdmUgdGhlIHdvcmtlciBzdHVjayB3aGlsZSBob2xkaW5nCnJ0bmxfbXV0ZXg/IFRo YXQgd291bGQgYmxvY2sgZXZlcnkgUlROTCB1c2VyLiBXaXRoIHRoaXMgcGF0Y2gsIHRoZSBuZXh0 CmVtYWNfc3VzcGVuZCgpIHdvdWxkIGFsc28gYmxvY2sgZm9yZXZlciBpbiBpdHMgbmV3IHJ0bmxf bG9jaygpLgoKLS0gClNhc2hpa28gQUkgcmV2aWV3IMK3IGh0dHBzOi8vbmV0ZGV2LWFpLmJvdHMu bGludXguZGV2L3Nhc2hpa28vIy9wYXRjaHNldC8yMDI2MTEwNTEyMzQ0MS4yNTI0MTcxLTEtYWxp dGFyaXE0NTg5MiU0MGdtYWlsLmNvbQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KbGludXgtcmlzY3YgbWFpbGluZyBsaXN0CmxpbnV4LXJpc2N2QGxpc3Rz LmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5m by9saW51eC1yaXNjdgo=