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
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
