From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.fireflyinternet.com ([109.228.58.192]:57271 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752239AbeENHoj (ORCPT ); Mon, 14 May 2018 03:44:39 -0400 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT To: Lionel Landwerlin , intel-gfx@lists.freedesktop.org From: Chris Wilson In-Reply-To: <754f7720-d8c7-a934-678c-faf0a726b6e1@intel.com> Cc: "Matthew Auld" , "Joonas Lahtinen" , "Rodrigo Vivi" , "Jani Nikula" , stable@vger.kernel.org References: <20180511135602.13071-1-chris@chris-wilson.co.uk> <152604831741.14639.14005844103011393462@mail.alporthouse.com> <754f7720-d8c7-a934-678c-faf0a726b6e1@intel.com> Message-ID: <152628387266.9830.8750878283710939730@mail.alporthouse.com> Subject: Re: [PATCH] drm/i915/oa: Disable OA on Haswell Date: Mon, 14 May 2018 08:44:32 +0100 Sender: stable-owner@vger.kernel.org List-ID: Quoting Lionel Landwerlin (2018-05-11 16:43:02) > On 11/05/18 15:18, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2018-05-11 15:14:13) > >> My understanding of the virtual memory addressing from the GPU is limited... > >> But how can the GPU poke at the kernel's allocated data? > >> I thought we mapped into the GPU's address space only what is allocated > >> through gem. > > Correct. The HW should only be accessing the pages through the GTT and > > the GTT should only contain known pages (or a pointer to the scratch > > page). There is maybe a hole where we are freeing the memory before > > the HW has finished using it (still writing through stale TLB and > > whatnot even though the system has reallocated the pages), but other > > than that quite, quite scary. Hence this awooga. > > > > I managed to reproduce a kasan backtrace on the same test. > So it's not just the CI machine. For the record, CI also seems much happier with the wait for OACONTROL before unpinning, so no need to panic! -Chris