* Breakage in "track dev_mapping in more robust and flexible way"
@ 2012-10-25 14:02 Thomas Hellstrom
2012-10-25 14:41 ` Jerome Glisse
0 siblings, 1 reply; 10+ messages in thread
From: Thomas Hellstrom @ 2012-10-25 14:02 UTC (permalink / raw)
To: Ilija Hadzic, Dave Airlie; +Cc: linux-graphics-maintainer, dri-devel
Hi,
This commit
From 949c4a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001
From: Ilija Hadzic <ihadzic@research.bell-labs.com>
Date: Tue, 15 May 2012 16:40:10 -0400
Subject: [PATCH] drm: track dev_mapping in more robust and flexible way
Setting dev_mapping (pointer to the address_space structure
used for memory mappings) to the address_space of the first
opener's inode and then failing if other openers come in
through a different inode has a few restrictions that are
eliminated by this patch.
If we already have valid dev_mapping and we spot an opener
with different i_node, we force its i_mapping pointer to the
already established address_space structure (first opener's
inode). This will make all mappings from drm device hang off
the same address_space object.
...
Breaks drivers using TTM, since when the X server calls into the driver
open, drm's dev_mapping has not
yet been setup. The setup needs to be moved before the driver's open
hook is called.
Typically, if a TTM-aware driver is provoked by the Xorg server to move
a buffer from system to VRAM or AGP,
before any other drm client is started, The user-space page table
entries are not killed before the move, and left pointing
into freed pages, causing system crashes and / or user-space access to
arbitrary memory.
/Thomas
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Breakage in "track dev_mapping in more robust and flexible way"
2012-10-25 14:02 Breakage in "track dev_mapping in more robust and flexible way" Thomas Hellstrom
@ 2012-10-25 14:41 ` Jerome Glisse
2012-10-25 15:10 ` Thomas Hellström
0 siblings, 1 reply; 10+ messages in thread
From: Jerome Glisse @ 2012-10-25 14:41 UTC (permalink / raw)
To: Thomas Hellstrom; +Cc: Dave Airlie, linux-graphics-maintainer, dri-devel
On Thu, Oct 25, 2012 at 04:02:25PM +0200, Thomas Hellstrom wrote:
> Hi,
>
> This commit
>
> From 949c4a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001
> From: Ilija Hadzic <ihadzic@research.bell-labs.com>
> Date: Tue, 15 May 2012 16:40:10 -0400
> Subject: [PATCH] drm: track dev_mapping in more robust and flexible way
>
> Setting dev_mapping (pointer to the address_space structure
> used for memory mappings) to the address_space of the first
> opener's inode and then failing if other openers come in
> through a different inode has a few restrictions that are
> eliminated by this patch.
>
> If we already have valid dev_mapping and we spot an opener
> with different i_node, we force its i_mapping pointer to the
> already established address_space structure (first opener's
> inode). This will make all mappings from drm device hang off
> the same address_space object.
> ...
>
> Breaks drivers using TTM, since when the X server calls into the
> driver open, drm's dev_mapping has not
> yet been setup. The setup needs to be moved before the driver's open
> hook is called.
>
> Typically, if a TTM-aware driver is provoked by the Xorg server to
> move a buffer from system to VRAM or AGP,
> before any other drm client is started, The user-space page table
> entries are not killed before the move, and left pointing
> into freed pages, causing system crashes and / or user-space access
> to arbitrary memory.
Doesn't handle move invalidate the drm file mapping before scheduling
the move ?
Cheers,
Jerome
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Breakage in "track dev_mapping in more robust and flexible way"
2012-10-25 14:41 ` Jerome Glisse
@ 2012-10-25 15:10 ` Thomas Hellström
2012-10-25 17:12 ` Ilija Hadzic
0 siblings, 1 reply; 10+ messages in thread
From: Thomas Hellström @ 2012-10-25 15:10 UTC (permalink / raw)
To: Jerome Glisse; +Cc: Dave Airlie, linux-graphics-maintainer, dri-devel
On 10/25/12 4:41 PM, Jerome Glisse wrote:
> On Thu, Oct 25, 2012 at 04:02:25PM +0200, Thomas Hellstrom wrote:
>> Hi,
>>
>> This commit
>>
>> From 949c4a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001
>> From: Ilija Hadzic <ihadzic@research.bell-labs.com>
>> Date: Tue, 15 May 2012 16:40:10 -0400
>> Subject: [PATCH] drm: track dev_mapping in more robust and flexible way
>>
>> Setting dev_mapping (pointer to the address_space structure
>> used for memory mappings) to the address_space of the first
>> opener's inode and then failing if other openers come in
>> through a different inode has a few restrictions that are
>> eliminated by this patch.
>>
>> If we already have valid dev_mapping and we spot an opener
>> with different i_node, we force its i_mapping pointer to the
>> already established address_space structure (first opener's
>> inode). This will make all mappings from drm device hang off
>> the same address_space object.
>> ...
>>
>> Breaks drivers using TTM, since when the X server calls into the
>> driver open, drm's dev_mapping has not
>> yet been setup. The setup needs to be moved before the driver's open
>> hook is called.
>>
>> Typically, if a TTM-aware driver is provoked by the Xorg server to
>> move a buffer from system to VRAM or AGP,
>> before any other drm client is started, The user-space page table
>> entries are not killed before the move, and left pointing
>> into freed pages, causing system crashes and / or user-space access
>> to arbitrary memory.
> Doesn't handle move invalidate the drm file mapping before scheduling
> the move ?
Yes, but to do that it needs a correct value of bdev::dev_mapping, which
is now incorrectly set on the
*second* open instead of the first open.
/Thomas
> Cheers,
> Jerome
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Breakage in "track dev_mapping in more robust and flexible way"
2012-10-25 15:10 ` Thomas Hellström
@ 2012-10-25 17:12 ` Ilija Hadzic
2012-10-25 17:31 ` Ilija Hadzic
2012-10-25 18:27 ` Thomas Hellström
0 siblings, 2 replies; 10+ messages in thread
From: Ilija Hadzic @ 2012-10-25 17:12 UTC (permalink / raw)
To: Thomas Hellström; +Cc: Dave Airlie, linux-graphics-maintainer, dri-devel
On Thu, Oct 25, 2012 at 11:10 AM, Thomas Hellström
<thellstrom@vmware.com> wrote:
> On 10/25/12 4:41 PM, Jerome Glisse wrote:
>>
>> On Thu, Oct 25, 2012 at 04:02:25PM +0200, Thomas Hellstrom wrote:
>>>
>>> Hi,
>>>
>>> This commit
>>>
>>> From 949c4a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001
>>> From: Ilija Hadzic <ihadzic@research.bell-labs.com>
>>> Date: Tue, 15 May 2012 16:40:10 -0400
>>> Subject: [PATCH] drm: track dev_mapping in more robust and flexible way
>>>
>>> Setting dev_mapping (pointer to the address_space structure
>>> used for memory mappings) to the address_space of the first
>>> opener's inode and then failing if other openers come in
>>> through a different inode has a few restrictions that are
>>> eliminated by this patch.
>>>
>>> If we already have valid dev_mapping and we spot an opener
>>> with different i_node, we force its i_mapping pointer to the
>>> already established address_space structure (first opener's
>>> inode). This will make all mappings from drm device hang off
>>> the same address_space object.
>>> ...
>>>
>>> Breaks drivers using TTM, since when the X server calls into the
>>> driver open, drm's dev_mapping has not
>>> yet been setup. The setup needs to be moved before the driver's open
>>> hook is called.
>>>
>>> Typically, if a TTM-aware driver is provoked by the Xorg server to
>>> move a buffer from system to VRAM or AGP,
>>> before any other drm client is started, The user-space page table
>>> entries are not killed before the move, and left pointing
>>> into freed pages, causing system crashes and / or user-space access
>>> to arbitrary memory.
>>
>> Doesn't handle move invalidate the drm file mapping before scheduling
>> the move ?
>
> Yes, but to do that it needs a correct value of bdev::dev_mapping, which is
> now incorrectly set on the
> *second* open instead of the first open.
>
So you are implying that in the first open the assignment of dev->dev_mapping is
somehow skipped (which could happen if drm_setup returns an error) or that the
driver on which you are having problems with (nouveau I presume) needs
dev_mapping
in the firstopen hook ?
It's been a while since I did it, but if my memory serves me well I
thought I explicitly
verified that dev_mapping was correctly set in the first open (though
GPUs I use are
primarily AMD).
-- Ilija
> /Thomas
>
>
>
>> Cheers,
>> Jerome
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Breakage in "track dev_mapping in more robust and flexible way"
2012-10-25 17:12 ` Ilija Hadzic
@ 2012-10-25 17:31 ` Ilija Hadzic
2012-10-25 18:27 ` Thomas Hellström
1 sibling, 0 replies; 10+ messages in thread
From: Ilija Hadzic @ 2012-10-25 17:31 UTC (permalink / raw)
To: =?X-UNKNOWN?Q?Thomas_Hellstr=F6m?=
Cc: Dave Airlie, linux-graphics-maintainer, dri-devel
Or could the driver that causes the problem be vmwgfx ? I now looked at
the code and I notice that indeed vmwgfx sets its private dev_mapping in
the open hook, while all other TTM-based drivers (radeon and nouveau) do
it when they create an object.
-- Ilija
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Breakage in "track dev_mapping in more robust and flexible way"
2012-10-25 17:12 ` Ilija Hadzic
2012-10-25 17:31 ` Ilija Hadzic
@ 2012-10-25 18:27 ` Thomas Hellström
2012-10-25 21:27 ` Ilija Hadzic
1 sibling, 1 reply; 10+ messages in thread
From: Thomas Hellström @ 2012-10-25 18:27 UTC (permalink / raw)
To: Ilija Hadzic; +Cc: Dave Airlie, linux-graphics-maintainer, dri-devel
On 10/25/12 7:12 PM, Ilija Hadzic wrote:
> On Thu, Oct 25, 2012 at 11:10 AM, Thomas Hellström
> <thellstrom@vmware.com> wrote:
>> On 10/25/12 4:41 PM, Jerome Glisse wrote:
>>> On Thu, Oct 25, 2012 at 04:02:25PM +0200, Thomas Hellstrom wrote:
>>>> Hi,
>>>>
>>>> This commit
>>>>
>>>> From 949c4a34afacfe800fc442afac117aba15284962 Mon Sep 17 00:00:00 2001
>>>> From: Ilija Hadzic <ihadzic@research.bell-labs.com>
>>>> Date: Tue, 15 May 2012 16:40:10 -0400
>>>> Subject: [PATCH] drm: track dev_mapping in more robust and flexible way
>>>>
>>>> Setting dev_mapping (pointer to the address_space structure
>>>> used for memory mappings) to the address_space of the first
>>>> opener's inode and then failing if other openers come in
>>>> through a different inode has a few restrictions that are
>>>> eliminated by this patch.
>>>>
>>>> If we already have valid dev_mapping and we spot an opener
>>>> with different i_node, we force its i_mapping pointer to the
>>>> already established address_space structure (first opener's
>>>> inode). This will make all mappings from drm device hang off
>>>> the same address_space object.
>>>> ...
>>>>
>>>> Breaks drivers using TTM, since when the X server calls into the
>>>> driver open, drm's dev_mapping has not
>>>> yet been setup. The setup needs to be moved before the driver's open
>>>> hook is called.
>>>>
>>>> Typically, if a TTM-aware driver is provoked by the Xorg server to
>>>> move a buffer from system to VRAM or AGP,
>>>> before any other drm client is started, The user-space page table
>>>> entries are not killed before the move, and left pointing
>>>> into freed pages, causing system crashes and / or user-space access
>>>> to arbitrary memory.
>>> Doesn't handle move invalidate the drm file mapping before scheduling
>>> the move ?
>> Yes, but to do that it needs a correct value of bdev::dev_mapping, which is
>> now incorrectly set on the
>> *second* open instead of the first open.
>>
> So you are implying that in the first open the assignment of dev->dev_mapping is
> somehow skipped (which could happen if drm_setup returns an error) or that the
> driver on which you are having problems with (nouveau I presume) needs
> dev_mapping
> in the firstopen hook ?
No. On open, driver::open is called from drm::open. It copies the value
of dev->dev_mapping, however,
driver::open is called *before* dev->dev_mapping is set up, so what I'm
saying is that the setup of
dev->dev_mapping must be moved to before driver::open is called from
drm::open
(this was hit while testing vmwgfx with new code, BTW. It will be hard,
but probably possible to trigger
from unpriviliged user-space with the current vmwgfx code.
Thanks,
Thomas
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Breakage in "track dev_mapping in more robust and flexible way"
2012-10-25 18:27 ` Thomas Hellström
@ 2012-10-25 21:27 ` Ilija Hadzic
2012-10-26 8:11 ` Thomas Hellstrom
0 siblings, 1 reply; 10+ messages in thread
From: Ilija Hadzic @ 2012-10-25 21:27 UTC (permalink / raw)
To: Thomas Hellström; +Cc: Dave Airlie, linux-graphics-maintainer, dri-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 599 bytes --]
Can you give the attached patch a whirl and let me know if it fixes the
problem?
As I indicated in my previous note, vmwgfx should be the only affected
driver because it looks at dev_mapping in the open hook (others do it when
they create an object, so they are not affected).
I'll probably revise it (and I'll have some general questions about
drm_open syscall) before officially send the patch, but I wanted to get
something quickly to you to check if it fixes your problem. I hope that
your vmwgfx test environment is such that you can reproduce the original
problem.
thanks,
-- Ilija
[-- Attachment #2: Type: TEXT/PLAIN, Size: 2618 bytes --]
From 18a489e7415f495c7ba48cc61733d6c7d8f3fd68 Mon Sep 17 00:00:00 2001
From: Ilija Hadzic <ihadzic@research.bell-labs.com>
Date: Thu, 25 Oct 2012 15:28:05 -0400
Subject: [PATCH] drm: set dev_mapping before calling drm_open_helper
Some drivers (specifically vmwgfx) look at dev_mapping
in their open hook, so we have to set dev->dev_mapping
earlier in the process.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
---
drivers/gpu/drm/drm_fops.c | 43 +++++++++++++++++++++++++++++--------------
1 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 7ef1b67..50b7b47 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -121,6 +121,8 @@ int drm_open(struct inode *inode, struct file *filp)
int minor_id = iminor(inode);
struct drm_minor *minor;
int retcode = 0;
+ int need_setup = 0;
+ struct address_space *old_mapping;
minor = idr_find(&drm_minors_idr, minor_id);
if (!minor)
@@ -132,23 +134,36 @@ int drm_open(struct inode *inode, struct file *filp)
if (drm_device_is_unplugged(dev))
return -ENODEV;
+ if (!dev->open_count++)
+ need_setup = 1;
+ mutex_lock(&dev->struct_mutex);
+ old_mapping = dev->dev_mapping;
+ if (old_mapping == NULL)
+ dev->dev_mapping = &inode->i_data;
+ mutex_unlock(&dev->struct_mutex);
+
retcode = drm_open_helper(inode, filp, dev);
- if (!retcode) {
- atomic_inc(&dev->counts[_DRM_STAT_OPENS]);
- if (!dev->open_count++)
- retcode = drm_setup(dev);
- }
- if (!retcode) {
- mutex_lock(&dev->struct_mutex);
- if (dev->dev_mapping == NULL)
- dev->dev_mapping = &inode->i_data;
- /* ihold ensures nobody can remove inode with our i_data */
- ihold(container_of(dev->dev_mapping, struct inode, i_data));
- inode->i_mapping = dev->dev_mapping;
- filp->f_mapping = dev->dev_mapping;
- mutex_unlock(&dev->struct_mutex);
+ if (retcode)
+ goto err_undo;
+ atomic_inc(&dev->counts[_DRM_STAT_OPENS]);
+ if (need_setup) {
+ retcode = drm_setup(dev);
+ if (retcode)
+ goto err_undo;
}
+ /* ihold ensures nobody can remove inode with our i_data */
+ mutex_lock(&dev->struct_mutex);
+ ihold(container_of(dev->dev_mapping, struct inode, i_data));
+ inode->i_mapping = dev->dev_mapping;
+ filp->f_mapping = dev->dev_mapping;
+ mutex_unlock(&dev->struct_mutex);
+ return 0;
+err_undo:
+ dev->open_count--;
+ mutex_lock(&dev->struct_mutex);
+ dev->dev_mapping = old_mapping;
+ mutex_unlock(&dev->struct_mutex);
return retcode;
}
EXPORT_SYMBOL(drm_open);
--
1.7.4.1
[-- Attachment #3: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: Breakage in "track dev_mapping in more robust and flexible way"
2012-10-25 21:27 ` Ilija Hadzic
@ 2012-10-26 8:11 ` Thomas Hellstrom
2012-10-26 13:14 ` Ilija Hadzic
0 siblings, 1 reply; 10+ messages in thread
From: Thomas Hellstrom @ 2012-10-26 8:11 UTC (permalink / raw)
To: Ilija Hadzic; +Cc: Dave Airlie, linux-graphics-maintainer, dri-devel
Hi,
On 10/25/2012 11:27 PM, Ilija Hadzic wrote:
>
> Can you give the attached patch a whirl and let me know if it fixes
> the problem?
>
> As I indicated in my previous note, vmwgfx should be the only affected
> driver because it looks at dev_mapping in the open hook (others do it
> when they create an object, so they are not affected).
>
> I'll probably revise it (and I'll have some general questions about
> drm_open syscall) before officially send the patch, but I wanted to
> get something quickly to you to check if it fixes your problem. I hope
> that your vmwgfx test environment is such that you can reproduce the
> original
> problem.
>
> thanks,
>
> -- Ilija
Yes, it appears like this patch fixes the problem. It'd be good to have
it in 3.7 (drm-fixes) with a cc to stable.
/Thomas
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Breakage in "track dev_mapping in more robust and flexible way"
2012-10-26 8:11 ` Thomas Hellstrom
@ 2012-10-26 13:14 ` Ilija Hadzic
2012-10-29 8:39 ` Thomas Hellstrom
0 siblings, 1 reply; 10+ messages in thread
From: Ilija Hadzic @ 2012-10-26 13:14 UTC (permalink / raw)
To: Thomas Hellstrom; +Cc: Dave Airlie, linux-graphics-maintainer, dri-devel
On Fri, 26 Oct 2012, Thomas Hellstrom wrote:
> Hi,
>
> On 10/25/2012 11:27 PM, Ilija Hadzic wrote:
>>
>> Can you give the attached patch a whirl and let me know if it fixes the
>> problem?
>>
>> As I indicated in my previous note, vmwgfx should be the only affected
>> driver because it looks at dev_mapping in the open hook (others do it when
>> they create an object, so they are not affected).
>>
>> I'll probably revise it (and I'll have some general questions about
>> drm_open syscall) before officially send the patch, but I wanted to get
>> something quickly to you to check if it fixes your problem. I hope that
>> your vmwgfx test environment is such that you can reproduce the original
>> problem.
>>
>> thanks,
>>
>> -- Ilija
>
> Yes, it appears like this patch fixes the problem. It'd be good to have it in
> 3.7 (drm-fixes) with a cc to stable.
>
OK great. Thanks for testing. Before I send out an "official" patch, I
have a few questions for those who have been around longer and can
possibly reflect better than me on the history of drm_open syscall.
Currently, before touching dev->dev_mapping field we grab dev->struct
mutex. This has been introduced by Dave Airlie a long time ago in
a2c0a97b784f837300f7b0869c82ab712c600952. I tried to preserve that in all
patches where I touched dev_open, but looking at the code I don't think
the mutex is necessary. Namely, drm_open is only set in drm_open, and
concurrent openers are protected with drm_global_mutex. Other places
(drivers) where dev->dev_mapping is accessed is read-only and dev_mapping
is written at first open when there are no file descriptors around to
issue any other call. Also, it doesn't look to me that any driver locks
dev->struct_mutex before accessing dev->dev_mapping anyway. So I am
thinking of dropping the mutex completely, but I would like to hear a
second thought.
The other issue, I noticed is that of the drm_setup() call fails, the
open_count counter would remain incremented and I think we need to restore
it back (or if I am missing something, would someone please enlighten me).
This was also in the kernel all this time (and I have not noticed until
now), so I "smuggled" that fix in the patch that I sent you. However,
wonder if I should cut the separate patch for open_count fix.
Actually, I think that I should cut three patches: one to drop the mutex,
one to fix the open_count and one to fix your problem with dev_mapping and
that probably all three should CC stable. Before I do that, I'd like to
hear opinions of others.
thanks,
Ilija
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Breakage in "track dev_mapping in more robust and flexible way"
2012-10-26 13:14 ` Ilija Hadzic
@ 2012-10-29 8:39 ` Thomas Hellstrom
0 siblings, 0 replies; 10+ messages in thread
From: Thomas Hellstrom @ 2012-10-29 8:39 UTC (permalink / raw)
To: dri-devel
On 10/26/2012 03:14 PM, Ilija Hadzic wrote:
>
>
> On Fri, 26 Oct 2012, Thomas Hellstrom wrote:
>
>> Hi,
>>
>> On 10/25/2012 11:27 PM, Ilija Hadzic wrote:
>>>
>>> Can you give the attached patch a whirl and let me know if it fixes
>>> the problem?
>>>
>>> As I indicated in my previous note, vmwgfx should be the only
>>> affected driver because it looks at dev_mapping in the open hook
>>> (others do it when they create an object, so they are not affected).
>>>
>>> I'll probably revise it (and I'll have some general questions about
>>> drm_open syscall) before officially send the patch, but I wanted to
>>> get something quickly to you to check if it fixes your problem. I
>>> hope that your vmwgfx test environment is such that you can
>>> reproduce the original
>>> problem.
>>>
>>> thanks,
>>>
>>> -- Ilija
>>
>> Yes, it appears like this patch fixes the problem. It'd be good to
>> have it in 3.7 (drm-fixes) with a cc to stable.
>>
>
> OK great. Thanks for testing. Before I send out an "official" patch, I
> have a few questions for those who have been around longer and can
> possibly reflect better than me on the history of drm_open syscall.
>
> Currently, before touching dev->dev_mapping field we grab dev->struct
> mutex. This has been introduced by Dave Airlie a long time ago in
> a2c0a97b784f837300f7b0869c82ab712c600952. I tried to preserve that in
> all patches where I touched dev_open, but looking at the code I don't
> think the mutex is necessary. Namely, drm_open is only set in
> drm_open, and concurrent openers are protected with drm_global_mutex.
> Other places (drivers) where dev->dev_mapping is accessed is read-only
> and dev_mapping is written at first open when there are no file
> descriptors around to issue any other call. Also, it doesn't look to
> me that any driver locks dev->struct_mutex before accessing
> dev->dev_mapping anyway. So I am thinking of dropping the mutex
> completely, but I would like to hear a second thought.
Without having looked a the code, with your current changes
dev->dev_mapping should be immutable and initialized before any
consumers reference
it, and as such would need no mutex, so dropping the protection of
dev->dev_mapping from that point of view should be fine. I think people
sooner or later want to get rid of drm_global_mutex, though, but at that
point we probably want another mutex that protects open-time
initialization of immutable members only, so from my point of view this
is OK, but you might want to double-check with Dave.
>
> The other issue, I noticed is that of the drm_setup() call fails, the
> open_count counter would remain incremented and I think we need to
> restore it back (or if I am missing something, would someone please
> enlighten me). This was also in the kernel all this time (and I have
> not noticed until now), so I "smuggled" that fix in the patch that I
> sent you. However, wonder if I should cut the separate patch for
> open_count fix.
>
> Actually, I think that I should cut three patches: one to drop the
> mutex, one to fix the open_count and one to fix your problem with
> dev_mapping and that probably all three should CC stable. Before I do
> that, I'd like to hear opinions of others.
I think you should, However stable doesn't want fixes for theoretical
stuff that have never been triggered in real life, so the patch to drop
mutex protection doesn't belong there. That's a patch for drm-next, so
people get a decent chance to see if it breaks something. The
dev_mapping thing opens up a quite severe security issue and should got
into drm-fixes with Cc to stable as soon as ever possible. The
open_count stuff should go into drm-fixes, possibly cc'd to stable.
Thanks,
Thomas
>
> thanks,
>
> Ilija
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-10-29 8:39 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-25 14:02 Breakage in "track dev_mapping in more robust and flexible way" Thomas Hellstrom
2012-10-25 14:41 ` Jerome Glisse
2012-10-25 15:10 ` Thomas Hellström
2012-10-25 17:12 ` Ilija Hadzic
2012-10-25 17:31 ` Ilija Hadzic
2012-10-25 18:27 ` Thomas Hellström
2012-10-25 21:27 ` Ilija Hadzic
2012-10-26 8:11 ` Thomas Hellstrom
2012-10-26 13:14 ` Ilija Hadzic
2012-10-29 8:39 ` Thomas Hellstrom
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.