From: "liujian (CE)" <liujian56@huawei.com>
To: John Stultz <jstultz@google.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
"sboyd@kernel.org" <sboyd@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"Paul E. McKenney" <paulmck@kernel.org>
Subject: RE: [Question] softlockup in run_timer_softirq
Date: Wed, 15 Feb 2023 08:34:14 +0000 [thread overview]
Message-ID: <f2b7fdba4ead429bb4dd38a9ccb3735a@huawei.com> (raw)
In-Reply-To: <CANDhNCqfBdh8zUd+LseTTQKpmJ27Uid+ZV_+FNckZPNc2Oy3-w@mail.gmail.com>
> -----Original Message-----
> From: John Stultz [mailto:jstultz@google.com]
> Sent: Tuesday, February 14, 2023 4:01 AM
> To: liujian (CE) <liujian56@huawei.com>
> Cc: tglx@linutronix.de; sboyd@kernel.org; linux-kernel@vger.kernel.org;
> peterz@infradead.org; Paul E. McKenney <paulmck@kernel.org>
> Subject: Re: [Question] softlockup in run_timer_softirq
>
> On Fri, Feb 10, 2023 at 1:51 AM liujian (CE) <liujian56@huawei.com> wrote:
> >
> > During the syz test, we encountered many problems with various timer
> > handler functions softlockup.
> >
> > We analyze __run_timers() and find the following problem.
> >
> > In the while loop of __run_timers(), because there are too many timers
> > or improper timer handler functions, if the processing time of the
> > expired timers is always greater than the time wheel's next_expiry,
> > the function will loop infinitely.
> >
> > The following extreme test case can be used to reproduce the problem.
> > An extreme test case[1] is constructed to reproduce the problem.
>
> Thanks for reporting and sending out this data:
>
> First, any chance you might submit this as a in-kernel-stress test?
> Maybe utilizing the kernel/torture.c framework?
>
Okay, I'll learn this framework and do this thing.
> (Though the test may need to occasionally take a break so the system can
> eventually catch up)
>
> > Is this a problem or an unreasonable use?
> >
> > Can we limit the running time of __run_timers() [2]?
> >
> > Does anyone have a good idea to solve this problem?
>
> So your patch reminds me of Peter's softirq_needs_break() logic:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=co
> re/softirq
>
> Maybe it could extend that series for the timer softirq as well?
>
Thank you. Yes.
Base on the patchset and the extended patch for timer [1], the soft lockup problem does not occur.
By the way, I see this is a very old patchset? Will this patchset push the main line? @John @Peter
[1]
Author: Liu Jian <liujian56@huawei.com>
Date: Tue Feb 14 09:53:46 2023 +0800
softirq, timer: Use softirq_needs_break()
In the while loop of __run_timers(), because there are too many timers or
improper timer handler functions, if the processing time of the expired
timers is always greater than the time wheel's next_expiry, the function
will loop infinitely.
To prevent this, use the timeout/break logic provided by SoftIRQs.If the
running time exceeds the limit, break the loop and an additional
TIMER_SOFTIRQ is triggered.
Signed-off-by: Liu Jian <liujian56@huawei.com>
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 63a8ce7177dd..70744a469a39 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1992,7 +1992,7 @@ void timer_clear_idle(void)
* __run_timers - run all expired timers (if any) on this CPU.
* @base: the timer vector to be processed.
*/
-static inline void __run_timers(struct timer_base *base)
+static inline void __run_timers(struct timer_base *base, struct softirq_action *h)
{
struct hlist_head heads[LVL_DEPTH];
int levels;
@@ -2020,6 +2020,12 @@ static inline void __run_timers(struct timer_base *base)
while (levels--)
expire_timers(base, heads + levels);
+
+ if (softirq_needs_break(h)) {
+ if (time_after_eq(jiffies, base->next_expiry))
+ __raise_softirq_irqoff(TIMER_SOFTIRQ);
+ break;
+ }
}
raw_spin_unlock_irq(&base->lock);
timer_base_unlock_expiry(base);
@@ -2032,9 +2038,9 @@ static __latent_entropy void run_timer_softirq(struct softirq_action *h)
{
struct timer_base *base = this_cpu_ptr(&timer_bases[BASE_STD]);
- __run_timers(base);
+ __run_timers(base, h);
if (IS_ENABLED(CONFIG_NO_HZ_COMMON))
- __run_timers(this_cpu_ptr(&timer_bases[BASE_DEF]));
+ __run_timers(this_cpu_ptr(&timer_bases[BASE_DEF]), h);
}
/*
> thanks
> -john
next prev parent reply other threads:[~2023-02-15 8:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 9:50 [Question] softlockup in run_timer_softirq liujian (CE)
2023-02-13 20:00 ` John Stultz
2023-02-15 8:34 ` liujian (CE) [this message]
2023-05-02 3:06 ` John Stultz
2023-05-04 1:49 ` liujian (CE)
2023-05-04 2:59 ` John Stultz
2023-05-05 11:37 ` liujian (CE)
2023-03-03 10:55 ` liujian (CE)
2023-03-09 7:04 ` John Stultz
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=f2b7fdba4ead429bb4dd38a9ccb3735a@huawei.com \
--to=liujian56@huawei.com \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
/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