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 9706DC43458 for ; Mon, 13 Jul 2026 12:46:47 +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=OzuNKuB8WOXNt5m0tr4jnIITMPybu5wwpM7u4SbDZ5s=; b=L8sR+ps4rEFVCB WmS3lnwtWPoeCXIn904Vxmi2OaWFg3NYo3RBE5rF78bGkThgZweIuIkroOAyfjchTQz9vb1rC4KLH OZk/vJLveRO0zQFXpZcDQPr0FqWGg5q+4sJ1yKjK4VcSF/2Ao0YodQfScxofO2NecaA62iRweJxta Xm5eMt0gijVNGWgUtfhjcPgGqVgANtbjVkdHw4O/hA8XGCj9zgODRnjqBlGeESAWpQCq0E0i2VPuk 0SWkgUs6YRuIJANpLTRxxFHYHMBLwJZoGjmareV4Dc4kHQEfid+SOYcfURfXWwuc+AsWp58FPxbY8 DpR8+apWVj2prpJMyL6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjG3X-00000009EEu-0G2P; Mon, 13 Jul 2026 12:46:43 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjG3V-00000009EEk-2a1n for linux-amlogic@lists.infradead.org; Mon, 13 Jul 2026 12:46:41 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 2DA2140A8D; Mon, 13 Jul 2026 12:46:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDAE71F000E9; Mon, 13 Jul 2026 12:46:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783946801; bh=5qp4cB28UsZKGHNVhMCm/1kfvcwCj7c2iWrRp/RkMyc=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=MjHezeNR8aDJFQXD+LYaTJEEHFUxCWP2HlFAlRSf6lAk035xOu58EPgx942BBLA8I 3TavJA7Z/asNzkWmbqEj/jBRyWuqUfSpfc3zUsR0JpmDE5rLZEm5ZzKLZ+g7mOIHTm 9RN9IespmO+eFmfLPA8CCeOPXi0YoqzkTWjPTSAsQRX7pDX12rFce9Zj+9+2MtO1hU M0W5gNlKJ3tnfUrdGBu3XibexmgYiVT0Pb0HrxtEKrd5qIDBXUPXbqpjEbXjrIjjY8 wUW6jL5VarNGYry/Lqg3qsofsz2i5w+DcRe/YuCLMBL1FUvUgy3FifPyVma69vDyAS pTuUrTfWoZ6XA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 10/19] media: meson: vdec: Fix race conditions and leaks in esparser pipeline To: "Anand Moon" Cc: dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org In-Reply-To: <20260713120840.17427-11-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-11-linux.amoon@gmail.com> Date: Mon, 13 Jul 2026 12:46:40 +0000 Message-Id: <20260713124640.CDAE71F000E9@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 OCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBJ bmZpbml0ZSBsb29wIGFuZCBDUFUgc29mdC1sb2NrdXAgaW4gYGVzcGFyc2VyX3F1ZXVlX2FsbF9z cmNgIGR1ZSB0byBpbnZlcnRlZCBgcHJvY2Vzc2VkX2ZyYW1lYCBsb2dpYy4KLSBbSGlnaF0gU2Vs Zi1kZWFkbG9jayBpbiBgdmRlY19zdGFydF9zdHJlYW1pbmdgIGFuZCBgdmRlY19zdG9wX3N0cmVh bWluZ2AgZHVlIHRvIHJlY3Vyc2l2ZSBhY3F1aXNpdGlvbiBvZiBgY29yZS0+bG9ja2AuCi0gW0hp Z2hdIEFCLUJBIGRlYWRsb2NrIGluIGB2ZGVjX3N0b3Bfc3RyZWFtaW5nYCBjYXVzZWQgYnkgY2Fs bGluZyBgY2FuY2VsX3dvcmtfc3luY2Agd2hpbGUgaG9sZGluZyBgc2Vzcy0+bG9ja2AuCi0gW0hp Z2hdIEFCLUJBIGxvY2sgaW52ZXJzaW9uIGRlYWRsb2NrIGJldHdlZW4gYGNvcmUtPmxvY2tgIGFu ZCBgc2Vzcy0+bG9ja2AgaW4gdGhlIGVzcGFyc2VyIHdvcmtxdWV1ZS4KLSBbSGlnaF0gU3lzdGVt LXdpZGUgVjRMMiBzdGFsbCBkdWUgdG8gc2xlZXBpbmcgZm9yIHVwIHRvIDIwMG1zIHdoaWxlIGhv bGRpbmcgdGhlIGRyaXZlci13aWRlIGBjb3JlLT5sb2NrYC4KLSBbSGlnaF0gU2lsZW50IG9taXNz aW9uIG9mIHN0YXJ0IGNvZGUgcGFkZGluZyBmb3IgdW5tYXBwZWQgYnVmZmVycyBsZWFkcyB0byBo YXJkd2FyZSBvdXQtb2YtYm91bmRzIERNQS4KClByZS1leGlzdGluZyBpc3N1ZXM6Ci0gW0NyaXRp Y2FsXSBJbnRlZ2VyIG92ZXJmbG93IGluIGB2cDlfdXBkYXRlX2hlYWRlcmAgYWxsb3dzIG1hc3Np dmUgb3V0LW9mLWJvdW5kcyBoZWFwIGNvcnJ1cHRpb24gZnJvbSB1bnRydXN0ZWQgcGF5bG9hZCBk YXRhLgotIFtIaWdoXSBgZXNwYXJzZXJfcGFkX3N0YXJ0X2NvZGVgIGV4ZWN1dGVzIGFuIG91dC1v Zi1ib3VuZHMgbWVtb3J5IHdyaXRlIGJlZm9yZSBldmFsdWF0aW5nIGJvdW5kcyBjaGVja3MuCi0t CgotLS0gUGF0Y2ggWzEwXTogW1BBVENIIHY3IDEwLzE5XSBtZWRpYTogbWVzb246IHZkZWM6IEZp eCByYWNlIGNvbmRpdGlvbnMgYW5kIGxlYWtzIGluIGVzcGFyc2VyIHBpcGVsaW5lIC0tLQpjb21t aXQgZjk3ODE2NWUyZWY5NjdlYzNmMjA3YzgwMzEwZDQ3NGVmZWUzYzllOApBdXRob3I6IEFuYW5k IE1vb24gPGxpbnV4LmFtb29uQGdtYWlsLmNvbT4KU3ViamVjdDogbWVkaWE6IG1lc29uOiB2ZGVj OiBGaXggcmFjZSBjb25kaXRpb25zIGFuZCBsZWFrcyBpbiBlc3BhcnNlciBwaXBlbGluZQoKVGhp cyBjb21taXQgZml4ZXMgYSBjaXJjdWxhciBsb2NraW5nIGRlcGVuZGVuY3kgYW5kIHBvdGVudGlh bCByYWNlIGNvbmRpdGlvbnMKd2l0aGluIHRoZSBhc3luY2hyb25vdXMgZXNwYXJzZXIgcXVldWUu IEl0IG1vdmVzIGhhcmR3YXJlIG93bmVyc2hpcCB2YWxpZGF0aW9uCmluc2lkZSB0aGUgY29yZS0+ bG9jayBtdXRleCByZWdpb24gYW5kIHByb3Blcmx5IGNsZWFucyB1cCB0aW1lc3RhbXAgdHJhY2tl cnMuClRoZSBWUDkgcGF5bG9hZCBldmFsdWF0aW9uIGxvZ2ljIGlzIGFsc28gcmVmaW5lZC4KCj4g ZGlmZiAtLWdpdCBhL2RyaXZlcnMvc3RhZ2luZy9tZWRpYS9tZXNvbi92ZGVjL2VzcGFyc2VyLmMg Yi9kcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5jCj4gaW5kZXggZWRi ZmM4MjllMmRhOC4uYjlmMzZmZWY0YmUxMiAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL3N0YWdpbmcv bWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5jCj4gKysrIGIvZHJpdmVycy9zdGFnaW5nL21lZGlh L21lc29uL3ZkZWMvZXNwYXJzZXIuYwo+IEBAIC0xOTksMTIgKzE5OSwxNiBAQCBzdGF0aWMgaW50 IHZwOV91cGRhdGVfaGVhZGVyKHN0cnVjdCBhbXZkZWNfY29yZSAqY29yZSwgc3RydWN0IHZiMl9i dWZmZXIgKmJ1ZikKPiAgICogdGhlIEVTUEFSU0VSIGludGVycnVwdC4KPiAgICovCj4gIHN0YXRp YyB1MzIgZXNwYXJzZXJfcGFkX3N0YXJ0X2NvZGUoc3RydWN0IGFtdmRlY19jb3JlICpjb3JlLAo+ ICsJCQkJICAgc3RydWN0IGFtdmRlY19zZXNzaW9uICpzZXNzLAo+ICAJCQkJICAgc3RydWN0IHZi Ml9idWZmZXIgKnZiLAo+ICAJCQkJICAgdTMyIHBheWxvYWRfc2l6ZSkKPiAgewo+ICAJdTMyIHBh ZF9zaXplID0gMDsKPiAgCXU4ICp2YWRkciA9IHZiMl9wbGFuZV92YWRkcih2YiwgMCk7Cj4gIAo+ ICsJaWYgKCFzZXNzIHx8IFJFQURfT05DRShzZXNzLT5zaG91bGRfc3RvcCkgfHwgIXNlc3MtPnBy aXYgfHwgIXZhZGRyKQo+ICsJCXJldHVybiAwOwoKW1NldmVyaXR5OiBIaWdoXQpEb2VzIHJldHVy bmluZyAwIGhlcmUgc2tpcCB0aGUgc3RhcnQgY29kZSBpbmplY3Rpb24gYW5kIGNhdXNlIGFuCm91 dC1vZi1ib3VuZHMgRE1BIHNjYW4/CgpCeSBieXBhc3NpbmcgdGhlIGluamVjdGlvbiBvZiB0aGUg U0VBUkNIX1BBVFRFUk4gc3RhcnQgY29kZSwgdGhlIGNhbGxlcgplc3BhcnNlcl9xdWV1ZSgpIG1p Z2h0IGludGVycHJldCB0aGUgMCBhcyBzdWNjZXNzIGFuZCBpbnN0cnVjdCB0aGUgRE1BCmVuZ2lu ZSB0byBmZXRjaCB0aGUgYnVmZmVyLiAKClNpbmNlIHRoZSBzZWFyY2ggcGF0dGVybiBpcyBtaXNz aW5nLCBjb3VsZCB0aGUgaGFyZHdhcmUgcGFyc2VyIHNjYW4KaW5kZWZpbml0ZWx5IHBhc3QgdGhl IHZhbGlkIGJ1ZmZlciBpbnRvIGFkamFjZW50IHBoeXNpY2FsIG1lbW9yeSwgcmVzdWx0aW5nCmlu IGFuIG91dC1vZi1ib3VuZHMgRE1BIHJlYWQ/Cgo+ICAJaWYgKHBheWxvYWRfc2l6ZSA8IEVTUEFS U0VSX01JTl9QQUNLRVRfU0laRSkgewo+ICAJCXBhZF9zaXplID0gRVNQQVJTRVJfTUlOX1BBQ0tF VF9TSVpFIC0gcGF5bG9hZF9zaXplOwo+ICAJCW1lbXNldCh2YWRkciArIHBheWxvYWRfc2l6ZSwg MCwgcGFkX3NpemUpOwo+ICAJfQoKW1NldmVyaXR5OiBIaWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0 aW5nIGlzc3VlLCBidXQgZG9lcyB0aGlzIG1lbXNldCgpIHdyaXRlIG91dCBvZiBib3VuZHM/CgpJ ZiBhIHNtYWxsIGJ1ZmZlciBpcyBxdWV1ZWQsIHRoaXMgY2FsY3VsYXRpb24gZXhlY3V0ZXMgYmVm b3JlIHRoZQpvdmVyYWxsIGJvdW5kcyBjaGVjayBpcyBldmFsdWF0ZWQuIAoKQ291bGQgdGhpcyBv dmVyd3JpdGUgYWRqYWNlbnQga2VybmVsIG1lbW9yeSB3aXRoIHplcm9lcyBiZWZvcmUgdmFsaWRh dGluZyAKdGhlIHNpemU/CgpbIC4uLiBdCgo+IEBAIC0zNDksMjQgKzM1NiwzOCBAQCBlc3BhcnNl cl9xdWV1ZShzdHJ1Y3QgYW12ZGVjX3Nlc3Npb24gKnNlc3MsIHN0cnVjdCB2YjJfdjRsMl9idWZm ZXIgKnZidWYpCj4gIAl2YnVmLT5zZXF1ZW5jZSA9IHNlc3MtPnNlcXVlbmNlX291dCsrOwo+ICAK PiAgCWlmIChzZXNzLT5mbXRfb3V0LT5waXhmbXQgPT0gVjRMMl9QSVhfRk1UX1ZQOSkgewo+IC0J CXBheWxvYWRfc2l6ZSA9IHZwOV91cGRhdGVfaGVhZGVyKGNvcmUsIHZiKTsKPiArCQlpbnQgcmVz ID0gdnA5X3VwZGF0ZV9oZWFkZXIoY29yZSwgdmIpOwoKW1NldmVyaXR5OiBDcml0aWNhbF0KVGhp cyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGRvZXMgdnA5X3VwZGF0ZV9oZWFkZXIoKSBo YXZlIGFuIGludGVnZXIKb3ZlcmZsb3c/CgpCeSBleHRyYWN0aW5nIHVudHJ1c3RlZCBwYXlsb2Fk IGJ5dGVzIGFuZCBzaGlmdGluZyB0aGVtIGxlZnQgdXAgdG8gMjQgYml0cwppbnRvIGEgc2lnbmVk IGludGVnZXIsIGNhbiBtYWxpY2lvdXMgcGF5bG9hZHMgY29uc3RydWN0IG5lZ2F0aXZlIGZyYW1l IHNpemVzPwoKSWYgYSBoaWdobHkgbmVnYXRpdmUgc2lnbmVkIGludGVnZXIgaXMgcHJvZHVjZWQg YW5kIHBhc3NlZCB0byBtZW1tb3ZlKCkgYXMgYW4KdW5zaWduZWQgc2l6ZV90LCBjb3VsZCB0aGlz IGNhdXNlIG1hc3NpdmUgb3V0LW9mLWJvdW5kcyByZWFkcyBhbmQgd3JpdGVzIG9uCnRoZSBrZXJu ZWwgaGVhcCBvciBETUEgbWVtb3J5PwoKPiAgCj4gLQkJaWYgKHBheWxvYWRfc2l6ZSA9PSAwKSB7 Cj4gLQkJCWRldl9lcnIoY29yZS0+ZGV2LCAiZXNwYXJzZXI6IFZQOSBoZWFkZXIgdXBkYXRlIGZh aWxlZFxuIik7Cj4gKwkJaWYgKHJlcyA8PSAwKSB7Cj4gKwkJCWRldl9lcnIoY29yZS0+ZGV2LAo+ ICsJCQkJImVzcGFyc2VyOiBWUDkgaGVhZGVyIHVwZGF0ZSBmYWlsZWQgKCVkKVxuIiwKPiArCQkJ CXJlcyk7Cj4gIAkJCWFtdmRlY19yZW1vdmVfdHMoc2VzcywgdmItPnRpbWVzdGFtcCk7Cj4gIAkJ CXJldHVybiAtRUJBRE1TRzsKPiAgCQl9Cj4gKwkJcGF5bG9hZF9zaXplID0gcmVzOwo+ICsJfQo+ ICsKPiArCXBhZF9zaXplID0gZXNwYXJzZXJfcGFkX3N0YXJ0X2NvZGUoY29yZSwgc2VzcywgdmIs IHBheWxvYWRfc2l6ZSk7Cj4gKwo+ICsJLyogUHJvdGVjdCBoYXJkd2FyZSByZWdpc3RlciB3cml0 ZXMgdW5kZXIgY29yZS0+bG9jayAqLwo+ICsJbXV0ZXhfbG9jaygmY29yZS0+bG9jayk7CgpbU2V2 ZXJpdHk6IEhpZ2hdCkRvZXMgdGhpcyBuZXcgbXV0ZXhfbG9jaygpIGludHJvZHVjZSBhbiBBQi1C QSBsb2NrIGludmVyc2lvbj8KClRoZSBiYWNrZ3JvdW5kIHdvcmtxdWV1ZSB0aHJlYWQgZXNwYXJz ZXJfcXVldWVfYWxsX3NyYygpIGFjcXVpcmVzIHNlc3MtPmxvY2sgCmZpcnN0ICh2aWEgc2NvcGVk X2d1YXJkKSBhbmQgdGhlbiBjYWxscyBlc3BhcnNlcl9xdWV1ZSgpLiAKCkJ5IGFkZGluZyBtdXRl eF9sb2NrKCZjb3JlLT5sb2NrKSBoZXJlLCBjb3VsZCB0aGlzIGNvbmZsaWN0IHdpdGggVjRMMiBp b2N0bHMKdGhhdCBpbXBsaWNpdGx5IGFjcXVpcmUgY29yZS0+bG9jayBiZWZvcmUgc2Vzcy0+bG9j aywgcmVzdWx0aW5nIGluIGFuIEFCLUJBCmRlYWRsb2NrPwoKPiArCWlmIChjb3JlLT5jdXJfc2Vz cyAhPSBzZXNzIHx8IFJFQURfT05DRShzZXNzLT5zaG91bGRfc3RvcCkpIHsKPiArCQltdXRleF91 bmxvY2soJmNvcmUtPmxvY2spOwo+ICsJCWFtdmRlY19yZW1vdmVfdHMoc2VzcywgdmItPnRpbWVz dGFtcCk7Cj4gKwkJcmV0dXJuIC1FU0hVVERPV047Cj4gIAl9Cj4gIAo+IC0JcGFkX3NpemUgPSBl c3BhcnNlcl9wYWRfc3RhcnRfY29kZShjb3JlLCB2YiwgcGF5bG9hZF9zaXplKTsKPiAgCXJldCA9 IGVzcGFyc2VyX3dyaXRlX2RhdGEoY29yZSwgcGh5LCBwYXlsb2FkX3NpemUgKyBwYWRfc2l6ZSk7 CgpbU2V2ZXJpdHk6IEhpZ2hdCkNvdWxkIHNsZWVwaW5nIGluc2lkZSBlc3BhcnNlcl93cml0ZV9k YXRhKCkgYmxvY2sgYWxsIG90aGVyIFY0TDIgaW9jdGxzPwoKQmVjYXVzZSBjb3JlLT5sb2NrIGlz IG1hcHBlZCB0byB2ZGV2LT5sb2NrLCBzbGVlcGluZyB2aWEgCndhaXRfZXZlbnRfaW50ZXJydXB0 aWJsZV90aW1lb3V0KCkgd2hpbGUgd2FpdGluZyBmb3IgdGhlIGhhcmR3YXJlIGludGVycnVwdCAK YmxvY2tzIGFsbCBvdGhlciBWNEwyIGlvY3RscyBhY3Jvc3MgdGhlIGVudGlyZSBkZXZpY2UgZm9y IHRoZSBkdXJhdGlvbiBvZiAKdGhlIGZldGNoLiAKCkNhbiB0aGlzIHNldmVyZWx5IGRlZ3JhZGUg c3lzdGVtIHBlcmZvcm1hbmNlPwoKPiAgCj4gIAlpZiAocmV0IDw9IDApIHsKPiAgCQlkZXZfd2Fy bihjb3JlLT5kZXYsICJlc3BhcnNlcjogaW5wdXQgcGFyc2luZyBlcnJvclxuIik7Cj4gIAkJYW12 ZGVjX3JlbW92ZV90cyhzZXNzLCB2Yi0+dGltZXN0YW1wKTsKPiAgCQlhbXZkZWNfd3JpdGVfcGFy c2VyKGNvcmUsIFBBUlNFUl9GRVRDSF9DTUQsIDApOwo+ICsJCW11dGV4X3VubG9jaygmY29yZS0+ bG9jayk7Cj4gIAkJcmV0dXJuIC1FSU87Cj4gIAl9Cj4gKwltdXRleF91bmxvY2soJmNvcmUtPmxv Y2spOwo+ICAKPiAgCWF0b21pY19pbmMoJnNlc3MtPmVzcGFyc2VyX3F1ZXVlZF9idWZzKTsKPiAg CgpJIGFsc28gaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCByZWxhdGVkIGNvZGUgcGF0aHMgb3V0 c2lkZSB0aGUgZGlmZjoKCltTZXZlcml0eTogSGlnaF0KSXMgdGhlcmUgYW4gaW5maW5pdGUgbG9v cCBpbiBlc3BhcnNlcl9xdWV1ZV9hbGxfc3JjKCk/CgpXaGVuIGxvb2tpbmcgYXQgdGhlIHdvcmtl ciB0aHJlYWQ6Cgpkcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5jOmVz cGFyc2VyX3F1ZXVlX2FsbF9zcmMoKSB7CiAgICAuLi4KCQlib29sIHByb2Nlc3NlZF9mcmFtZSA9 IGZhbHNlOwogICAgICAgIC4uLgoJCWlmIChwcm9jZXNzZWRfZnJhbWUpCgkJCWJyZWFrOwogICAg Li4uCn0KCkJlY2F1c2UgdGhlIGJyZWFrIHN0YXRlbWVudHMgaW5zaWRlIHRoZSBzY29wZWRfZ3Vh cmQgbWFjcm8gb25seSBleGl0IHRoZSAKaW50ZXJuYWwgbWFjcm8gbG9vcCwgcHJvY2Vzc2VkX2Zy YW1lIHJlbWFpbnMgZmFsc2Ugd2hlbiB0aGUgcXVldWUgaXMgZW1wdHkuIAoKRG9lcyB0aGUgaW52 ZXJ0ZWQgbG9naWMgY2F1c2UgdGhlIHRocmVhZCB0byBieXBhc3MgdGhlIG91dGVyIGJyZWFrIGFu ZCBsb29wIAppbmZpbml0ZWx5LCBzb2Z0LWxvY2tpbmcgdGhlIENQVT8KCltTZXZlcml0eTogSGln aF0KRG8gdmRlY19zdGFydF9zdHJlYW1pbmcoKSBhbmQgdmRlY19zdG9wX3N0cmVhbWluZygpIHNl bGYtZGVhZGxvY2s/CgpJbiB0aGUgY3VycmVudCBjb2RlOgoKZHJpdmVycy9zdGFnaW5nL21lZGlh L21lc29uL3ZkZWMvdmRlYy5jOnZkZWNfc3RhcnRfc3RyZWFtaW5nKCkgewogICAgLi4uCgltdXRl eF9sb2NrKCZjb3JlLT5sb2NrKTsKICAgIC4uLgp9CgpCZWNhdXNlIHRoZSBkZXZpY2UncyB2ZGV2 LT5sb2NrIGlzIG1hcHBlZCBkaXJlY3RseSB0byAmY29yZS0+bG9jaywgdGhlIFY0TDIgCmNvcmUg ZnJhbWV3b3JrIGF1dG9tYXRpY2FsbHkgYWNxdWlyZXMgaXQgYmVmb3JlIGRpc3BhdGNoaW5nIHN0 YW5kYXJkIGlvY3Rscy4gCgpEb2VzIGV4cGxpY2l0bHkgY2FsbGluZyBtdXRleF9sb2NrKCZjb3Jl LT5sb2NrKSBpbnNpZGUgdGhlc2UgY2FsbGJhY2tzIApyZXN1bHQgaW4gYSBwZXJtYW5lbnQgc2Vs Zi1kZWFkbG9jaz8KCltTZXZlcml0eTogSGlnaF0KSXMgdGhlcmUgYW4gQUItQkEgZGVhZGxvY2sg ZHVyaW5nIHN0cmVhbSB0ZWFyZG93bj8KCkR1cmluZyBzdHJlYW1vZmY6Cgpkcml2ZXJzL3N0YWdp bmcvbWVkaWEvbWVzb24vdmRlYy92ZGVjLmM6dmRlY19zdG9wX3N0cmVhbWluZygpIHsKICAgIC4u LgoJCWNhbmNlbF93b3JrX3N5bmMoJnNlc3MtPmVzcGFyc2VyX3F1ZXVlX3dvcmspOwogICAgLi4u Cn0KClRoZSBpb2N0bCB0aHJlYWQgYWNxdWlyZXMgc2Vzcy0+bG9jayBiZWZvcmUgaW52b2tpbmcg dGhpcyBjYWxsYmFjay4gCkNvbmN1cnJlbnRseSwgdGhlIGJhY2tncm91bmQgd29ya3F1ZXVlIHRo cmVhZCBlc3BhcnNlcl9xdWV1ZV9hbGxfc3JjKCkgCmJsb2NrcyB3YWl0aW5nIGZvciBzZXNzLT5s b2NrLiAKCkRvZXMgY2FsbGluZyBjYW5jZWxfd29ya19zeW5jKCkgaGVyZSBjYXVzZSB0aGUgaW9j dGwgdGhyZWFkIHRvIGJsb2NrIGZvcmV2ZXIgCndhaXRpbmcgZm9yIHRoZSB3b3JrZXIgdGhyZWFk LCByZXN1bHRpbmcgaW4gYW4gQUItQkEgZGVhZGxvY2s/CgotLSAKU2FzaGlrbyBBSSByZXZpZXcg wrcgaHR0cHM6Ly9zYXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYwNzEzMTIwODQwLjE3NDI3LTEt bGludXguYW1vb25AZ21haWwuY29tP3BhcnQ9MTAKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFtbG9naWMgbWFpbGluZyBsaXN0CmxpbnV4LWFt bG9naWNAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xpbnV4LWFtbG9naWMK 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 C1649C43458 for ; Mon, 13 Jul 2026 12:46:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C8D1810E09F; Mon, 13 Jul 2026 12:46:42 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="MjHezeNR"; 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 AA9AD10E09F for ; Mon, 13 Jul 2026 12:46:41 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 2DA2140A8D; Mon, 13 Jul 2026 12:46:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDAE71F000E9; Mon, 13 Jul 2026 12:46:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783946801; bh=5qp4cB28UsZKGHNVhMCm/1kfvcwCj7c2iWrRp/RkMyc=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=MjHezeNR8aDJFQXD+LYaTJEEHFUxCWP2HlFAlRSf6lAk035xOu58EPgx942BBLA8I 3TavJA7Z/asNzkWmbqEj/jBRyWuqUfSpfc3zUsR0JpmDE5rLZEm5ZzKLZ+g7mOIHTm 9RN9IespmO+eFmfLPA8CCeOPXi0YoqzkTWjPTSAsQRX7pDX12rFce9Zj+9+2MtO1hU M0W5gNlKJ3tnfUrdGBu3XibexmgYiVT0Pb0HrxtEKrd5qIDBXUPXbqpjEbXjrIjjY8 wUW6jL5VarNGYry/Lqg3qsofsz2i5w+DcRe/YuCLMBL1FUvUgy3FifPyVma69vDyAS pTuUrTfWoZ6XA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 10/19] media: meson: vdec: Fix race conditions and leaks in esparser pipeline To: "Anand Moon" Cc: dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org In-Reply-To: <20260713120840.17427-11-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-11-linux.amoon@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2026 12:46:40 +0000 Message-Id: <20260713124640.CDAE71F000E9@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 8 potential issue(= s) to consider: New issues: - [High] Infinite loop and CPU soft-lockup in `esparser_queue_all_src` due = to inverted `processed_frame` logic. - [High] Self-deadlock in `vdec_start_streaming` and `vdec_stop_streaming` = due to recursive acquisition of `core->lock`. - [High] AB-BA deadlock in `vdec_stop_streaming` caused by calling `cancel_= work_sync` while holding `sess->lock`. - [High] AB-BA lock inversion deadlock between `core->lock` and `sess->lock= ` in the esparser workqueue. - [High] System-wide V4L2 stall due to sleeping for up to 200ms while holdi= ng the driver-wide `core->lock`. - [High] Silent omission of start code padding for unmapped buffers leads t= o hardware out-of-bounds DMA. Pre-existing issues: - [Critical] Integer overflow in `vp9_update_header` allows massive out-of-= bounds heap corruption from untrusted payload data. - [High] `esparser_pad_start_code` executes an out-of-bounds memory write b= efore evaluating bounds checks. -- --- Patch [10]: [PATCH v7 10/19] media: meson: vdec: Fix race conditions an= d leaks in esparser pipeline --- commit f978165e2ef967ec3f207c80310d474efee3c9e8 Author: Anand Moon Subject: media: meson: vdec: Fix race conditions and leaks in esparser pipe= line This commit fixes a circular locking dependency and potential race conditio= ns within the asynchronous esparser queue. It moves hardware ownership validat= ion inside the core->lock mutex region and properly cleans up timestamp tracker= s. The VP9 payload evaluation logic is also refined. > diff --git a/drivers/staging/media/meson/vdec/esparser.c b/drivers/stagin= g/media/meson/vdec/esparser.c > index edbfc829e2da8..b9f36fef4be12 100644 > --- a/drivers/staging/media/meson/vdec/esparser.c > +++ b/drivers/staging/media/meson/vdec/esparser.c > @@ -199,12 +199,16 @@ static int vp9_update_header(struct amvdec_core *co= re, struct vb2_buffer *buf) > * the ESPARSER interrupt. > */ > static u32 esparser_pad_start_code(struct amvdec_core *core, > + struct amvdec_session *sess, > struct vb2_buffer *vb, > u32 payload_size) > { > u32 pad_size =3D 0; > u8 *vaddr =3D vb2_plane_vaddr(vb, 0); > =20 > + if (!sess || READ_ONCE(sess->should_stop) || !sess->priv || !vaddr) > + return 0; [Severity: High] Does returning 0 here skip the start code injection and cause an out-of-bounds DMA scan? By bypassing the injection of the SEARCH_PATTERN start code, the caller esparser_queue() might interpret the 0 as success and instruct the DMA engine to fetch the buffer.=20 Since the search pattern is missing, could the hardware parser scan indefinitely past the valid buffer into adjacent physical memory, resulting in an out-of-bounds DMA read? > if (payload_size < ESPARSER_MIN_PACKET_SIZE) { > pad_size =3D ESPARSER_MIN_PACKET_SIZE - payload_size; > memset(vaddr + payload_size, 0, pad_size); > } [Severity: High] This is a pre-existing issue, but does this memset() write out of bounds? If a small buffer is queued, this calculation executes before the overall bounds check is evaluated.=20 Could this overwrite adjacent kernel memory with zeroes before validating=20 the size? [ ... ] > @@ -349,24 +356,38 @@ esparser_queue(struct amvdec_session *sess, struct = vb2_v4l2_buffer *vbuf) > vbuf->sequence =3D sess->sequence_out++; > =20 > if (sess->fmt_out->pixfmt =3D=3D V4L2_PIX_FMT_VP9) { > - payload_size =3D vp9_update_header(core, vb); > + int res =3D vp9_update_header(core, vb); [Severity: Critical] This is a pre-existing issue, but does vp9_update_header() have an integer overflow? By extracting untrusted payload bytes and shifting them left up to 24 bits into a signed integer, can malicious payloads construct negative frame size= s? If a highly negative signed integer is produced and passed to memmove() as = an unsigned size_t, could this cause massive out-of-bounds reads and writes on the kernel heap or DMA memory? > =20 > - if (payload_size =3D=3D 0) { > - dev_err(core->dev, "esparser: VP9 header update failed\n"); > + if (res <=3D 0) { > + dev_err(core->dev, > + "esparser: VP9 header update failed (%d)\n", > + res); > amvdec_remove_ts(sess, vb->timestamp); > return -EBADMSG; > } > + payload_size =3D res; > + } > + > + pad_size =3D esparser_pad_start_code(core, sess, vb, payload_size); > + > + /* Protect hardware register writes under core->lock */ > + mutex_lock(&core->lock); [Severity: High] Does this new mutex_lock() introduce an AB-BA lock inversion? The background workqueue thread esparser_queue_all_src() acquires sess->loc= k=20 first (via scoped_guard) and then calls esparser_queue().=20 By adding mutex_lock(&core->lock) here, could this conflict with V4L2 ioctls that implicitly acquire core->lock before sess->lock, resulting in an AB-BA deadlock? > + if (core->cur_sess !=3D sess || READ_ONCE(sess->should_stop)) { > + mutex_unlock(&core->lock); > + amvdec_remove_ts(sess, vb->timestamp); > + return -ESHUTDOWN; > } > =20 > - pad_size =3D esparser_pad_start_code(core, vb, payload_size); > ret =3D esparser_write_data(core, phy, payload_size + pad_size); [Severity: High] Could sleeping inside esparser_write_data() block all other V4L2 ioctls? Because core->lock is mapped to vdev->lock, sleeping via=20 wait_event_interruptible_timeout() while waiting for the hardware interrupt= =20 blocks all other V4L2 ioctls across the entire device for the duration of=20 the fetch.=20 Can this severely degrade system performance? > =20 > if (ret <=3D 0) { > dev_warn(core->dev, "esparser: input parsing error\n"); > amvdec_remove_ts(sess, vb->timestamp); > amvdec_write_parser(core, PARSER_FETCH_CMD, 0); > + mutex_unlock(&core->lock); > return -EIO; > } > + mutex_unlock(&core->lock); > =20 > atomic_inc(&sess->esparser_queued_bufs); > =20 I also have some questions about related code paths outside the diff: [Severity: High] Is there an infinite loop in esparser_queue_all_src()? When looking at the worker thread: drivers/staging/media/meson/vdec/esparser.c:esparser_queue_all_src() { ... bool processed_frame =3D false; ... if (processed_frame) break; ... } Because the break statements inside the scoped_guard macro only exit the=20 internal macro loop, processed_frame remains false when the queue is empty.= =20 Does the inverted logic cause the thread to bypass the outer break and loop= =20 infinitely, soft-locking the CPU? [Severity: High] Do vdec_start_streaming() and vdec_stop_streaming() self-deadlock? In the current code: drivers/staging/media/meson/vdec/vdec.c:vdec_start_streaming() { ... mutex_lock(&core->lock); ... } Because the device's vdev->lock is mapped directly to &core->lock, the V4L2= =20 core framework automatically acquires it before dispatching standard ioctls= .=20 Does explicitly calling mutex_lock(&core->lock) inside these callbacks=20 result in a permanent self-deadlock? [Severity: High] Is there an AB-BA deadlock during stream teardown? During streamoff: drivers/staging/media/meson/vdec/vdec.c:vdec_stop_streaming() { ... cancel_work_sync(&sess->esparser_queue_work); ... } The ioctl thread acquires sess->lock before invoking this callback.=20 Concurrently, the background workqueue thread esparser_queue_all_src()=20 blocks waiting for sess->lock.=20 Does calling cancel_work_sync() here cause the ioctl thread to block foreve= r=20 waiting for the worker thread, resulting in an AB-BA deadlock? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260713120840.1742= 7-1-linux.amoon@gmail.com?part=3D10