On 03/18/2014 11:33 AM, Takashi Iwai wrote:
At Tue, 18 Mar 2014 10:28:58 +0000, Mark Brown wrote:
On Tue, Mar 18, 2014 at 07:46:09AM +0100, Takashi Iwai wrote:
kmemdup() with GFP_KERNEL in the lock context. Ditto in regmap_register_patch(), which calls krealloc() with GFP_KERNEL.
So send a patch...
Yeah, yeah, don't rush :)
The former could be fixed by moving the lock like below. The fix for the latter depends on whether we need to protect map->patch_regs growth from races or not. If not, krealloc() can be moved out of the lock.
It should only be happening on init so probably not. On the other hand doing it without any sort of locking isn't great.
Right. OTOH, it's still better than papering over with GFP_ATOMIC, I think. We can just give a proper note in the function description, for example.
We should still hold the log over the _regmap_write portion of regmap_register_patch(), but I think we should otherwise be fine if we make it a API requirement that the caller needs to make sure that regmap_register_patch() is not called concurrently to itself or to regcache_sync().
- Lars