On Fri, Aug 9, 2013 at 11:47 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > On Fri, Aug 9, 2013 at 8:39 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Fri, Aug 9, 2013 at 11:36 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: >>> On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>> On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> 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. In that case, I'm convinced. In case you care: Acked-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx> --Andy > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Andy Lutomirski AMA Capital Management, LLC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
