From: Thomas Gleixner <tglx@linutronix.de>
To: paulmck@kernel.org, Dmitry Vyukov <dvyukov@google.com>
Cc: Hillf Danton <hdanton@sina.com>,
syzbot <syzbot+0e964fad69a9c462bc1e@syzkaller.appspotmail.com>,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
Peter Zijlstra <peterz@infradead.org>,
kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [syzbot] INFO: rcu detected stall in syscall_exit_to_user_mode
Date: Wed, 15 Sep 2021 11:36:22 +0200 [thread overview]
Message-ID: <87ee9qb2p5.ffs@tglx> (raw)
In-Reply-To: <20210914183142.GP4156@paulmck-ThinkPad-P17-Gen-1>
On Tue, Sep 14 2021 at 11:31, Paul E. McKenney wrote:
> On Tue, Sep 14, 2021 at 08:00:04PM +0200, Dmitry Vyukov wrote:
>> If I understand it correctly the timer is not actually set up as
>> periodic, but rather each callback invocation arms it again. Setting
>> up a timer for 1 ns _once_ (or few times) is probably fine (right?),
>> so the check needs to be somewhat more elaborate and detect "infinite"
>> rearming.
>
> If it were practical, I would suggest checking for a CPU never actually
> executing any instructions in the interrupted context. The old-school
> way of doing this was to check the amount of time spent interrupted,
> perhaps adding some guess at interrupt entry/exit overhead. Is there
> a better new-school way?
Set NR_CPUS=0 and if then any executed instruction is observed the bug
is pretty obvious, isn't it?
next prev parent reply other threads:[~2021-09-15 9:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-28 4:52 [syzbot] INFO: rcu detected stall in syscall_exit_to_user_mode syzbot
2021-08-30 10:58 ` Dmitry Vyukov
[not found] ` <20210831074532.2255-1-hdanton@sina.com>
2021-09-13 10:28 ` Thomas Gleixner
[not found] ` <20210914123726.4219-1-hdanton@sina.com>
2021-09-14 14:58 ` Thomas Gleixner
2021-09-14 18:00 ` Dmitry Vyukov
2021-09-14 18:31 ` Paul E. McKenney
2021-09-15 9:36 ` Thomas Gleixner [this message]
2021-09-15 8:57 ` Thomas Gleixner
2021-09-15 9:14 ` Dmitry Vyukov
2021-09-15 9:32 ` Thomas Gleixner
2021-09-16 9:24 ` Dmitry Vyukov
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=87ee9qb2p5.ffs@tglx \
--to=tglx@linutronix.de \
--cc=dvyukov@google.com \
--cc=hdanton@sina.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=syzbot+0e964fad69a9c462bc1e@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/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