diff options
author | Benjamin Herrenschmidt <benh@kernel.crashing.org> | 2009-05-17 21:56:16 -0400 |
---|---|---|
committer | Jesse Barnes <jbarnes@virtuousgeek.org> | 2009-05-19 18:35:33 -0400 |
commit | b674137755bbe2750f997a2a1264db3cdf8abcb3 (patch) | |
tree | 7f1bdc8208dada0449cbba603f7aefb2a7cd3c27 /crypto/hash.c | |
parent | 279e677faa775ad16e75c32e1bf4a37f8158bc61 (diff) |
drm: Round size of SHM maps to PAGE_SIZE
Currently, userspace can fail to obtain the SAREA mapping (among other
reasons) if it passes SAREA_MAX to drmAddMap without aligning it to the
page size. This breaks for example on PowerPC with 64K pages and radeon
despite the kernel radeon actually doing the right rouding in the first
place.
The way SAREA_MAX is defined with a bunch of ifdef's and duplicated
between libdrm and the X server is gross, ultimately it should be
retrieved by userspace from the kernel, but in the meantime, we have
plenty of existing userspace built with bad values that need to work.
This patch works around broken userspace by rounding the requested size
in drm_addmap_core() of any SHM map to the page size. Since the backing
memory for SHM maps is also allocated within addmap_core, there is no
danger of adjacent memory being exposed due to the increased map size.
The only side effect is that drivers that previously tried to create or
access SHM maps using a size < PAGE_SIZE and failed (getting -EINVAL),
will now succeed at the cost of a little bit more memory used if that
happens to be when the map is created.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Diffstat (limited to 'crypto/hash.c')
0 files changed, 0 insertions, 0 deletions