[PATCH] privates: Clear screen-specific keys during CloseScreen

[Keith Packard]

Aaron Plattner <aplattner at nvidia.com> writes:

> The modesetting driver corrupts memory when used after a server regeneration
> because not enough memory is allocated for its pixmap privates.  This happens
> because its call to dixRegisterScreenSpecificPrivateKey() does nothing because
> key->initialized is still TRUE from the first server generation.  However, the
> key is not in the screen's linked list of screen-specific privates because
> that's freed and reallocated during the server generation loop in dix_main().
>
> Fix this by clearing the screen-specific keys during CloseScreen, the same way
> other privates are cleared during dixResetPrivates().

Yeah, this makes sense. I think that we expected the screen-specific
privates to be allocated as a part of the screen initialization or
privates (and hence why dixFreeScreenSpecificPrivates is called before
CloseScreen when it might get freed if it were separately allocated).

I have a slight fear that CloseScreen is going to reference these
privates, and so cleaning them before CloseScreen might turn out
badly. A lot of code gets executed in CloseScreen, after all.

There's no interface for screen-specific privates to be allocated by the
privates.c code, so we can safely assume that they do not need to be
freed themselves.

How about we just set key->initialized = FALSE and leave the rest of the
key alone? That does assume that no screens will get hot-added during
CloseScreen, which seems entirely reasonable to me. The whole thing will
then be neatly re-set when the server comes around again.

Alternatively, we could assert that dixRegisterScreenSpecificPrivateKey
is only called once per key and remove the check for key->initialized,
which is really only valid for keys used across multiple objects. I think?

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150916/554c5480/attachment.sig>