RE: [PATCH v1 1/1] Firstly, as Andy mentioned, this should be smp_rmb() instead of rmb(). considering that TSYNC is a cross-thread situation, and rmb() is a mandatory barrier which should not be used to control SMP effects, since mandatory barriers imp...

From: Wanghongzhe (Hongzhe, EulerOS)
Date: Thu Feb 04 2021 - 03:46:47 EST

Next message: Arnaud Pouliquen: "[PATCH v3 01/15] rpmsg: char: rename rpmsg_char_init to rpmsg_chrdev_init"
Previous message: Guillaume Tucker: "Re: next/master bisection: baseline.login on rk3288-rock2-square"
In reply to: Kees Cook: "Re: [PATCH v1 1/1] Firstly, as Andy mentioned, this should be smp_rmb() instead of rmb(). considering that TSYNC is a cross-thread situation, and rmb() is a mandatory barrier which should not be used to control SMP effects, since mandatory barriers impose unnecessary overhead on both SMP and UP systems, as kernel Documentation said."
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> Let's start with a patch that just replaces rmb() with smp_rmb() and then work
> on optimizing. Can you provide performance numbers that show
> rmb() (and soon smp_rmb()) is causing actual problems here?
Ok, I will send a patch that just replaces rmb() with smp_rmb() and give performance numbers.

> BUG() should never be used[1]. This is a recoverable situation, I think, and
> should be handled as such.

I just follow the default case behind. Let's discuss this issue in next patches.

--
wanghongzhe