From: Joel Fernandes <joelagnelf@nvidia.com>
To: paulmck@kernel.org, Xiongfeng Wang <wangxiongfeng2@huawei.com>
Cc: Joel Fernandes <joel@joelfernandes.org>,
ankur.a.arora@oracle.com,
Frederic Weisbecker <frederic@kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
neeraj.upadhyay@kernel.org, urezki@gmail.com,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
xiqi2@huawei.com,
"Wangshaobo (bobo)" <bobo.shaobowang@huawei.com>,
Xie XiuQi <xiexiuqi@huawei.com>
Subject: Re: [QUESTION] problems report: rcu_read_unlock_special() called in irq_exit() causes dead loop
Date: Thu, 5 Jun 2025 14:56:25 -0400 [thread overview]
Message-ID: <e7354668-2573-4564-834b-44d76d983222@nvidia.com> (raw)
In-Reply-To: <a963b475-72cd-474d-96d4-9e651fc8f857@paulmck-laptop>
On 6/4/2025 8:26 AM, Paul E. McKenney wrote:
>>>>>>> Or just don't send subsequent self-IPIs if we just sent one for the
>>>>>>> rdp. Chances are, if we did not get the scheduler's attention during
>>>>>>> the first one, we may not in subsequent ones I think. Plus we do send
>>>>>>> other IPIs already if the grace period was over extended (from the FQS
>>>>>>> loop), maybe we can tweak that?
>>>>>> Thanks a lot for your reply. I think it's hard for me to fix this issue as
>>>>>> above without introducing new bugs. I barely understand the RCU code. But I'm
>>>>>> very glad to help test if you have any code modifiction need to. I have
>>>>>> the VM and the syskaller benchmark which can reproduce the problem.
>>>>> Sure, I understand. This is already incredibly valuable so thank you again.
>>>>> Will request for your testing help soon. I also have a test module now which
>>>>> can sort-off reproduce this. Keep you posted!
>>>>
>>>> Oh sorry I meant to ask - could you provide the full kernel log and also is
>>>> there a standalone reproducer syzcaller binary one can run to reproduce it in a VM?
>>
>> Sorry, I communicate with the teams who maintain the syzkaller tools. He said
>> I can't send the syskaller binary out of the company. Sorry, but I can help to
>> reproduce. It's not complicate and not time consuming.
>>
>> I found the origin log which use kernel v6.6. But it's not complete.
>> Then I reprouce the problem using the latest kernel.
>> Both logs are attached as attachments.
>>
> Looking at both the v6.6 version and Joel's fix, I am forced to conclude
> that this bug has been there for a very long time. Thank you for your
> testing efforts and Joel for the fix!
Thanks. I am still working on polishing the fix Xiongfeng tested. I hope to have
it out next week for review. As we discussed I will split the context-tracking
API into a separate patch and will also add a separate documentation
comment-patch on why we need the irq_work.
thanks,
- Joel
next prev parent reply other threads:[~2025-06-05 18:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 9:43 [QUESTION] problems report: rcu_read_unlock_special() called in irq_exit() causes dead loop Xiongfeng Wang
2025-05-28 16:30 ` Joel Fernandes
2025-05-30 1:55 ` Xiongfeng Wang
2025-06-03 18:59 ` Joel Fernandes
2025-06-03 19:03 ` Joel Fernandes
2025-06-03 19:22 ` Joel Fernandes
2025-06-04 1:35 ` Joel Fernandes
2025-06-04 3:25 ` Xiongfeng Wang
[not found] ` <64dfcaad-091c-4319-882b-d94515365758@huawei.com>
2025-06-04 9:20 ` Joel Fernandes
2025-06-04 3:20 ` Xiongfeng Wang
2025-06-04 12:26 ` Paul E. McKenney
2025-06-05 18:56 ` Joel Fernandes [this message]
2025-07-01 9:20 ` Qi Xi
2025-07-01 13:29 ` Joel Fernandes
2025-07-02 9:04 ` Qi Xi
2025-07-02 9:14 ` Qi Xi
2025-07-02 10:59 ` Joel Fernandes
2025-07-02 11:11 ` Frederic Weisbecker
2025-07-02 17:24 ` Joel Fernandes
2025-07-03 1:04 ` Xiongfeng Wang
2025-07-05 13:12 ` Joel Fernandes
2025-07-07 3:06 ` Qi Xi
2025-07-07 3:08 ` Joel Fernandes
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=e7354668-2573-4564-834b-44d76d983222@nvidia.com \
--to=joelagnelf@nvidia.com \
--cc=ankur.a.arora@oracle.com \
--cc=bobo.shaobowang@huawei.com \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=urezki@gmail.com \
--cc=wangxiongfeng2@huawei.com \
--cc=xiexiuqi@huawei.com \
--cc=xiqi2@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.