linux-kernel - Re: Traceback with CONFIG_REGMAP_KUNIT=y+CONFIG_DEBUG_ATOMIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d29552c2-f20c-cf68-76ae-e03a2cc7e0ba@roeck-us.net>
Date:   Thu, 20 Jul 2023 08:03:13 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Mark Brown <broonie@...nel.org>
Cc:     Dan Carpenter <dan.carpenter@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: Traceback with CONFIG_REGMAP_KUNIT=y+CONFIG_DEBUG_ATOMIC_SLEEP=y

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