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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
