Messages in this thread | | | Date | Tue, 26 May 2015 09:54:33 +0300 | From | Tomi Valkeinen <> | Subject | Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed |
| |
On 26/05/15 06:56, Heiko Schocher wrote:
>> Without locking, the initmem may be freed while fb_find_logo() is >> running. > > Yes, you are right, that must be added ... but has such a change a > chance to go in mainline?
I don't know. To be honest, this whole thing feels a bit like hackery. I think initdata should only be accessed from initcalls, never asynchronously.
> BTW: Could this not be currently a problem on multicore systems? > If lets say core 2 just draws the logo, another core 1 calls > fb_logo_late_init() and later core 1 free_initmem(), while the core 2 > still draws it?
Yes, I think so...
So, maybe it would be better to not even try to go forward with the current approach. Two approaches come to my mind:
1) Keep the logos in the memory, and don't even try to free them. I don't know many bytes they are in total, though.
2) Make a copy of the logos to a kmalloced area at some early boot stage. Then manually free the logos at some point (after the first access to the logos? after a certain time (urgh...)?).
Tomi
[unhandled content-type:application/pgp-signature]
| |