high_memory address in /proc/dri/*/vma
Ben Hutchings
ben at decadent.org.uk
Tue Dec 20 11:03:54 PST 2011
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
More information about the dri-devel
mailing list