Re: [PATCH] drm: fix cliprects leaking in drm_rmdraw()
On Fri, 2008-10-17 at 13:16 +0800, Zhenyu Wang wrote:
From 4aab96c10fca2d5a3f89e56a4d6a96c6125cf932 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang [EMAIL PROTECTED]
Date: Fri, 17 Oct 2008 11:32:32 +0800
Subject: [PATCH] drm: fix cliprects leaking in drm_rmdraw()
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
---
drivers/gpu/drm/drm_drawable.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drawable.c b/drivers/gpu/drm/drm_drawable.c
index 70b15d1..7f8e392 100644
--- a/drivers/gpu/drm/drm_drawable.c
+++ b/drivers/gpu/drm/drm_drawable.c
@@ -76,11 +76,14 @@ int drm_rmdraw(struct drm_device *dev, void *data, struct
drm_file *file_priv)
{
struct drm_draw *draw = data;
unsigned long irqflags;
+ struct drm_drawable_info *info;
+ info = drm_get_drawable_info(dev, draw-handle);
spin_lock_irqsave(dev-drw_lock, irqflags);
- drm_free(drm_get_drawable_info(dev, draw-handle),
- sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
+ drm_free(info-rects, info-num_rects * sizeof(struct drm_clip_rect),
+ DRM_MEM_BUFS);
+ drm_free(info, sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
idr_remove(dev-drw_idr, draw-handle);
That get_drawable_info should be under the spinlock, right?
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
building the sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm having an odd problem building the dri sources on my FreeBSD machine. I have to admit that while I feel quite at home with both the FreeBSD and GNU Makes, all of the varioius auto-tools confound me. That's why my current problem is. I first tried to use autoreconf, that failed because it couldn't locate ltmain.sh. I thought that was something that was supposed to be generated by the autoreconf (that the rest of my Xorg build seems to). Well, at least the autreconf got me a configure, so I tried that, with the - --prefix suitably set. It came back to me and gave me a fatal error aboutnot being able to find either install-sh or install.sh. I'd never seen such a thing before, because the FreeBSD-native install always worked just fine with an interface very much line install.sh. Is it really neccessary to use that shell script? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj3gFUACgkQz62J6PPcoOm6MwCgl6AixEmZIVwnAJQZJqnBadNe I+oAoI/TZTLdxEAh2TSl+az0XxmbrYn8 =2k6/ -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix stalled cliprects when update drawable info with zero rects.
On Fri, 2008-10-17 at 13:15 +0800, Zhenyu Wang wrote:
From 09a461ca6d05b0c6e82aeca158bad6549ba84904 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang [EMAIL PROTECTED]
Date: Fri, 17 Oct 2008 11:20:14 +0800
Subject: [PATCH] drm: fix stalled cliprects when update drawable info with
zero rects.
When passed in drawable's cliprect number as zero, we may
still alloc and leave a stalled cliprects. Fix by clean up
cliprects in that case.
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
---
drivers/gpu/drm/drm_drawable.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_drawable.c b/drivers/gpu/drm/drm_drawable.c
index 1839c57..70b15d1 100644
--- a/drivers/gpu/drm/drm_drawable.c
+++ b/drivers/gpu/drm/drm_drawable.c
@@ -111,7 +111,9 @@ int drm_update_drawable_info(struct drm_device *dev, void
*data, struct drm_file
switch (update-type) {
case DRM_DRAWABLE_CLIPRECTS:
- if (update-num != info-num_rects) {
+ if (update-num == 0)
+ rects = NULL;
+ else if (update-num != info-num_rects) {
rects = drm_alloc(update-num * sizeof(struct
drm_clip_rect),
DRM_MEM_BUFS);
} else
Well, if I'm reading things right, when you pass zero cliprects, you'd
get either
previously != 0: drm_alloc(0, DRM_MEM_BUFS) = ZERO_SIZE_PTR;
previously == 0: whatever the previous value was (NULL or ZERO_SIZE_PTR)
However, given that I earlier today wrote a fix that tried to use
info-rects != NULL instead of info-num_rects != 0 before dereferening
the first rect, this seems like a sensible change to me. Pushed to
drm-intel-next with a change of the commit message:
commit 8b4daf046d90f1b60c53f14ef89b6fd6d8b35f30
Author: Zhenyu Wang [EMAIL PROTECTED]
Date: Fri Oct 17 13:15:48 2008 +0800
drm: Set cliprects to NULL when changing drawable to having 0 cliprects.
This avoids setting the cliprects pointer to a zero-sized allocation.
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
Signed-off-by: Eric Anholt [EMAIL PROTECTED]
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix cliprects leaking in drm_rmdraw()
On Fri, 2008-10-17 at 15:48 +0800, Zhenyu Wang wrote:
On 2008.10.16 23:27:12 -0700, Eric Anholt wrote:
On Fri, 2008-10-17 at 13:16 +0800, Zhenyu Wang wrote:
From 4aab96c10fca2d5a3f89e56a4d6a96c6125cf932 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang [EMAIL PROTECTED]
Date: Fri, 17 Oct 2008 11:32:32 +0800
Subject: [PATCH] drm: fix cliprects leaking in drm_rmdraw()
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
---
drivers/gpu/drm/drm_drawable.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drawable.c
b/drivers/gpu/drm/drm_drawable.c
index 70b15d1..7f8e392 100644
--- a/drivers/gpu/drm/drm_drawable.c
+++ b/drivers/gpu/drm/drm_drawable.c
@@ -76,11 +76,14 @@ int drm_rmdraw(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_draw *draw = data;
unsigned long irqflags;
+ struct drm_drawable_info *info;
+ info = drm_get_drawable_info(dev, draw-handle);
spin_lock_irqsave(dev-drw_lock, irqflags);
- drm_free(drm_get_drawable_info(dev, draw-handle),
- sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
+ drm_free(info-rects, info-num_rects * sizeof(struct drm_clip_rect),
+ DRM_MEM_BUFS);
+ drm_free(info, sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
idr_remove(dev-drw_idr, draw-handle);
That get_drawable_info should be under the spinlock, right?
yes, right. Here's the updated one. Thanks!
From 4b74a8a2213f1211e7a0054a40f3dda582bd0177 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang [EMAIL PROTECTED]
Date: Fri, 17 Oct 2008 16:05:00 +0800
Subject: [PATCH] drm: fix cliprects leaking in drm_rmdraw()
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
---
drivers/gpu/drm/drm_drawable.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drawable.c b/drivers/gpu/drm/drm_drawable.c
index 70b15d1..4a794d8 100644
--- a/drivers/gpu/drm/drm_drawable.c
+++ b/drivers/gpu/drm/drm_drawable.c
@@ -76,11 +76,14 @@ int drm_rmdraw(struct drm_device *dev, void *data, struct
drm_file *file_priv)
{
struct drm_draw *draw = data;
unsigned long irqflags;
+ struct drm_drawable_info *info;
spin_lock_irqsave(dev-drw_lock, irqflags);
- drm_free(drm_get_drawable_info(dev, draw-handle),
- sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
+ info = drm_get_drawable_info(dev, draw-handle);
+ drm_free(info-rects, info-num_rects * sizeof(struct drm_clip_rect),
+ DRM_MEM_BUFS);
+ drm_free(info, sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
Is it safe t ocall drm_free under the spinlock? It seems like a bad idea
to me...
idr_remove(dev-drw_idr, draw-handle);
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
-- ___ Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Comment #21 from [EMAIL PROTECTED] 2008-10-17 02:37 --- Just to let you know. I am now on 2.6.27-rc6, xserver-core 1.4.2, xorg 7.3, and the problem is still there. I needed to install some openGL apps (I did not use any before because of the crashes), and it took three days until I got my freeze :-( Again, nothing in the syslog or anywhere else. Being more than two years old now, I guess this bug will never be found. Only solution seems to upgrade to another hardware or just not to use any opengl apps. Unfortunately, I am still very happy with my Thinkpad X31, otherwise. So I guess I will go without opengl for another two to three years, until there is a stronger reason to upgrade the hardware. Pity, I like compiz... Thanks anyway and kind regards Michael -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Comment #22 from [EMAIL PROTECTED] 2008-10-17 04:20 --- Michael, did you ever try turning off AGP? Wrong AGPMode setting, or AGP at all, is known to cause system freezes. Add this to your Device section: Option BusType PCI If that works out well, you can remove that line and instead try Option AGPMode 2 or try 4 instead of 2. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Comment #23 from [EMAIL PROTECTED] 2008-10-17 04:50 --- Tormod, well, I am pretty sure that I have tried many xorg options when I first reported the bug (two years ago) including different AGPmodes, but I will try BusType PCI again. Due to the infrequent nature of these freezes it may, however, take days or weeks until I can give feedback. Thanks for your help, Michael -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Comment #24 from [EMAIL PROTECTED] 2008-10-17 06:11 --- Hmm, one question: Is AGP only used in opengl apps? I guess not. It rather seems to be the basic hardware communication protocol, isn't it? Because, without opengl I don't have any freezes of the machine, whatsoever. Only with opengl apps (e.g. compiz, googleearth) I occasionally experience these crashes. Wouldn't this rule out an effect of the option BusType PCI? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Comment #26 from [EMAIL PROTECTED] 2008-10-17 06:36 --- Using option PCI often help in lockup case, AGP is wacky. And having freeze only with gl apps doesn't rule out this option. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Comment #25 from [EMAIL PROTECTED] 2008-10-17 06:27 --- AFAIK, the DRI is the only component that uses AGP transfers with the ATI cards. If you don't enable DRI, AGP is not used, only basic PCI over the AGP slot. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6626] Infrequent system freezes when using OpenGL on ATI radeon driver r100
http://bugzilla.kernel.org/show_bug.cgi?id=6626 --- Comment #27 from [EMAIL PROTECTED] 2008-10-17 07:20 --- PCI vs. AGP only affects the GART setup for GPU access to buffers in system memory (command buffers, vertex buffers, etc.). AGP tends to be problematic. The radeon PCI GART interface is usually pretty stable. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17895] Radeon XPRESS 200M (RC410) - xorg crash after prolonged exercise of compiz
http://bugs.freedesktop.org/show_bug.cgi?id=17895 --- Comment #1 from Alex Villacís Lasso [EMAIL PROTECTED] 2008-10-17 11:07:39 PST --- Created an attachment (id=19724) -- (http://bugs.freedesktop.org/attachment.cgi?id=19724) Another log displaying the same crash The crashes are occurring again. Log attached. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17723] Radeon XPRESS 200M (RC410) - xorg crash when enabling compiz with 32 Mb VRAM
http://bugs.freedesktop.org/show_bug.cgi?id=17723 --- Comment #50 from Alex Villacís Lasso [EMAIL PROTECTED] 2008-10-17 11:11:53 PST --- There's also a crash in the log file though, does that only occur on shutdown? If so, I think this is a substantial improvement over the original failure mode, and I'll push the patches when I get to it if nobody beats me to it. It seems that the new failure mode is more bearable than the old one. However, I still get some sporadic crashes (even with 64 Mb VRAM). I opened bug #17895 for it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix cliprects leaking in drm_rmdraw()
On Fri, 2008-10-17 at 02:04 -0700, Keith Packard wrote:
On Fri, 2008-10-17 at 15:48 +0800, Zhenyu Wang wrote:
On 2008.10.16 23:27:12 -0700, Eric Anholt wrote:
On Fri, 2008-10-17 at 13:16 +0800, Zhenyu Wang wrote:
From 4aab96c10fca2d5a3f89e56a4d6a96c6125cf932 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang [EMAIL PROTECTED]
Date: Fri, 17 Oct 2008 11:32:32 +0800
Subject: [PATCH] drm: fix cliprects leaking in drm_rmdraw()
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
---
drivers/gpu/drm/drm_drawable.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drawable.c
b/drivers/gpu/drm/drm_drawable.c
index 70b15d1..7f8e392 100644
--- a/drivers/gpu/drm/drm_drawable.c
+++ b/drivers/gpu/drm/drm_drawable.c
@@ -76,11 +76,14 @@ int drm_rmdraw(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_draw *draw = data;
unsigned long irqflags;
+ struct drm_drawable_info *info;
+ info = drm_get_drawable_info(dev, draw-handle);
spin_lock_irqsave(dev-drw_lock, irqflags);
- drm_free(drm_get_drawable_info(dev, draw-handle),
-sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
+ drm_free(info-rects, info-num_rects * sizeof(struct
drm_clip_rect),
+ DRM_MEM_BUFS);
+ drm_free(info, sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
idr_remove(dev-drw_idr, draw-handle);
That get_drawable_info should be under the spinlock, right?
yes, right. Here's the updated one. Thanks!
From 4b74a8a2213f1211e7a0054a40f3dda582bd0177 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang [EMAIL PROTECTED]
Date: Fri, 17 Oct 2008 16:05:00 +0800
Subject: [PATCH] drm: fix cliprects leaking in drm_rmdraw()
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
---
drivers/gpu/drm/drm_drawable.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drawable.c b/drivers/gpu/drm/drm_drawable.c
index 70b15d1..4a794d8 100644
--- a/drivers/gpu/drm/drm_drawable.c
+++ b/drivers/gpu/drm/drm_drawable.c
@@ -76,11 +76,14 @@ int drm_rmdraw(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_draw *draw = data;
unsigned long irqflags;
+ struct drm_drawable_info *info;
spin_lock_irqsave(dev-drw_lock, irqflags);
- drm_free(drm_get_drawable_info(dev, draw-handle),
-sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
+ info = drm_get_drawable_info(dev, draw-handle);
+ drm_free(info-rects, info-num_rects * sizeof(struct drm_clip_rect),
+ DRM_MEM_BUFS);
+ drm_free(info, sizeof(struct drm_drawable_info), DRM_MEM_BUFS);
Is it safe t ocall drm_free under the spinlock? It seems like a bad idea
to me...
It's safe as far as I can tell. spinlock debugging hasn't triggered,
which seems pretty conclusive. Pushed.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm patches for 2.6.27-rc1
Hi Linus, This is a new tree, I had a conflict with your latest tree due to some trivial cleanups you merged. I've added the fix for CVE-2008-3831 which is unembargoed. Please pull the 'drm-next' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next This contains two patches outside the DRM git tree to add exports for GEM functionality while we await Nick Piggins vmap and shmem changes. This update contains the following. 1. CVE-2008-3831 - fixes for memset on arbitrary memory via i915 on G33 hw and above. 2. Intel GEM memory manager . 3. Opregion support for Intel Integrated chipsets. 4. Updated radeon driver with support for new chipsets + bugfixes 5. vblank reworking to save power and interrupts on intel/radeon GPUs. Dave. arch/x86/mm/highmem_32.c |1 + drivers/gpu/drm/Kconfig|3 +- drivers/gpu/drm/Makefile |5 +- drivers/gpu/drm/drm_agpsupport.c | 52 +- drivers/gpu/drm/drm_cache.c| 69 + drivers/gpu/drm/drm_drv.c |6 + drivers/gpu/drm/drm_fops.c |8 +- drivers/gpu/drm/drm_gem.c | 421 ++ drivers/gpu/drm/drm_irq.c | 464 +- drivers/gpu/drm/drm_memory.c |2 + drivers/gpu/drm/drm_mm.c |5 +- drivers/gpu/drm/drm_proc.c | 135 ++- drivers/gpu/drm/drm_stub.c | 11 +- drivers/gpu/drm/drm_sysfs.c|2 +- drivers/gpu/drm/i915/Makefile |7 +- drivers/gpu/drm/i915/i915_dma.c| 332 +++-- drivers/gpu/drm/i915/i915_drv.c| 476 +-- drivers/gpu/drm/i915/i915_drv.h| 1180 +--- drivers/gpu/drm/i915/i915_gem.c| 2558 drivers/gpu/drm/i915/i915_gem_debug.c | 201 +++ drivers/gpu/drm/i915/i915_gem_proc.c | 292 drivers/gpu/drm/i915/i915_gem_tiling.c | 257 drivers/gpu/drm/i915/i915_irq.c| 514 +-- drivers/gpu/drm/i915/i915_opregion.c | 371 + drivers/gpu/drm/i915/i915_reg.h| 1417 ++ drivers/gpu/drm/i915/i915_suspend.c| 509 +++ drivers/gpu/drm/mga/mga_drv.c | 29 +- drivers/gpu/drm/mga/mga_drv.h |6 +- drivers/gpu/drm/mga/mga_irq.c | 74 +- drivers/gpu/drm/mga/mga_state.c|2 +- drivers/gpu/drm/r128/r128_drv.c| 29 +- drivers/gpu/drm/r128/r128_drv.h| 11 +- drivers/gpu/drm/r128/r128_irq.c| 55 +- drivers/gpu/drm/r128/r128_state.c |2 +- drivers/gpu/drm/radeon/radeon_cp.c | 53 +- drivers/gpu/drm/radeon/radeon_drv.c| 32 +- drivers/gpu/drm/radeon/radeon_drv.h| 57 +- drivers/gpu/drm/radeon/radeon_irq.c| 268 +++-- drivers/gpu/drm/radeon/radeon_state.c |2 +- drivers/gpu/drm/sis/sis_mm.c | 10 +- drivers/gpu/drm/via/via_drv.c | 26 +- drivers/gpu/drm/via/via_drv.h | 16 +- drivers/gpu/drm/via/via_irq.c | 105 +- drivers/gpu/drm/via/via_mm.c |3 +- include/drm/drm.h | 63 +- include/drm/drmP.h | 249 +++- include/drm/drm_pciids.h | 54 +- include/drm/i915_drm.h | 333 + mm/shmem.c |1 + 49 files changed, 8814 insertions(+), 1964 deletions(-) create mode 100644 drivers/gpu/drm/drm_cache.c create mode 100644 drivers/gpu/drm/drm_gem.c create mode 100644 drivers/gpu/drm/i915/i915_gem.c create mode 100644 drivers/gpu/drm/i915/i915_gem_debug.c create mode 100644 drivers/gpu/drm/i915/i915_gem_proc.c create mode 100644 drivers/gpu/drm/i915/i915_gem_tiling.c create mode 100644 drivers/gpu/drm/i915/i915_opregion.c create mode 100644 drivers/gpu/drm/i915/i915_reg.h create mode 100644 drivers/gpu/drm/i915/i915_suspend.c commit 4b40893918203ee1a1f6a114316c2a19c072e9bd Author: Matthias Hopf [EMAIL PROTECTED] Date: Sat Oct 18 07:18:05 2008 +1000 drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831) Olaf Kirch noticed that the i915_set_status_page() function of the i915 kernel driver calls ioremap with an address offset that is supplied by userspace via ioctl. The function zeroes the mapped memory via memset and tells the hardware about the address. Turns out that access to that ioctl is not restricted to root so users could probably exploit that to do nasty things. We haven't tried to write actual exploit code though. It only affects the Intel G33 series and newer. Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 9e0b97e37fddaf5419d8af24362015ab684eff7e Author: Dave Airlie [EMAIL PROTECTED] Date: Fri Oct 17 09:29:14 2008 +1000 drm: make CONFIG_DRM depend on CONFIG_SHMEM. This can be removed later when DRM doesn't depend on shmem. Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit edc6f389f6ae9cb7621270a8ddbb1892bd8df125 Author:
Re: [git pull] drm patches for 2.6.27-rc1
On Fri, 17 Oct 2008, Dave Airlie wrote:
Please pull the 'drm-next' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
Grr.
This whole merge series has been full of people sending me UNTESTED CRAP.
So what's the excuse _this_ time for adding all these stupid warnings to
my build log? Did nobody test this?
drivers/gpu/drm/drm_proc.c: In function ‘drm_gem_one_name_info’:
drivers/gpu/drm/drm_proc.c:525: warning: format ‘%d’ expects type ‘int’, but
argument 3 has type ‘size_t’
drivers/gpu/drm/drm_proc.c:533: warning: format ‘%9d’ expects type ‘int’, but
argument 4 has type ‘size_t’
drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_gtt_pwrite’:
drivers/gpu/drm/i915/i915_gem.c:184: warning: unused variable ‘vaddr_atomic’
and I wonder how many other warnings got added that I never even noticed
because I don't build them?
And yes, it's not just warnings. One of thse is horribly bad code:
nid-len += sprintf(nid-buf[nid-len],
%6d%9d%8d%9d\n,
obj-name, obj-size,
atomic_read(obj-handlecount.refcount),
atomic_read(obj-refcount.refcount));
where it's just wrong to use the field width as a separator. Because if
the counts are big enough, the separator suddenly goes away!
So that format string should be
%6d %8zd %7d %8d\n
instead. Which gives the same output when you don't overflow, and doesn't
have the overflow bug when you do.
As to that vaddr_atomic thing, the warning would have been avoided if
you had just cleanly split up the optimistic fast case.
IOW, write cleaner code, and the warning just goes away on its own.
Something like the appended. UNTESTED!
Hmm?
I really wish people were more careful, and took more pride in trying to
write readable code, with small modular functions instead. And move those
variables down to the block they are needed in.
Anyway, I pulled the thing, but _please_ test this cleanup and send it
back to me if it passes your testing. Ok?
Linus
---
drivers/gpu/drm/drm_proc.c |4 +-
drivers/gpu/drm/i915/i915_gem.c | 59 +++---
2 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index d490db4..ae73b7f 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -522,12 +522,12 @@ static int drm_gem_one_name_info(int id, void *ptr, void
*data)
struct drm_gem_object *obj = ptr;
struct drm_gem_name_info_data *nid = data;
- DRM_INFO(name %d size %d\n, obj-name, obj-size);
+ DRM_INFO(name %d size %zd\n, obj-name, obj-size);
if (nid-eof)
return 0;
nid-len += sprintf(nid-buf[nid-len],
- %6d%9d%8d%9d\n,
+ %6d %8zd %7d %8d\n,
obj-name, obj-size,
atomic_read(obj-handlecount.refcount),
atomic_read(obj-refcount.refcount));
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9ac73dd..b8c8b2e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -171,6 +171,36 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
return 0;
}
+/*
+ * Try to write quickly with an atomic kmap. Return true on success.
+ *
+ * If this fails (which includes a partial write), we'll redo the whole
+ * thing with the slow version.
+ *
+ * This is a workaround for the low performance of iounmap (approximate
+ * 10% cpu cost on normal 3D workloads). kmap_atomic on HIGHMEM kernels
+ * happens to let us map card memory without taking IPIs. When the vmap
+ * rework lands we should be able to dump this hack.
+ */
+static inline int fast_user_write(unsigned long pfn, char __user *user_data,
int l)
+{
+#ifdef CONFIG_HIGHMEM
+ unsigned long unwritten;
+ char *vaddr_atomic;
+
+ vaddr_atomic = kmap_atomic_pfn(pfn, KM_USER0);
+#if WATCH_PWRITE
+ DRM_INFO(pwrite i %d o %d l %d pfn %ld vaddr %p\n,
+i, o, l, pfn, vaddr_atomic);
+#endif
+ unwritten = __copy_from_user_inatomic_nocache(vaddr_atomic + o,
user_data, l);
+ kunmap_atomic(vaddr_atomic, KM_USER0);
+ return !unwritten;
+#else
+ return 1;
+#endif
+}
+
static int
i915_gem_gtt_pwrite(struct drm_device *dev, struct drm_gem_object *obj,
struct drm_i915_gem_pwrite *args,
@@ -180,12 +210,7 @@ i915_gem_gtt_pwrite(struct drm_device *dev, struct
drm_gem_object *obj,
ssize_t remain;
loff_t offset;
char __user *user_data;
- char __iomem *vaddr;
- char *vaddr_atomic;
- int i, o, l;
int ret = 0;
- unsigned long pfn;
- unsigned long unwritten;
user_data = (char __user *) (uintptr_t) args-data_ptr;
Re: [git pull] drm patches for 2.6.27-rc1
On Fri, 2008-10-17 at 15:43 -0700, Linus Torvalds wrote: On Fri, 17 Oct 2008, Dave Airlie wrote: Please pull the 'drm-next' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next Grr. This whole merge series has been full of people sending me UNTESTED CRAP. So what's the excuse _this_ time for adding all these stupid warnings to my build log? Did nobody test this? drivers/gpu/drm/drm_proc.c: In function ‘drm_gem_one_name_info’: drivers/gpu/drm/drm_proc.c:525: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ drivers/gpu/drm/drm_proc.c:533: warning: format ‘%9d’ expects type ‘int’, but argument 4 has type ‘size_t’ drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_gtt_pwrite’: drivers/gpu/drm/i915/i915_gem.c:184: warning: unused variable ‘vaddr_atomic’ and I wonder how many other warnings got added that I never even noticed because I don't build them? And yes, it's not just warnings. One of thse is horribly bad code: nid-len += sprintf(nid-buf[nid-len], %6d%9d%8d%9d\n, obj-name, obj-size, atomic_read(obj-handlecount.refcount), atomic_read(obj-refcount.refcount)); where it's just wrong to use the field width as a separator. Because if the counts are big enough, the separator suddenly goes away! So that format string should be %6d %8zd %7d %8d\n instead. Which gives the same output when you don't overflow, and doesn't have the overflow bug when you do. As to that vaddr_atomic thing, the warning would have been avoided if you had just cleanly split up the optimistic fast case. IOW, write cleaner code, and the warning just goes away on its own. Something like the appended. UNTESTED! Yeah, none of us are on x86-64, so we missed those warnings in testing. The change looks pretty good except for s/return 1/return 0/. We wanted to pull the i_wish_it_was_ioremap_atomic() hack out so that we could use it for relocation updates as well (which aren't copy_from_user), and I've started writing that patch. Expect something pushed at you soon. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm patches for 2.6.27-rc1
On Fri, 17 Oct 2008, Eric Anholt wrote: Yeah, none of us are on x86-64, so we missed those warnings in testing. Really? None of you use any modern CPU's, or you're _all_ running 32-bit distros even though your cpu's could support 64-bit ones? I would suggest at least _somebody_ in the intel graphics team try to get with the times.. I realize that Otellini was saying Nobody needs 64-bit on the desktop a few years ago, but he was full of sh*t then, and it's certainly not remotely true now. It's not being disloyal to your CEO, really. I'm pretty sure nobody will be fired just for ignoring that whole 640kB^H^H^H^H^H32-bits should be enough for everybody idiocy. The change looks pretty good except for s/return 1/return 0/. oops, yes. Thinko. I reversed the meaning of the return value: at first I just returned unwritten, but decided that that was a really ugly interface, and then when I prettied that up, I didn't fix the !HIGHMEM case. And I obviously never _tested_ it. Linus - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm patches for 2.6.27-rc1
On Fri, 2008-10-17 at 19:47 -0700, Linus Torvalds wrote: Really? None of you use any modern CPU's, or you're _all_ running 32-bit distros even though your cpu's could support 64-bit ones? We're lazy, perhaps even lazier than yourself. Given that the whole goal is to essentially ignore the CPU and get our code running on the GPU, it's hard to get excited about the kind of kernel we're running on the CPU. We've got a bunch of test boxes that run 64-bits, unfortunately, the people doing builds there appear not to care about warnings. That will get fixed. I've also got this new G45 box here; perhaps it's time to enter the 21st century and run it in native 64-bit mode. It's scary though; I've been writing window systems for 32-bit machines for thirty years now. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
