Re: high_memory address in /proc/dri/*/vma

[Ben Hutchings <ben@decadent.org.uk>]

On Tue, Dec 20, 2011 at 05:32:13PM +0100, Daniel Vetter wrote:
> On Tue, Dec 20, 2011 at 12:09:39AM +0000, Ben Hutchings wrote:
> > [Re-sent to the right address, I hope.]
> > 
> > Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
> > leak kernel addresses via /proc/dri/*/vma") you changed the logging of
> > high_memory:
> > 
> > -       seq_printf(m, "vma use count: %d, high_memory = %p, 0x%08llx\n",
> > +       seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
> >                    atomic_read(&dev->vma_count),
> > -                  high_memory, (u64)virt_to_phys(high_memory));
> > +                  high_memory, (void *)virt_to_phys(high_memory));
> > 
> > This doesn't make sense because the physical address may be truncated
> > (in theory at least).
> > 
> > I think it would make more sense to make this entire file readable by
> > root only, but I don't know whether anything depends on being able to
> > read it.  Its existence is conditional on DRM_DEBUG_CODE != 0 but that
> > is always true at the moment.
> 
> Afaik (and I've done quite some code history checking) the proc files are
> not relied upon by userspace (up to about 10 years back). Patch to kill
> them all is pending and should hit either 3.3 or 3.4.
 
Great, that'll be one more warning gone. :-)

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus