mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Mark Brown <broonie@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-kernel@vger.kernel.org,
	Dan Carpenter <dan.carpenter@linaro.org>
Subject: Traceback with CONFIG_REGMAP_KUNIT=y+CONFIG_DEBUG_ATOMIC_SLEEP=y
Date: Wed, 19 Jul 2023 15:37:54 -0700	[thread overview]
Message-ID: <ee59d128-413c-48ad-a3aa-d9d350c80042@roeck-us.net> (raw)

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

             reply	other threads:[~2023-07-19 22:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19 22:37 Guenter Roeck [this message]
2023-07-19 23:05 ` Mark Brown
2023-07-20  8:50 ` Dan Carpenter
2023-07-20 14:26   ` Guenter Roeck
2023-07-20 14:31     ` Mark Brown
2023-07-20 15:03       ` Guenter Roeck
2023-07-20 15:07         ` Mark Brown
2023-07-20 16:25           ` Guenter Roeck
2023-07-20 16:36             ` Mark Brown
2023-07-20 16:41             ` Guenter Roeck
2023-07-20 16:48               ` Mark Brown
2023-07-20 17:22                 ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ee59d128-413c-48ad-a3aa-d9d350c80042@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=broonie@kernel.org \
    --cc=dan.carpenter@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®