From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>,
David Sterba <dsterba@suse.cz>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Kees Cook <keescook@chromium.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Ira Weiny <ira.weiny@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] highmem: Make kunmap_{local,atomic}() take pointers to const void
Date: Wed, 15 Jun 2022 07:40:59 +0200 [thread overview]
Message-ID: <5276974.Sb9uPGUboI@opensuse> (raw)
In-Reply-To: <20220615051256.31466-1-fmdefrancesco@gmail.com>
On mercoledì 15 giugno 2022 07:12:56 CEST Fabio M. De Francesco wrote:
> kunmap_{local,atomic}() currently take pointers to void. However, this
> is semantically incorrect, since these functions do not change the memory
> their arguments point to.
>
> Therefore, make this semantics explicit by modifying the
> kunmap_{local,atomic}() prototypes to take pointers to const void.
>
> As side effects, compilers will likely produce more efficient code and
> they won't any longer need casts to pointers to void where these
> functions take arguments of type pointer to const void.
>
> Suggested-by: David Sterba <dsterba@suse.cz>
> Suggested-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> ---
>
> v1->v2: Change the commit message to clearly explain why these functions
> should require pointers to const void. The fundamental argument behind
> the commit message changes is semantic correctness. Other bonuses come as
> side effects. Obviously there are no changes to the code.
>
> Many thanks to David Sterba and Ira Weiny for suggestions and reviews.
>
> include/linux/highmem-internal.h | 10 +++++-----
> mm/highmem.c | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
As said in another email, this is the second version of "[PATCH] highmem:
Make __kunmap_{local,atomic}() take "const void *"". You see that I changed
subject (involuntarily, that was just a mistake when formatting).
This is why I'm writing: make Maintainers find easily which patch this is
the second version of.
Sorry for that unwanted change to the subject.
Thanks,
Fabio
prev parent reply other threads:[~2022-06-15 5:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-15 5:12 [PATCH v2] highmem: Make kunmap_{local,atomic}() take pointers to const void Fabio M. De Francesco
2022-06-15 5:40 ` Fabio M. De Francesco [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=5276974.Sb9uPGUboI@opensuse \
--to=fmdefrancesco@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=dsterba@suse.cz \
--cc=ira.weiny@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@infradead.org \
/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.