Re: [PATCH 17/25] drm: rip out drm_core_has_MTRR checks

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Fri, Aug 9, 2013 at 8:39 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Fri, Aug 9, 2013 at 11:36 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>>>> The new arch_phys_wc_add/del functions do the right thing both with
>>>> and without MTRR support in the kernel. So we can drop these
>>>> additional checks.
>>>
>>> If any of the new arch_phys_wc_add calls are reachable and if the
>>> driver calls arch_phys_wc_add itself, then the lack of refcounting on
>>> non-PAT systems may cause a problem.  (I don't understand the drm
>>> stuff well enough to know whether that can actually happen.)
>>
>> This is only about compile-time options really. Somehow drm had the
>> idea to use these check functions instead of #ifdef plus dummy static
>> inline noop functions. David Herrmann just did the same patch for the
>> agp stuff. So refcounting is of no concern here.
>
> I feel like I'm missing something obvious here.  On nouveau, prior to
> this patch, the drm maps code would not touch mtrrs.  Now it will.
> Nouveau already calls arch_phys_wc_add, so if that maps code is
> reached on the same resource, then there could be refcounting issues.

Oh that kind of confusion. The maps code here is for old userspace
drivers, I have some patches in the queue that will disable it
properly for kms drivers. So it should never happen that both the kms
driver and the maps code in the drm core set up a mtrr mapping. And if
it happens someone is doing something really nasty, and that hole will
soon be plugged.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch