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 4E1B0C79F9E for ; Mon, 7 Sep 2026 07:04:47 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8C6E910E68C; Mon, 7 Sep 2026 07:04:46 +0000 (UTC) Received: from wxsgout04.xfusion.com (wxsgout03.xfusion.com [36.139.52.80]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4AFA710E68C for ; Mon, 7 Sep 2026 07:04:45 +0000 (UTC) Received: from wuxpheds03048.xfusion.com (unknown [10.32.143.30]) by wxsgout04.xfusion.com (SkyGuard) with ESMTPS id 4hddKb45hfzBXKbc; Mon, 7 Sep 2026 15:01:55 +0800 (CST) Received: from DESKTOP-Q8I2N5U.xfusion.com (10.82.130.100) by wuxpheds03048.xfusion.com (10.32.143.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_RSA_WITH_AES_128_CBC_SHA256) id 15.2.2562.20; Mon, 7 Sep 2026 15:04:39 +0800 From: shechenglong To: CC: , , , , Subject: Re: [PATCH] drm/client: fix restore of partially initialized client Date: Mon, 7 Sep 2026 15:04:33 +0800 Message-ID: <20260907070433.1412-1-shechenglong@xfusion.com> X-Mailer: git-send-email 2.37.1.windows.1 In-Reply-To: <20260907041237.C7E301F00A3A@smtp.kernel.org> References: <20260907041237.C7E301F00A3A@smtp.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.82.130.100] X-ClientProxiedBy: wuxpheds03047.xfusion.com (10.32.141.63) To wuxpheds03048.xfusion.com (10.32.143.30) 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: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > Could the error handling path be updated to ensure the buffer is properly > destroyed when this occurs? Thanks for pointing this out. This appears to be a pre-existing issue and is not introduced by this patch. The purpose of the current patch is limited to preventing the restore callback from dereferencing a partially initialized fbdev client. The cleanup concern looks valid. I will inspect the buffer ownership and error-unwind paths around register_framebuffer() failure. If additional cleanup is required, I will handle it separately so that the restore fix remains focused. Thanks, Chenglong She