From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>, Toshi Kani <toshi.kani@hp.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>,
Will Deacon <will.deacon@arm.com>,
Christoph Hellwig <hch@infradead.org>, X86 ML <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Julia Lawall <julia.lawall@lip6.fr>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Borislav Petkov <bp@alien8.de>
Subject: Enhancing semantics with memremap() - aliasing with memremap()
Date: Tue, 24 May 2016 16:36:42 -0700 [thread overview]
Message-ID: <CAB=NE6Wy=V17uwc3GNMYaWk4cOx1a1TtHBgMYii-M5FDuPn_Gw@mail.gmail.com> (raw)
Dan, Toshi, Christoph,
I recall a while ago while memremap() was being introduced we
discussed making stronger semantics for memremap() a desirable future
goal [0], along with removal cleanups of ioremap_cache(). This was
when only 2 types were being considered, WB and WT. I see we now have
WC as well for the memremap() family.
Among one of the semantic topics, on the x86 side of things we seem to
have at least concluded we want to at the very least start by
completely discouraging and warning alias uses for different
conflicting types. A recent patch by Toshi helps to find these at run
time, however it may be possible to do this proactively semantically
with Coccinelle as well, but we first need an example test driver with
all known invalid uses cases to write up some grammar rules for the
hunt.
A much much longer term goal would be properly identify only those
valid uses for aliasing, and have a special API for them. This will
take time for the above reaons. During the memremap() review we seemed
to have agreed that making stronger semantics for memremap() was also
desirable, more aimed towards addressing this as a future goal.
Is it a good time for that now? I would hope identifying proper
aliasing uses for memremap() might be a bit easier now than for
ioremap() given its not used as widely. It may be an easier target to
also write some grammar rules for it as well.
[0] http://lkml.kernel.org/r/CAPcyv4g0-CcFRCWPBdKB7h0zZEO5qzT-N9YLYJw9sb=_HYnXiA@mail.gmail.com>
Luis
next reply other threads:[~2016-05-24 23:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-24 23:36 Luis R. Rodriguez [this message]
2016-05-31 16:58 ` Enhancing semantics with memremap() - aliasing with memremap() Christoph Hellwig
2016-05-31 17:25 ` Luis R. Rodriguez
2016-05-31 17:25 ` Luis R. Rodriguez
2016-05-31 17:27 ` Luis R. Rodriguez
2016-05-31 23:31 ` Kani, Toshimitsu
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='CAB=NE6Wy=V17uwc3GNMYaWk4cOx1a1TtHBgMYii-M5FDuPn_Gw@mail.gmail.com' \
--to=mcgrof@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=hch@infradead.org \
--cc=julia.lawall@lip6.fr \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=toshi.kani@hp.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.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 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).