dri-devel April 2012

dri-devel@lists.freedesktop.org

119 participants
668 discussions

[PATCH] drm/savage: fix integer overflows in savage_bci_cmdbuf()
by Xi Wang 06 Apr '12

06 Apr '12

Since cmdbuf->size and cmdbuf->nbox are from userspace, a large value would overflow the allocation size, leading to out-of-bounds access. Signed-off-by: Xi Wang <xi.wang(a)gmail.com> --- drivers/gpu/drm/savage/savage_state.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/savage/savage_state.c b/drivers/gpu/drm/savage/savage_state.c index 031aaaf..b6d8608 100644 --- a/drivers/gpu/drm/savage/savage_state.c +++ b/drivers/gpu/drm/savage/savage_state.c @@ -988,7 +988,7 @@ int savage_bci_cmdbuf(struct drm_device *dev, void *data, struct drm_file *file_ * for locking on FreeBSD. */ if (cmdbuf->size) { - kcmd_addr = kmalloc(cmdbuf->size * 8, GFP_KERNEL); + kcmd_addr = kmalloc_array(cmdbuf->size, 8, GFP_KERNEL); if (kcmd_addr == NULL) return -ENOMEM; @@ -1015,8 +1015,8 @@ int savage_bci_cmdbuf(struct drm_device *dev, void *data, struct drm_file *file_ cmdbuf->vb_addr = kvb_addr; } if (cmdbuf->nbox) { - kbox_addr = kmalloc(cmdbuf->nbox * sizeof(struct drm_clip_rect), - GFP_KERNEL); + kbox_addr = kmalloc_array(cmdbuf->nbox, sizeof(struct drm_clip_rect), + GFP_KERNEL); if (kbox_addr == NULL) { ret = -ENOMEM; goto done; -- 1.7.5.4

1 0

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()
by Xi Wang 06 Apr '12

06 Apr '12

A large args->buffer_count from userspace may overflow the allocation size, leading to out-of-bounds access. Use kmalloc_array() to avoid that. Signed-off-by: Xi Wang <xi.wang(a)gmail.com> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index f51a696..19962bd 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1409,8 +1409,8 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data, return -EINVAL; } - exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count, - GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY); + exec2_list = kmalloc_array(args->buffer_count, sizeof(*exec2_list), + GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY); if (exec2_list == NULL) exec2_list = drm_malloc_ab(sizeof(*exec2_list), args->buffer_count); -- 1.7.5.4

2 9

[PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats
by Seung-Woo Kim 06 Apr '12

06 Apr '12

Multi buffer plane pixel formats are added as like kernel header. Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com> --- include/drm/drm_fourcc.h | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h index 85facb0..7cfd95a 100644 --- a/include/drm/drm_fourcc.h +++ b/include/drm/drm_fourcc.h @@ -107,6 +107,10 @@ #define DRM_FORMAT_NV16 fourcc_code('N', 'V', '1', '6') /* 2x1 subsampled Cr:Cb plane */ #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */ +/* 2 non contiguous plane YCbCr */ +#define DRM_FORMAT_NV12M fourcc_code('N', 'M', '1', '2') /* 2x2 subsampled Cr:Cb plane */ +#define DRM_FORMAT_NV12MT fourcc_code('T', 'M', '1', '2') /* 2x2 subsampled Cr:Cb plane 64x32 macroblocks */ + /* * 3 plane YCbCr * index 0: Y plane, [7:0] Y @@ -127,4 +131,7 @@ #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */ #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */ +/* 3 non contiguous plane YCbCr */ +#define DRM_FORMAT_YUV420M fourcc_code('Y', 'M', '1', '2') /* 2x2 subsampled Cb (1) and Cr (2) planes */ + #endif /* DRM_FOURCC_H */ -- 1.7.4.1

11 12

[Bug 36769] Sporadic corruption of hardware cursor.
by bugzilla-daemon＠freedesktop.org 06 Apr '12

06 Apr '12

https://bugs.freedesktop.org/show_bug.cgi?id=36769 Alex Deucher <agd5f(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #10 from Alex Deucher <agd5f(a)yahoo.com> 2012-04-06 06:14:08 PDT --- *** This bug has been marked as a duplicate of bug 46796 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 46796] [X800SE] Mouse cursor corruption when switching users
by bugzilla-daemon＠freedesktop.org 06 Apr '12

06 Apr '12

https://bugs.freedesktop.org/show_bug.cgi?id=46796 Alex Deucher <agd5f(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rankincj(a)googlemail.com --- Comment #16 from Alex Deucher <agd5f(a)yahoo.com> 2012-04-06 06:14:08 PDT --- *** Bug 36769 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 36769] Sporadic corruption of hardware cursor.
by bugzilla-daemon＠freedesktop.org 06 Apr '12

06 Apr '12

https://bugs.freedesktop.org/show_bug.cgi?id=36769 --- Comment #9 from Chris Rankin <rankincj(a)googlemail.com> 2012-04-06 05:10:05 PDT --- (In reply to comment #8) > If your card has more than 128M of VRAM... 256 MB, to be exact: radeon 0000:01:00.0: putting AGP V3 device into 8x mode radeon 0000:01:00.0: GTT: 256M 0xC0000000 - 0xCFFFFFFF [drm] Generation 2 PCI interface, using max accessible memory radeon 0000:01:00.0: VRAM: 256M 0x00000000E0000000 - 0x00000000EFFFFFFF (256M used) [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 444042 kiB. [TTM] Zone highmem: Available graphics memory: 1037688 kiB. [TTM] Initializing pool allocator. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 256M of GTT memory ready. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 36769] Sporadic corruption of hardware cursor.
by bugzilla-daemon＠freedesktop.org 06 Apr '12

06 Apr '12

https://bugs.freedesktop.org/show_bug.cgi?id=36769 --- Comment #8 from Michel Dänzer <michel(a)daenzer.net> 2012-04-06 04:06:42 PDT --- If your card has more than 128M of VRAM (that's just one reason why Xorg.0.log and dmesg should be attached to every bug report...), let's mark this as a duplicate of bug 46796, which has more information about the likely cause and its fix. If you ever hit it again, we can go from there. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 48304] New: r600g: text in fbterm is garbled
by bugzilla-daemon＠freedesktop.org 06 Apr '12

06 Apr '12

https://bugs.freedesktop.org/show_bug.cgi?id=48304 Bug #: 48304 Summary: r600g: text in fbterm is garbled Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: myxolmyxmyx(a)yopmail.com Created attachment 59485 --> https://bugs.freedesktop.org/attachment.cgi?id=59485 screen cap Worked for me when I used vesafb and fglrx. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 8

[Bug 36769] Sporadic corruption of hardware cursor.
by bugzilla-daemon＠freedesktop.org 06 Apr '12

06 Apr '12

https://bugs.freedesktop.org/show_bug.cgi?id=36769 --- Comment #7 from Chris Rankin <rankincj(a)googlemail.com> 2012-04-06 03:55:36 PDT --- (In reply to comment #6) > Possibly a duplicate of bug 46796. Or vice versa? > Can you try the patch there or a 3.4 kernel snapshot? I believe that this patch has now been added to both 3.2 and 3.3 stable trees too. And no, the problem hasn't reoccurred yet - but it's still early days. I never had a reliable method of triggering it in the first place, so I can only *really* be sure if it *isn't* fixed... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Re: drm: Branch 'master' - 5 commits
by Ville Syrjälä 05 Apr '12

05 Apr '12

On Tue, Apr 03, 2012 at 02:50:01PM -0700, Rob Clark wrote: > + /* just testing a limited # of formats to test single > + * and multi-planar path.. would be nice to add more.. > + */ > + if (!strcmp(p->format_str, "YUYV")) { > + pitches[0] = p->w * 2; > + offsets[0] = 0; > + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]); > + > + fill422(virtual, 0, p->w, p->h, pitches[0]); > + > + format = DRM_FORMAT_YUYV; > + } else if (!strcmp(p->format_str, "NV12")) { > + pitches[0] = p->w; > + offsets[0] = 0; > + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]); > + pitches[1] = p->w; > + offsets[1] = p->w * p->h; > + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]); > + > + fill420(virtual, virtual+offsets[1], virtual+offsets[1]+1, > + 2, 0, p->w, p->h, pitches[0]); > + > + format = DRM_FORMAT_NV12; > + } else if (!strcmp(p->format_str, "YV12")) { > + pitches[0] = p->w; > + offsets[0] = 0; > + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]); > + pitches[1] = p->w / 2; > + offsets[1] = p->w * p->h; > + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]); > + pitches[2] = p->w / 2; > + offsets[2] = offsets[1] + (p->w * p->h) / 4; > + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]); ^ Should be '2'. The kernel patch I just posted might have caught this. OTOH it might not have in case handles[2] contains uninitialized data. We should add a test that would make sure that passing an invalid bo handle for any plane would return with an error. The problem is knowing what exactly is an invalid handle since it's all driver specific. Perhaps 0xffffffff would be a reasonably safe choice. Hmm, now I wonder if 0 might actually be a valid handle for some of the current drivers... There should obviously also be a test that does use separate bos for reach plane. That should either succeed and produce the correct result, or the driver should respond with an error at least to the setplane ioctl. Whether it would allow addfb2 to succeed is a slightly more complicated matter. I suppose it could be possible that on some odd hardware some planes would support multiple bos and some would not. In which case the driver would need to allow the addfb2. -- Ville Syrjälä syrjala(a)sci.fi http://www.sci.fi/~syrjala/ ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

2 2

← Newer
1
...
60
61
62
63
64
65
66
67
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2012