From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:47166 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752065AbcKIISb (ORCPT ); Wed, 9 Nov 2016 03:18:31 -0500 Subject: Patch "drm/fb-helper: Don't call dirty callback for untouched clips" has been added to the 4.8-stable tree To: tiwai@suse.de, daniel.vetter@ffwll.ch, gregkh@linuxfoundation.org, ville.syrjala@linux.intel.com Cc: , From: Date: Wed, 09 Nov 2016 09:18:36 +0100 Message-ID: <1478679516232141@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled drm/fb-helper: Don't call dirty callback for untouched clips to the 4.8-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: drm-fb-helper-don-t-call-dirty-callback-for-untouched-clips.patch and it can be found in the queue-4.8 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From 87d3b6588f9bf205902868d3e5baf68e37ad4ae1 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 20 Oct 2016 17:05:30 +0200 Subject: drm/fb-helper: Don't call dirty callback for untouched clips MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Takashi Iwai commit 87d3b6588f9bf205902868d3e5baf68e37ad4ae1 upstream. Since 4.7 kernel, we've seen the error messages like kernel: [TTM] Buffer eviction failed kernel: qxl 0000:00:02.0: object_init failed for (4026540032, 0x00000001) kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO on QXL when switching and accessing on VT. The culprit was the generic deferred_io code (qxl driver switched to it since 4.7). There is a race between the dirty clip update and the call of callback. In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock, while it kicks off the update worker outside the spinlock. Meanwhile the update worker clears the dirty clip in the spinlock, too. Thus, when drm_fb_helper_dirty() is called concurrently, schedule_work() is called after the clip is cleared in the first worker call. This patch addresses it by validating the clip before calling the dirty fb callback. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322 Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298 Fixes: eaa434defaca ('drm/fb-helper: Add fb_deferred_io support') Signed-off-by: Takashi Iwai Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161020150530.5787-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/drm_fb_helper.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -632,7 +632,9 @@ static void drm_fb_helper_dirty_work(str clip->x2 = clip->y2 = 0; spin_unlock_irqrestore(&helper->dirty_lock, flags); - helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1); + /* call dirty callback only when it has been really touched */ + if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) + helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1); } /** Patches currently in stable-queue which might be from tiwai@suse.de are queue-4.8/alsa-hda-adding-a-new-group-of-pin-cfg-into-alc295-pin-quirk-table.patch queue-4.8/drm-fb-helper-don-t-call-dirty-callback-for-untouched-clips.patch queue-4.8/alsa-seq-fix-time-account-regression.patch queue-4.8/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-laptops.patch queue-4.8/alsa-hda-allow-40-bit-dma-mask-for-nvidia-devices.patch queue-4.8/alsa-hda-fix-surround-output-pins-for-asrock-b150m-mobo.patch queue-4.8/alsa-usb-audio-add-quirk-for-syntek-stk1160.patch