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 CE08DC43458 for ; Mon, 13 Jul 2026 12:42:41 +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=D4fvlaCHI4gD9Ryv7+pUr9054mAVDsBW1glmQ0KkkNg=; b=OtnFU+teAypHcL aZJcZZqQcD8DsFqJUEVR1Kh50yK9Msd690IGtFH72PmvATaTnU2stylISIR0nDhbv/lVd24fM6sal JHrtAci5I4YcjhiZ2Mg02TeeeLUWiz+kM3Q9Ww4CUdHGrQIaoKX468wKPkgU//G9boHmPcgnEfcuZ UkVNrSNawObgooVkLB4kA+Gq5YJQXAQkj84P1Jcgytj/Ew/BgH6ZMaWtgrzAR18uiqZmD6awdgw3U +KpWsZKT+ZKDhTbW+g5hv+esI3hpMNK4vFR3t/Ac2LzdFIqiV5OwzN6v9BB1NSH+7ykvhQRUBMA2k rLUT7oN+D6efajIrPw9Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjFzZ-00000009Djb-2PBL; Mon, 13 Jul 2026 12:42:37 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjFzY-00000009Dj0-1Wqx for linux-amlogic@lists.infradead.org; Mon, 13 Jul 2026 12:42:36 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id DAA3F434ED; Mon, 13 Jul 2026 12:42:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BE331F000E9; Mon, 13 Jul 2026 12:42:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783946555; bh=Wx7oiArxQ0vNgschEOJbP2Q3vCsNxXvegFU4jYy34Qw=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=Rwp1xDM+Jn0t2iN17uXVq8mR90HeGNKEk2Y3peG4mh+VZortZemdftLjsKbsgzWzX Dt/kSHzcplbpejgZKk4D6FuhXdoJef4hssbH2hO4PN5xgE3y2/PRjvGC4yx5+zCcL3 5x2cKjbV7w9XYapezyFhg4znysTyMDl9IqpQxzrEu865IAKLVf7BdYCJErBTyAKkVd NzLpmt28Y/BLmQSrCI/+blTqn2E9CvnirUpOs0BdOJBvG+h8m0wHlhoHvFSjcZ+pPw mjy42B6K4RKjQrxop0pNI+6+kfsY/B0Uj4sVm2lGrO+X90Jre2leRgkJ1IUwjP/BUf JQA9IInmK8acw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 08/19] media: meson: vdec: Fix concurrent execution races and unsafe teardown To: "Anand Moon" Cc: linux-amlogic@lists.infradead.org, dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org In-Reply-To: <20260713120840.17427-9-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-9-linux.amoon@gmail.com> Date: Mon, 13 Jul 2026 12:42:34 +0000 Message-Id: <20260713124235.7BE331F000E9@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 NCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0NyaXRpY2FsXSBVbmNvbmRpdGlv bmFsIG51bGxpZmljYXRpb24gb2YgYGNvcmUtPmN1cl9zZXNzYCBpbiBgdmRlY19jbG9zZSgpYCBh bGxvd3MgY29uY3VycmVudCBzZXNzaW9ucyB0byBjbG9iYmVyIGhhcmR3YXJlIG93bmVyc2hpcCwg dHJpZ2dlcmluZyBpbnRlcnJ1cHQgc3Rvcm1zIGFuZCBzZXZlcmUgbWVtb3J5IGxlYWtzLgotIFtI aWdoXSBBQi1CQSBkZWFkbG9jayBiZXR3ZWVuIGB2ZGVjX3N0b3Bfc3RyZWFtaW5nKClgIGFuZCBg ZXNwYXJzZXJfcXVldWVfYWxsX3NyYygpYCB3b3JrcXVldWUgZHVlIHRvIGBjYW5jZWxfd29ya19z eW5jKClgLgotIFtIaWdoXSBJbnZlcnRlZCBsb29wIGxvZ2ljIGluIGBlc3BhcnNlcl9xdWV1ZV9h bGxfc3JjKClgIGNhdXNlcyBpbmZpbml0ZSBDUFUgYnVzeS13YWl0IG9uIGhhcmR3YXJlIGJhY2tw cmVzc3VyZSBhbmQgcHJlbWF0dXJlIGV4aXQgb24gc3VjY2Vzcy4KLSBbTWVkaXVtXSBNZW1vcnkg bGVhayBvZiBgc2Vzcy0+cHJpdmAgb24gdGhlIG5ld2x5IGFkZGVkIGB2ZGVjX3N0YXJ0X3N0cmVh bWluZygpYCBlcnJvciBwYXRoLgotLQoKLS0tIFBhdGNoIFs4XTogW1BBVENIIHY3IDA4LzE5XSBt ZWRpYTogbWVzb246IHZkZWM6IEZpeCBjb25jdXJyZW50IGV4ZWN1dGlvbiByYWNlcyBhbmQgdW5z YWZlIHRlYXJkb3duIC0tLQpjb21taXQgNDU4N2U2YmJkMDkxZDY2NDViZTYyNGRjMTg1YzBmYWRk ZWQ4NjQ5YgpBdXRob3I6IEFuYW5kIE1vb24gPGxpbnV4LmFtb29uQGdtYWlsLmNvbT4KCm1lZGlh OiBtZXNvbjogdmRlYzogRml4IGNvbmN1cnJlbnQgZXhlY3V0aW9uIHJhY2VzIGFuZCB1bnNhZmUg dGVhcmRvd24KCkFkZHJlc3MgZGF0YSByYWNlcyBpbnZvbHZpbmcgJ3Nob3VsZF9zdG9wJyBhbmQg cHJldmVudCBtdWx0aS1zZXNzaW9uCmhhcmR3YXJlIGNsb2JiZXJpbmcgYnkgZW5mb3JjaW5nIGF0 b21pYyB0cmFja2luZyBhbmQgc3RyaWN0IG93bmVyCnZhbGlkYXRpb24gZHVyaW5nIGRldmljZSB0 ZWFyZG93bi4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvc3RhZ2luZy9tZWRpYS9tZXNvbi92ZGVj L2VzcGFyc2VyLmMgYi9kcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5j Cj4gaW5kZXggZTVkM2Q4MTdiOWIyYi4uOTU5NjczNzQyZTY5OSAxMDA2NDQKPiAtLS0gYS9kcml2 ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5jCj4gKysrIGIvZHJpdmVycy9z dGFnaW5nL21lZGlhL21lc29uL3ZkZWMvZXNwYXJzZXIuYwo+IEBAIC0zNzksNyArMzc5LDcgQEAg dm9pZCBlc3BhcnNlcl9xdWV1ZV9hbGxfc3JjKHN0cnVjdCB3b3JrX3N0cnVjdCAqd29yaykKPiAg Cj4gIAkJc2NvcGVkX2d1YXJkKG11dGV4LCAmc2Vzcy0+bG9jaykgewo+ICAJCQkvKiBTYWZlIGF0 b21pYyB0cmFja2luZyBjaGVjazogZXhpdCBsb29wIGlmIHNlc3Npb24gaXMgc2h1dHRpbmcgZG93 biAqLwo+IC0JCQlpZiAoc2Vzcy0+c2hvdWxkX3N0b3ApCj4gKwkJCWlmIChSRUFEX09OQ0Uoc2Vz cy0+c2hvdWxkX3N0b3ApKQo+ICAJCQkJcmV0dXJuOwoKW1NldmVyaXR5OiBIaWdoXQpDb3VsZCB0 aGUgd29ya3F1ZXVlIGdldCBzdHVjayBpbiBhbiBpbmZpbml0ZSBsb29wIGR1ZSB0byBob3cgc2Nv cGVkX2d1YXJkCmV4cGFuZHM/CgpCZWNhdXNlIHNjb3BlZF9ndWFyZChtdXRleCwgJnNlc3MtPmxv Y2spIGV4cGFuZHMgdG8gYSBmb3IgbG9vcCwgaWYgdGhlCmlubmVyIGNvZGUgaGl0cyBhbiBlbXB0 eSBxdWV1ZSBvciAtRUFHQUlOIGFuZCBjYWxscyBicmVhaywgaXQgd2lsbCBvbmx5CmV4aXQgdGhl IHNjb3BlZF9ndWFyZCBsb29wLCBsZWF2aW5nIHByb2Nlc3NlZF9mcmFtZSBhcyBmYWxzZS4KClRo ZSBjb2RlIHRoZW4gZXZhbHVhdGVzIGlmIChwcm9jZXNzZWRfZnJhbWUpIGJyZWFrOyB3aGljaCBm YWlscywgZXhlY3V0ZXMKY29uZF9yZXNjaGVkKCksIGFuZCBsb29wcyB0aGUgb3V0ZXIgd2hpbGUg KDEpIGluZmluaXRlbHkuCgpDb252ZXJzZWx5LCBpZiBhIGZyYW1lIGlzIHN1Y2Nlc3NmdWxseSBw cm9jZXNzZWQgKHByb2Nlc3NlZF9mcmFtZSBpcyB0cnVlKSwKZG9lcyB0aGUgbG9vcCBicmVhayBl bnRpcmVseSwgY2F1c2luZyB0aGUgd29ya3F1ZXVlIHRvIGV4aXQgYWZ0ZXIgcHJvY2Vzc2luZwpq dXN0IGEgc2luZ2xlIGZyYW1lPwoKWyAuLi4gXQoKPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9zdGFn aW5nL21lZGlhL21lc29uL3ZkZWMvdmRlYy5jIGIvZHJpdmVycy9zdGFnaW5nL21lZGlhL21lc29u L3ZkZWMvdmRlYy5jCj4gaW5kZXggNmZlOTcyMjU3NzE3OS4uODNhOWIxMjM4OTcyYSAxMDA2NDQK PiAtLS0gYS9kcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy92ZGVjLmMKPiArKysgYi9k cml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy92ZGVjLmMKClsgLi4uIF0KCj4gQEAgLTM4 OCwxMCArMzkyLDEyIEBAIHN0YXRpYyBpbnQgdmRlY19zdGFydF9zdHJlYW1pbmcoc3RydWN0IHZi Ml9xdWV1ZSAqcSwgdW5zaWduZWQgaW50IGNvdW50KQo+ICAJCXNlc3MtPnN0cmVhbW9uX2NhcCA9 IDA7Cj4gIAo+ICAJbXV0ZXhfbG9jaygmY29yZS0+bG9jayk7Cj4gLQlpZiAoY29yZS0+Y3VyX3Nl c3MgPT0gc2VzcykKPiAtCQljb3JlLT5jdXJfc2VzcyA9IE5VTEw7Cj4gLQlpZiAoc2Vzcy0+c3Rh dHVzICE9IFNUQVRVU19ORUVEU19SRVNVTUUpCj4gLQkJc2Vzcy0+c3RhdHVzID0gU1RBVFVTX1NU T1BQRUQ7Cj4gKwlpZiAoY29yZS0+Y3VyX3Nlc3MgPT0gc2Vzcykgewo+ICsJCS8qIFNhZmVseSBj bGVhciBoYXJkd2FyZSBvd25lcnNoaXAgc2luY2Ugd2Ugd2VyZSBjb25maXJtZWQgYXMgdGhlIG93 bmVyICovCj4gKwkJc21wX3N0b3JlX3JlbGVhc2UoJmNvcmUtPmN1cl9zZXNzLCBOVUxMKTsKPiAr CQlpZiAoc2Vzcy0+c3RhdHVzICE9IFNUQVRVU19ORUVEU19SRVNVTUUpCj4gKwkJCXNlc3MtPnN0 YXR1cyA9IFNUQVRVU19TVE9QUEVEOwo+ICsJfQo+ICAJbXV0ZXhfdW5sb2NrKCZjb3JlLT5sb2Nr KTsKPiAgZXJyX3VubG9ja19ub19odzoKCltTZXZlcml0eTogTWVkaXVtXQpJcyB0aGVyZSBhIG1l bW9yeSBsZWFrIG9mIHNlc3MtPnByaXYgb24gdGhlIGVycm9yIHBhdGhzIGluCnZkZWNfc3RhcnRf c3RyZWFtaW5nKCk/CgpJZiB2ZGVjX3Bvd2Vyb24oKSBzdWNjZWVkcyAod2hpY2ggZHluYW1pY2Fs bHkgYWxsb2NhdGVzIHNlc3MtPnByaXYpLCBidXQKYSBsYXRlciBzdGVwIGxpa2Uga3RocmVhZF9y dW4oKSBmYWlscywgdGhlIGNvZGUganVtcHMgdG8gZXJyX3Bvd2Vyb2ZmLgpXaGlsZSB0aGUgaGFy ZHdhcmUgc3RhdGUgYW5kIHZpZmlmb192YWRkciBhcmUgcm9sbGVkIGJhY2ssIGtmcmVlKHNlc3Mt PnByaXYpCmFwcGVhcnMgdG8gYmUgbWlzc2luZy4KCklmIFZJRElPQ19TVFJFQU1PTiByZXBlYXRl ZGx5IGZhaWxzLCBjb3VsZCB0aGlzIGxlYWsga2VybmVsIG1lbW9yeT8KClsgLi4uIF0KCj4gQEAg LTQ5MywyNiArNTAyLDMzIEBAIHN0YXRpYyB2b2lkIHZkZWNfc3RvcF9zdHJlYW1pbmcoc3RydWN0 IHZiMl9xdWV1ZSAqcSkKPiAgCQljYW5jZWxfd29ya19zeW5jKCZzZXNzLT5lc3BhcnNlcl9xdWV1 ZV93b3JrKTsKCltTZXZlcml0eTogSGlnaF0KQ2FuIHRoaXMgY2F1c2UgYW4gQUItQkEgZGVhZGxv Y2sgYmV0d2VlbiB0aGUgVjRMMiBjb3JlIGFuZCB0aGUgd29ya3F1ZXVlPwoKV2hlbiB1c2Vyc3Bh Y2UgY2FsbHMgVklESU9DX1NUUkVBTU9GRiwgdGhlIFY0TDIgY29yZSBhY3F1aXJlcyB0aGUgcXVl dWUgbG9jawooc2Vzcy0+bG9jayksIHRoZW4gY2FsbHMgdmRlY19zdG9wX3N0cmVhbWluZygpLCB3 aGljaCBjYWxscwpjYW5jZWxfd29ya19zeW5jKCkgaGVyZS4KCk1lYW53aGlsZSwgdGhlIGVzcGFy c2VyX3F1ZXVlX2FsbF9zcmMoKSB3b3JrcXVldWUgbG9vcCB1c2VzCnNjb3BlZF9ndWFyZChtdXRl eCwgJnNlc3MtPmxvY2spIHRvIGFjcXVpcmUgdGhlIGV4YWN0IHNhbWUgbG9jay4gSWYgdGhlCndv cmtxdWV1ZSBpcyBhY3RpdmUsIGl0IHdpbGwgYmxvY2sgd2FpdGluZyBmb3Igc2Vzcy0+bG9jaywg d2hpbGUKdmRlY19zdG9wX3N0cmVhbWluZygpIGJsb2NrcyBpbmRlZmluaXRlbHkgd2FpdGluZyBm b3IgdGhlIHdvcmtxdWV1ZSB0byBleGl0LgoKPiAgCQltdXRleF9sb2NrKCZjb3JlLT5sb2NrKTsK PiAgCj4gLQkJdmRlY19wb3dlcm9mZihzZXNzKTsKPiAtCQl2ZGVjX2ZyZWVfY2FudmFzKHNlc3Mp OwoKWyAuLi4gXQoKPiBAQCAtMTAxMiwyMSArMTAzMSwzMCBAQCBzdGF0aWMgaW50IHZkZWNfY2xv c2Uoc3RydWN0IGZpbGUgKmZpbGUpCgpbIC4uLiBdCgo+ICAJa2ZyZWUoc2Vzcy0+cHJpdik7Cj4g IAlzZXNzLT5wcml2ID0gTlVMTDsKPiAgCj4gKwkvKiBVbmNvbmRpdGlvbmFsbHkgc2V0IG91ciBs b2NhbCBzdGF0dXMgdG8gc3RvcHBlZCAqLwo+ICsJc2Vzcy0+c3RhdHVzID0gU1RBVFVTX1NUT1BQ RUQ7Cj4gKwkvKiBTYWZlbHkgY2xlYXIgaGFyZHdhcmUgb3duZXJzaGlwIHNpbmNlIHdlIHdlcmUg Y29uZmlybWVkIGFzIHRoZSBvd25lciAqLwo+ICsJc21wX3N0b3JlX3JlbGVhc2UoJmNvcmUtPmN1 cl9zZXNzLCBOVUxMKTsKPiArCgpbU2V2ZXJpdHk6IENyaXRpY2FsXQpEb2VzIHRoaXMgdW5jb25k aXRpb25hbGx5IGNsZWFyIHRoZSBoYXJkd2FyZSBvd25lcnNoaXAsIGV2ZW4gaWYgdGhpcyBzZXNz aW9uCmRvZXNuJ3Qgb3duIGl0PwoKSWYgc2Vzc2lvbiBBIGlzIHN0cmVhbWluZyBhbmQgc2Vzc2lv biBCIGlzIGNsb3NlZCwgdmRlY19jbG9zZSgpIGZvciBzZXNzaW9uCkIgd2lsbCBleGVjdXRlIHNt cF9zdG9yZV9yZWxlYXNlKCZjb3JlLT5jdXJfc2VzcywgTlVMTCkgb3V0c2lkZSBvZiB0aGUKaWYg KGNvcmUtPmN1cl9zZXNzID09IHNlc3MpIGNoZWNrLgoKSWYgY29yZS0+Y3VyX3Nlc3MgYmVjb21l cyBOVUxMIHdoaWxlIHNlc3Npb24gQSdzIGhhcmR3YXJlIGlzIGFjdGl2ZSwgY291bGQKdGhlIG5l eHQgaGFyZHdhcmUgaW50ZXJydXB0IHRyaWdnZXIgdmRlY19pc3IoKSB3aGljaCBzZWVzICFjb3Jl LT5jdXJfc2VzcwphbmQgcmV0dXJucyBJUlFfSEFORExFRCB3aXRob3V0IGNsZWFyaW5nIHRoZSBo YXJkd2FyZSBpbnRlcnJ1cHQgc3RhdHVzPwoKU2luY2UgdGhlIGludGVycnVwdCBpcyBsZXZlbC10 cmlnZ2VyZWQsIGNvdWxkIHRoaXMgcmVzdWx0IGluIGFuIGltbWVkaWF0ZQppbnRlcnJ1cHQgc3Rv cm0gdGhhdCBoYW5ncyB0aGUgQ1BVLCBhbmQgcGVybWFuZW50bHkgbGVhayBzZXNzaW9uIEEncwp2 aWZpZm9fdmFkZHIgRE1BIGJ1ZmZlcnMgd2hlbiBzZXNzaW9uIEEgaXMgZXZlbnR1YWxseSBjbG9z ZWQ/Cgo+ICAJbXV0ZXhfdW5sb2NrKCZjb3JlLT5sb2NrKTsKPiAgCj4gIAl2NGwyX20ybV9jdHhf cmVsZWFzZShzZXNzLT5tMm1fY3R4KTsKCi0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRwczov L3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA3MTMxMjA4NDAuMTc0MjctMS1saW51eC5hbW9v bkBnbWFpbC5jb20/cGFydD04CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpsaW51eC1hbWxvZ2ljIG1haWxpbmcgbGlzdApsaW51eC1hbWxvZ2ljQGxpc3Rz LmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5m by9saW51eC1hbWxvZ2ljCg== 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id A7DEDC43458 for ; Mon, 13 Jul 2026 12:42:37 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0FD2810E5BB; Mon, 13 Jul 2026 12:42:37 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="Rwp1xDM+"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2CA3110E5BB for ; Mon, 13 Jul 2026 12:42:36 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id DAA3F434ED; Mon, 13 Jul 2026 12:42:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BE331F000E9; Mon, 13 Jul 2026 12:42:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783946555; bh=Wx7oiArxQ0vNgschEOJbP2Q3vCsNxXvegFU4jYy34Qw=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=Rwp1xDM+Jn0t2iN17uXVq8mR90HeGNKEk2Y3peG4mh+VZortZemdftLjsKbsgzWzX Dt/kSHzcplbpejgZKk4D6FuhXdoJef4hssbH2hO4PN5xgE3y2/PRjvGC4yx5+zCcL3 5x2cKjbV7w9XYapezyFhg4znysTyMDl9IqpQxzrEu865IAKLVf7BdYCJErBTyAKkVd NzLpmt28Y/BLmQSrCI/+blTqn2E9CvnirUpOs0BdOJBvG+h8m0wHlhoHvFSjcZ+pPw mjy42B6K4RKjQrxop0pNI+6+kfsY/B0Uj4sVm2lGrO+X90Jre2leRgkJ1IUwjP/BUf JQA9IInmK8acw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 08/19] media: meson: vdec: Fix concurrent execution races and unsafe teardown To: "Anand Moon" Cc: linux-amlogic@lists.infradead.org, dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org In-Reply-To: <20260713120840.17427-9-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-9-linux.amoon@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2026 12:42:34 +0000 Message-Id: <20260713124235.7BE331F000E9@smtp.kernel.org> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Thank you for your contribution! Sashiko AI review found 4 potential issue(= s) to consider: - [Critical] Unconditional nullification of `core->cur_sess` in `vdec_close= ()` allows concurrent sessions to clobber hardware ownership, triggering in= terrupt storms and severe memory leaks. - [High] AB-BA deadlock between `vdec_stop_streaming()` and `esparser_queue= _all_src()` workqueue due to `cancel_work_sync()`. - [High] Inverted loop logic in `esparser_queue_all_src()` causes infinite = CPU busy-wait on hardware backpressure and premature exit on success. - [Medium] Memory leak of `sess->priv` on the newly added `vdec_start_strea= ming()` error path. -- --- Patch [8]: [PATCH v7 08/19] media: meson: vdec: Fix concurrent executio= n races and unsafe teardown --- commit 4587e6bbd091d6645be624dc185c0fadded8649b Author: Anand Moon media: meson: vdec: Fix concurrent execution races and unsafe teardown Address data races involving 'should_stop' and prevent multi-session hardware clobbering by enforcing atomic tracking and strict owner validation during device teardown. > diff --git a/drivers/staging/media/meson/vdec/esparser.c b/drivers/stagin= g/media/meson/vdec/esparser.c > index e5d3d817b9b2b..959673742e699 100644 > --- a/drivers/staging/media/meson/vdec/esparser.c > +++ b/drivers/staging/media/meson/vdec/esparser.c > @@ -379,7 +379,7 @@ void esparser_queue_all_src(struct work_struct *work) > =20 > scoped_guard(mutex, &sess->lock) { > /* Safe atomic tracking check: exit loop if session is shutting down = */ > - if (sess->should_stop) > + if (READ_ONCE(sess->should_stop)) > return; [Severity: High] Could the workqueue get stuck in an infinite loop due to how scoped_guard expands? Because scoped_guard(mutex, &sess->lock) expands to a for loop, if the inner code hits an empty queue or -EAGAIN and calls break, it will only exit the scoped_guard loop, leaving processed_frame as false. The code then evaluates if (processed_frame) break; which fails, executes cond_resched(), and loops the outer while (1) infinitely. Conversely, if a frame is successfully processed (processed_frame is true), does the loop break entirely, causing the workqueue to exit after processing just a single frame? [ ... ] > diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/me= dia/meson/vdec/vdec.c > index 6fe9722577179..83a9b1238972a 100644 > --- a/drivers/staging/media/meson/vdec/vdec.c > +++ b/drivers/staging/media/meson/vdec/vdec.c [ ... ] > @@ -388,10 +392,12 @@ static int vdec_start_streaming(struct vb2_queue *q= , unsigned int count) > sess->streamon_cap =3D 0; > =20 > mutex_lock(&core->lock); > - if (core->cur_sess =3D=3D sess) > - core->cur_sess =3D NULL; > - if (sess->status !=3D STATUS_NEEDS_RESUME) > - sess->status =3D STATUS_STOPPED; > + if (core->cur_sess =3D=3D sess) { > + /* Safely clear hardware ownership since we were confirmed as the owne= r */ > + smp_store_release(&core->cur_sess, NULL); > + if (sess->status !=3D STATUS_NEEDS_RESUME) > + sess->status =3D STATUS_STOPPED; > + } > mutex_unlock(&core->lock); > err_unlock_no_hw: [Severity: Medium] Is there a memory leak of sess->priv on the error paths in vdec_start_streaming()? If vdec_poweron() succeeds (which dynamically allocates sess->priv), but a later step like kthread_run() fails, the code jumps to err_poweroff. While the hardware state and vififo_vaddr are rolled back, kfree(sess->priv) appears to be missing. If VIDIOC_STREAMON repeatedly fails, could this leak kernel memory? [ ... ] > @@ -493,26 +502,33 @@ static void vdec_stop_streaming(struct vb2_queue *q) > cancel_work_sync(&sess->esparser_queue_work); [Severity: High] Can this cause an AB-BA deadlock between the V4L2 core and the workqueue? When userspace calls VIDIOC_STREAMOFF, the V4L2 core acquires the queue lock (sess->lock), then calls vdec_stop_streaming(), which calls cancel_work_sync() here. Meanwhile, the esparser_queue_all_src() workqueue loop uses scoped_guard(mutex, &sess->lock) to acquire the exact same lock. If the workqueue is active, it will block waiting for sess->lock, while vdec_stop_streaming() blocks indefinitely waiting for the workqueue to exit. > mutex_lock(&core->lock); > =20 > - vdec_poweroff(sess); > - vdec_free_canvas(sess); [ ... ] > @@ -1012,21 +1031,30 @@ static int vdec_close(struct file *file) [ ... ] > kfree(sess->priv); > sess->priv =3D NULL; > =20 > + /* Unconditionally set our local status to stopped */ > + sess->status =3D STATUS_STOPPED; > + /* Safely clear hardware ownership since we were confirmed as the owner= */ > + smp_store_release(&core->cur_sess, NULL); > + [Severity: Critical] Does this unconditionally clear the hardware ownership, even if this session doesn't own it? If session A is streaming and session B is closed, vdec_close() for session B will execute smp_store_release(&core->cur_sess, NULL) outside of the if (core->cur_sess =3D=3D sess) check. If core->cur_sess becomes NULL while session A's hardware is active, could the next hardware interrupt trigger vdec_isr() which sees !core->cur_sess and returns IRQ_HANDLED without clearing the hardware interrupt status? Since the interrupt is level-triggered, could this result in an immediate interrupt storm that hangs the CPU, and permanently leak session A's vififo_vaddr DMA buffers when session A is eventually closed? > mutex_unlock(&core->lock); > =20 > v4l2_m2m_ctx_release(sess->m2m_ctx); --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260713120840.1742= 7-1-linux.amoon@gmail.com?part=3D8