From: "Wanghongzhe (Hongzhe, EulerOS)" <wanghongzhe@huawei.com>
To: Kees Cook <keescook@chromium.org>
Cc: "luto@amacapital.net" <luto@amacapital.net>,
"andrii@kernel.org" <andrii@kernel.org>,
"ast@kernel.org" <ast@kernel.org>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
"daniel@iogearbox.net" <daniel@iogearbox.net>,
"john.fastabend@gmail.com" <john.fastabend@gmail.com>,
"kafai@fb.com" <kafai@fb.com>,
"kpsingh@kernel.org" <kpsingh@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"songliubraving@fb.com" <songliubraving@fb.com>,
"wad@chromium.org" <wad@chromium.org>, "yhs@fb.com" <yhs@fb.com>
Subject: 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...
Date: Thu, 4 Feb 2021 08:45:41 +0000 [thread overview]
Message-ID: <0cf4c1e8bfd140aba69cfd36a0dac048@huawei.com> (raw)
In-Reply-To: <202102021100.DB383A44@keescook>
> 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
prev parent reply other threads:[~2021-02-04 8:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 12:50 [PATCH] seccomp: Improve performance by optimizing memory barrier wanghongzhe
2021-02-01 15:39 ` Andy Lutomirski
2021-02-02 1:50 ` Wanghongzhe (Hongzhe, EulerOS)
2021-02-02 10:13 ` [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 wanghongzhe
2021-02-02 11:53 ` Greg KH
2021-02-02 14:01 ` kernel test robot
2021-02-02 14:01 ` kernel test robot
2021-02-02 19:02 ` Kees Cook
2021-02-04 8:45 ` Wanghongzhe (Hongzhe, EulerOS) [this message]
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=0cf4c1e8bfd140aba69cfd36a0dac048@huawei.com \
--to=wanghongzhe@huawei.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=keescook@chromium.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=wad@chromium.org \
--cc=yhs@fb.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.