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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFF31C43381 for ; Sat, 2 Mar 2019 08:30:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BB1F62083D for ; Sat, 2 Mar 2019 08:30:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1551515456; bh=uHuq6q3Owhz6ANT8ycwp/pV8p22et87cVBby+XmpqDk=; h=Subject:To:Cc:From:Date:List-ID:From; b=KnQOWncC4XdZrMZC9YCMxusWdEX559/XKTkeE/JYdoi21BQNQ2ylY98RZNYaf0WVe jVUY20ODXs9EeHUrSGeg9VCccIffdUdAWRtsNeNtoRxRbIFNOwElVadKCBvDtx2M2O 2lU9uT2jwMP6vOguzdRXO3NLJGcZvtkEHeWHz/7s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726049AbfCBIa4 (ORCPT ); Sat, 2 Mar 2019 03:30:56 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:48693 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726044AbfCBIaz (ORCPT ); Sat, 2 Mar 2019 03:30:55 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BE08C21C82; Sat, 2 Mar 2019 03:30:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sat, 02 Mar 2019 03:30:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Dbg10w 6lZu1yZCUuQBemwNJDc4cdRGZkAf2Fr5c2xkM=; b=ODdeXtUK1pxrdVCcgYeMwG S2qhYlq0q8Zbym4afaj/YSFOX1SpKUXy0FQHGzEtpHGzuFsfMc+k/Xn/Vg5lPiB5 QwtHrnDnBrY2bkEJyZElH3VXTuZNvCUHq/2w6x8sjqqRE46VH6aUuPDdMQ2of/cT 1Vo9/mfElqhZwgpQmn9EAAdGqpQ2XS5ouCgmmuzcW4kOfrV8N+uk5pZjfyFA8Emb Q90tvlgHiIBPDX7XhmXxWVhQArU8I9bFGX43eBdPEjuPc97w0qQ+coeqh9Bp9kIF x+V8R6WMfz+N81Sr6UQLuL0VwBEtUg16FasPrpRTsurF2EJhZfYybCQ1YVAmvv5g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrvdeigdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvffhfffkgggtgfesthekredttd dtlfenucfhrhhomhepoehgrhgvghhkhheslhhinhhugihfohhunhgurghtihhonhdrohhr gheqnecuffhomhgrihhnpehfrhgvvgguvghskhhtohhprdhorhhgnecukfhppeekfedrke eirdekledruddtjeenucfrrghrrghmpehmrghilhhfrhhomhepghhrvghgsehkrhhorghh rdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (5356596b.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 29A0D1030F; Sat, 2 Mar 2019 03:30:53 -0500 (EST) Subject: FAILED: patch "[PATCH] drm: Block fb changes for async plane updates" failed to apply to 4.14-stable tree To: nicholas.kazlauskas@amd.com, airlied@redhat.com, andrey.grodzovsky@amd.com, daniel.vetter@ffwll.ch, daniel@ffwll.ch, harry.wentland@amd.com, stable@vger.kernel.org Cc: From: Date: Sat, 02 Mar 2019 09:30:51 +0100 Message-ID: <15515154512883@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2216322919c8608a448d7ebc560a845238a5d6b6 Mon Sep 17 00:00:00 2001 From: Nicholas Kazlauskas Date: Mon, 7 Jan 2019 12:41:46 -0500 Subject: [PATCH] drm: Block fb changes for async plane updates The prepare_fb call always happens on new_plane_state. The drm_atomic_helper_cleanup_planes checks to see if plane state pointer has changed when deciding to call cleanup_fb on either the new_plane_state or the old_plane_state. For a non-async atomic commit the state pointer is swapped, so this helper calls prepare_fb on the new_plane_state and cleanup_fb on the old_plane_state. This makes sense, since we want to prepare the framebuffer we are going to use and cleanup the the framebuffer we are no longer using. For the async atomic update helpers this differs. The async atomic update helpers perform in-place updates on the existing state. They call drm_atomic_helper_cleanup_planes but the state pointer is not swapped. This means that prepare_fb is called on the new_plane_state and cleanup_fb is called on the new_plane_state (not the old). In the case where old_plane_state->fb == new_plane_state->fb then there should be no behavioral difference between an async update and a non-async commit. But there are issues that arise when old_plane_state->fb != new_plane_state->fb. The first is that the new_plane_state->fb is immediately cleaned up after it has been prepared, so we're using a fb that we shouldn't be. The second occurs during a sequence of async atomic updates and non-async regular atomic commits. Suppose there are two framebuffers being interleaved in a double-buffering scenario, fb1 and fb2: - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1 - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2 - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 We call cleanup_fb on fb2 twice in this example scenario, and any further use will result in use-after-free. The simple fix to this problem is to block framebuffer changes in the drm_atomic_helper_async_check function for now. v2: Move check by itself, add a FIXME (Daniel) Cc: Daniel Vetter Cc: Harry Wentland Cc: Andrey Grodzovsky Cc: # v4.14+ Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane update") Signed-off-by: Nicholas Kazlauskas Acked-by: Andrey Grodzovsky Acked-by: Harry Wentland Reviewed-by: Daniel Vetter Signed-off-by: Harry Wentland Link: https://patchwork.freedesktop.org/patch/275364/ Signed-off-by: Dave Airlie diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 54e2ae614dcc..f4290f6b0c38 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1602,6 +1602,15 @@ int drm_atomic_helper_async_check(struct drm_device *dev, old_plane_state->crtc != new_plane_state->crtc) return -EINVAL; + /* + * FIXME: Since prepare_fb and cleanup_fb are always called on + * the new_plane_state for async updates we need to block framebuffer + * changes. This prevents use of a fb that's been cleaned up and + * double cleanups from occuring. + */ + if (old_plane_state->fb != new_plane_state->fb) + return -EINVAL; + funcs = plane->helper_private; if (!funcs->atomic_async_update) return -EINVAL;