All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qi Xi <xiqi2@huawei.com>
To: Joel Fernandes <joelagnelf@nvidia.com>, <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>,
	"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: Tue, 1 Jul 2025 17:20:45 +0800	[thread overview]
Message-ID: <09e4d018-3db4-404e-a8f0-041cdee15a62@huawei.com> (raw)
In-Reply-To: <e7354668-2573-4564-834b-44d76d983222@nvidia.com>

Hello everyone,

Friendly ping about this problem :)

Qi

On 2025/6/6 2:56, Joel Fernandes wrote:
>
> 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

  reply	other threads:[~2025-07-01  9:20 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
2025-07-01  9:20                 ` Qi Xi [this message]
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=09e4d018-3db4-404e-a8f0-041cdee15a62@huawei.com \
    --to=xiqi2@huawei.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=joelagnelf@nvidia.com \
    --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 \
    /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.