From: Zhiyuan Dai <daizhiyuan@phytium.com.cn>
To: ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com,
dvyukov@google.com, akpm@linux-foundation.org
Cc: kasan-dev@googlegroups.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Zhiyuan Dai <daizhiyuan@phytium.com.cn>
Subject: [PATCH] mm/kasan: remove volatile keyword
Date: Mon, 22 Feb 2021 13:22:27 +0800 [thread overview]
Message-ID: <1613971347-24213-1-git-send-email-daizhiyuan@phytium.com.cn> (raw)
Like volatile, the kernel primitives which make concurrent
access to data safe (spinlocks, mutexes, memory barriers,
etc.) are designed to prevent unwanted optimization.
If they are being used properly, there will be no need to
use volatile as well. If volatile is still necessary,
there is almost certainly a bug in the code somewhere.
In properly-written kernel code, volatile can only serve
to slow things down.
see: Documentation/process/volatile-considered-harmful.rst
Signed-off-by: Zhiyuan Dai <daizhiyuan@phytium.com.cn>
---
mm/kasan/shadow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index 7c2c08c..d5ff9ca 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -25,13 +25,13 @@
#include "kasan.h"
-bool __kasan_check_read(const volatile void *p, unsigned int size)
+bool __kasan_check_read(const void *p, unsigned int size)
{
return check_memory_region((unsigned long)p, size, false, _RET_IP_);
}
EXPORT_SYMBOL(__kasan_check_read);
-bool __kasan_check_write(const volatile void *p, unsigned int size)
+bool __kasan_check_write(const void *p, unsigned int size)
{
return check_memory_region((unsigned long)p, size, true, _RET_IP_);
}
--
1.8.3.1
next reply other threads:[~2021-02-22 5:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-22 5:22 Zhiyuan Dai [this message]
2021-02-22 7:40 ` [PATCH] mm/kasan: remove volatile keyword Dmitry Vyukov
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=1613971347-24213-1-git-send-email-daizhiyuan@phytium.com.cn \
--to=daizhiyuan@phytium.com.cn \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryabinin.a.a@gmail.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;
as well as URLs for NNTP newsgroup(s).