On Tue, Oct 03, 2017 at 09:38:11AM -0600, Jordan Crouse wrote:
drm_gem_get_pages() and drm_gem_put_pages() calculate the number of pages to operate on from obj->size which is a size_t. Use similarly sized variables to calculate and iterate through the pages to avoid possibly losing bits from the page calculation.
Signed-off-by: Jordan Crouse jcrouse@codeaurora.org
Not sure it wouldn't be better to move over to u64? In theory you could have a gpu with huge amounts of vram on a 32bit kernel, like PAE.
There's also rough consensus that size_t is just an all-around evil type for anything :-)
Still an issue of course, just probably with a differen (and likely more invasive) fix. -Daniel
drivers/gpu/drm/drm_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index af62017..a8c146d 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -550,7 +550,7 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj) { struct address_space *mapping; struct page *p, **pages;
- int i, npages;
size_t i, npages;
/* This is the shared memory object that backs the GEM resource */ mapping = obj->filp->f_mapping;
@@ -603,7 +603,7 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj) void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages, bool dirty, bool accessed) {
- int i, npages;
size_t i, npages;
/* We already BUG_ON() for non-page-aligned sizes in
- drm_gem_object_init(), so we should never hit this unless
-- 1.9.1
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel