Re: Traceback with CONFIG_REGMAP_KUNIT=y+CONFIG_DEBUG_ATOMIC_SLEEP=y

[Guenter Roeck <linux@roeck-us.net>]

On 7/20/23 07:31, Mark Brown wrote:
> On Thu, Jul 20, 2023 at 07:26:54AM -0700, Guenter Roeck wrote:
>> On 7/20/23 01:50, Dan Carpenter wrote:
> 
>>> +++ b/drivers/base/regmap/regcache-rbtree.c
>>> @@ -187,7 +187,7 @@ static int regcache_rbtree_init(struct regmap *map)
>>>    	int i;
>>>    	int ret;
>>> -	map->cache = kmalloc(sizeof *rbtree_ctx, GFP_KERNEL);
>>> +	map->cache = kmalloc(sizeof *rbtree_ctx, map->alloc_flags);
> 
>> Yes, that might work as well (and after looking more deeply into the code
>> I wondered why it wasn't used in the first place).
> 
>> Based on Mark's feedback I submitted
>> https://lore.kernel.org/lkml/20230720032848.1306349-1-linux@roeck-us.net/
>> Sorry, I forgot to copy you on that one.
> 
>> Mark, please let me know what you prefer.
> 
> They're both independently fine, but I wouldn't expect anything that's
> running in atomic context to be actually using dynamic allocations.

Which one do you prefer ? As I mentioned in my second patch, there are
two drivers which use fast_io together with REGCACHE_RBTREE and thus
are likely affected by this problem. Dan's solution would cover that,
while my current RFC patch would likely cause those drivers to fail.
Plus, of course, they could get stuck if they actually end up trying to
sleep while allocating memory.

Thanks,
Guenter