Comment 60 for bug 1053959
Revision history for this message
|
|
#60 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
(In reply to comment #55)
> Created attachment 74005 [details]
> Xorg.0.log with intel_drv.so 2.20.8
>
> Sorry for the delay, it's awfully confusing that we're both called Chris
> Wilson, I didn't realise that you'd replied to my comment :)
>
> Here is Xorg.0.log, hopefully showing that the driver running is 2.20.8 (so
> with the patch)?
>
> I haven't been running xrestop, sorry. I've just started. Even if this is a
> client pixmap leak, surely one app shouldn't be able to bring down my
> desktop? Wouldn't that be a bug, perhaps in X itself rather than the Intel
> driver? But I've never seen anything like this happen with any other
> graphics card or system in 15 years of using Linux on the desktop.
It's a Denial-of-Service. There's a limited address space for mmapping of buffers, so that if the client does leak, eventually we will not be able to map a new buffer and it will remain blank. (KDE is full of such examples, or at least one sufficiently common one.)
We've harden the kernel to recover as much of that space as possible, but that is limited by the guarantees given by the userspace API. On the other side, it is possible to use alternative fallback methods if the mmapping fails, that hardening is present in SNA. Nevertheless, the side-effects will remain unpleasant until the source of the bug is found.