public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Charlie Jenkins <charlie@rivosinc.com>,
	Xu Lu <luxu.kernel@bytedance.com>
Cc: anup@brainfault.org, paul.walmsley@sifive.com,
	palmer@dabbelt.com, lihangjing@bytedance.com,
	xieyongji@bytedance.com, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] irqchip: riscv: Order normal writes and IPI writes
Date: Fri, 17 Jan 2025 11:35:51 +0100	[thread overview]
Message-ID: <87ldv9afso.ffs@tglx> (raw)
In-Reply-To: <Z4l1fklnUPyTSLO4@ghost>

Charlie!

On Thu, Jan 16 2025 at 13:09, Charlie Jenkins wrote:
> On Thu, Jan 16, 2025 at 08:07:10PM +0800, Xu Lu wrote:
>> Replace writel_relaxed() with writel() when issuing IPI to ensure all
>> previous write operations made by current CPU are visible to other CPUs.
>
> Did you experience an ordering issue from this?

That's not the right question.

      CPU 0                     CPU 1
      store A   // data
      store B   // IPI
                                IPI handler
                                load A

The real question is whether the RISC-V memory model guarantees under
all circumstances that A is globally visible before the IPI handler
load. If so, then the writel_relaxed() is fine. If not, the fence is
required.

That's not a question of observation. It's a question of facts defined
by the architecture. People have wasted months to analyze such fails
which tend to happen once every blue moon with no other trace than
"something went wrong" ....

> - Charlie

Please trim your replies...

Thanks,

        tglx

  reply	other threads:[~2025-01-17 10:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-16 12:07 [PATCH] irqchip: riscv: Order normal writes and IPI writes Xu Lu
2025-01-16 21:09 ` Charlie Jenkins
2025-01-17 10:35   ` Thomas Gleixner [this message]
2025-01-17 15:53     ` Anup Patel
2025-01-20  7:37       ` Thomas Gleixner
2025-01-20 11:05         ` [External] " Xu Lu

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=87ldv9afso.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=anup@brainfault.org \
    --cc=charlie@rivosinc.com \
    --cc=lihangjing@bytedance.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=luxu.kernel@bytedance.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=xieyongji@bytedance.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