From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fllv0016.ext.ti.com ([198.47.19.142]:37450 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728158AbeIQUTO (ORCPT ); Mon, 17 Sep 2018 16:19:14 -0400 Subject: Re: [PATCH] drm: fix use of freed memory in drm_mode_setcrtc To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= CC: , Daniel Vetter , Dave Airlie , , Benoit Parrot References: <20180917110054.4053-1-tomi.valkeinen@ti.com> <20180917144150.GN5565@intel.com> From: Tomi Valkeinen Message-ID: <18588590-0bbc-34e3-af97-690464298260@ti.com> Date: Mon, 17 Sep 2018 17:51:27 +0300 MIME-Version: 1.0 In-Reply-To: <20180917144150.GN5565@intel.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: On 17/09/18 17:41, Ville Syrjälä wrote: > On Mon, Sep 17, 2018 at 02:00:54PM +0300, Tomi Valkeinen wrote: >> drm_mode_setcrtc() retries modesetting in case one of the functions it >> calls returns -EDEADLK. connector_set, mode and fb are freed before >> retrying, but they are not set to NULL. This can cause >> drm_mode_setcrtc() to use those variables. >> >> For example: On the first try __drm_mode_set_config_internal() returns >> -EDEADLK. connector_set, mode and fb are freed. Next retry starts, and >> drm_modeset_lock_all_ctx() returns -EDEADLK, and we jump to 'out'. The >> code will happily try to release all three again. > > This thing uses lock_all() so I guess the EDEADLK must be coming from > some private locks in the driver? Yes, I've seen this cause issues only with Benoit's work-in-progress omapdrm patches. > Anyways, patch looks good so > Reviewed-by: Ville Syrjälä Thanks! Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki