From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from cstnet.cn (smtp25.cstnet.cn [159.226.251.25]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B68483E3150 for ; Wed, 22 Jul 2026 04:09:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.226.251.25 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784693395; cv=none; b=B39vpLvaSM4lOwgpW5GYmmYWtB+I7vtsTgEzai77GPEHiAtU+WycLLSbeSb6DYauvCjpeB/dfo7py7qJaKORvPygWgoGGCK+u77U4dRLbSgsHFJD2tr6lne2x42enEA7Wg2VDFWlfx8nz3nwrZxAuM2p8kN8zQVVra06zkVUa74= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784693395; c=relaxed/simple; bh=3YeoB8BBcKka/Zsxh1FugBYCl6r1EujPZltqTfu4A4Q=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=o1shNcA6PetZhjO9hxDNPkeH91BVW08/w9L5X94RHWyZYBTWWgrwClBv5nbwbb+3N2AjTq03Ei2tWe5ckxQdkghSecjmegs+ret3hdC1j1GZ7fsuR8yPnSuVKtbUdI4O2VTi5/a7V+0LDYqRzIitzYtB3YrIWMW0qi56EuIFpSI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn; spf=pass smtp.mailfrom=iscas.ac.cn; arc=none smtp.client-ip=159.226.251.25 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iscas.ac.cn Received: from localhost.localdomain (unknown [111.196.245.140]) by APP-05 (Coremail) with SMTP id zQCowAC36EKGQmBqgwy7AA--.34747S2; Wed, 22 Jul 2026 12:09:43 +0800 (CST) From: Pengpeng Hou To: Frank Binns , Matt Coster Cc: Sarah Walker , Donald Robson , Boris Brezillon , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Pengpeng Hou Subject: [RFC] drm/pvr: define oversized freelist reconstruction handling Date: Wed, 22 Jul 2026 12:09:42 +0800 Message-ID: <20260722040942.85459-1-pengpeng@iscas.ac.cn> X-Mailer: git-send-email 2.50.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:zQCowAC36EKGQmBqgwy7AA--.34747S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Cw15ZFyxGw1UCr13AF45Awb_yoW8Xw4UpF 4kAa1Ykw4kWw4rG3s7C3y7uFyFkrZakFW3GF98ta4qyr90yrs2yFWIkw12qFyDAFZFvw12 qFnFgrWUuF15Za7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Y14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r1I6r4UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVWxJr 0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E 2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2 Y2ka0xkIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWU CwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCT nIWIevJa73UjIFyTuYvjfUoWlkDUUUU X-CM-SenderInfo: pshqw1xhqjqxpvfd2hldfou0/ pvr_free_list_process_reconstruct_req() receives a reconstruction count from firmware and uses it to iterate the request ID array and populate the response ID array. Both arrays have ROGUE_FWIF_MAX_FREELISTS_TO_RECONSTRUCT entries, but the count is not checked against that limit. An oversized count would therefore make the loop and memcpy() access past the fixed protocol objects. The bounds issue is clear, but I could not find an ABI-defined completion for a malformed whole request. In particular, clamping does not appear justified. It changes the response count and silently omits IDs that firmware claims to have supplied. Dropping the request may leave firmware waiting for the reconstruction update, while echoing the original count cannot be represented safely in the fixed response. For comparison, the older Imagination host implementation also assumes a valid count, processes that many entries and echoes the count in the update: https://android.googlesource.com/kernel/mediatek/+/android-mtk-3.18/drivers/staging/imgtec/rogue/rgxta3d.c#710 The current ABI provides a per-freelist reconstruction-failed flag, but no whole-request error value for an invalid count. What is the intended recovery when firmware supplies a count above the protocol maximum? Should the driver treat it as a firmware-fatal condition, complete a bounded subset, or use another firmware-defined response? Once that contract is clear, I can prepare a narrow patch without inventing new firmware semantics.