All of lore.kernel.org
 help / color / mirror / Atom feed
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



      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.