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
Attachment:
signature.asc
Description: OpenPGP digital signature
