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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee59d128-413c-48ad-a3aa-d9d350c80042@roeck-us.net>
Date:   Wed, 19 Jul 2023 15:37:54 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Mark Brown <broonie@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org,
        Dan Carpenter <dan.carpenter@...aro.org>
Subject: Traceback with CONFIG_REGMAP_KUNIT=y+CONFIG_DEBUG_ATOMIC_SLEEP=y

Hi,

when booting images with both CONFIG_REGMAP_KUNIT and
CONFIG_DEBUG_ATOMIC_SLEEP enabled, I get the following backtrace.

[    4.994957]     # Subtest: regmap
[    4.995067]     1..14
[    4.995190]         KTAP version 1
[    4.995308]         # Subtest: basic_read_write
[    4.999402]         ok 1 none
[    5.003028]         ok 2 flat
[    5.005510] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306
[    5.005960] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 117, name: kunit_try_catch
[    5.006219] preempt_count: 1, expected: 0
[    5.006414] 1 lock held by kunit_try_catch/117:
[    5.006590]  #0: 833b9010 (regmap_kunit:86:(config)->lock){....}-{2:2}, at: regmap_lock_spinlock+0x14/0x1c
[    5.007493] irq event stamp: 162
[    5.007627] hardirqs last  enabled at (161): [<80786738>] crng_make_state+0x1a0/0x294
[    5.007871] hardirqs last disabled at (162): [<80c531ec>] _raw_spin_lock_irqsave+0x7c/0x80
[    5.008119] softirqs last  enabled at (0): [<801110ac>] copy_process+0x810/0x2138
[    5.008356] softirqs last disabled at (0): [<00000000>] 0x0
[    5.008688] CPU: 0 PID: 117 Comm: kunit_try_catch Tainted: G                 N 6.4.4-rc3-g0e8d2fdfb188 #1
[    5.009011] Hardware name: Generic DT based system
[    5.009277]  unwind_backtrace from show_stack+0x18/0x1c
[    5.009497]  show_stack from dump_stack_lvl+0x38/0x5c
[    5.009676]  dump_stack_lvl from __might_resched+0x188/0x2d0
[    5.009860]  __might_resched from __kmem_cache_alloc_node+0x1dc/0x25c
[    5.010061]  __kmem_cache_alloc_node from kmalloc_trace+0x30/0xc8
[    5.010254]  kmalloc_trace from regcache_rbtree_write+0x26c/0x468
[    5.010446]  regcache_rbtree_write from _regmap_write+0x88/0x140
[    5.010634]  _regmap_write from regmap_write+0x44/0x68
[    5.010803]  regmap_write from basic_read_write+0x8c/0x270
[    5.010980]  basic_read_write from kunit_try_run_case+0x48/0xa0
[    5.011170]  kunit_try_run_case from kunit_generic_run_threadfn_adapter+0x1c/0x28
[    5.011396]  kunit_generic_run_threadfn_adapter from kthread+0xf8/0x120
[    5.011603]  kthread from ret_from_fork+0x14/0x3c
[    5.011801] Exception stack(0x881a5fb0 to 0x881a5ff8)
[    5.012024] 5fa0:                                     00000000 00000000 00000000 00000000
[    5.012269] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    5.012502] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    5.014546]         ok 3 rbtree
[    5.018988]         ok 4 maple

This isn't surprising given that the regmap code allocates rbcache nodes
with GFP_KERNEL and the regmap configuration results in using spinlock
to lock regmap accesses.

I'll be happy to submit a patch to fix the problem, but I would need
some advice. I could

- Update the unit test regmap configuration to avoid using
  spinlock as locking mechanism for rbtree tests.
  That would work, but fail to catch situations where this happens
  in the real world.
- Use a different method to allocate memory in regcache_rbtree_node_alloc().
  - Replace GFP_KERNEL with GFP_NOWAIT or GFP_KERNEL | __GFP_NOWARN (?)
    or something else, possibly only if gfpflags_allow_blocking() is false
  - Use some other allocation function if gfpflags_allow_blocking()
    is false (which one ?)

Any suggestions ?

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ