Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1406513 > unrolled thread

Enhancing semantics with memremap() - aliasing with memremap()

Back to article view | Back to linux.kernel

Contents

  Enhancing semantics with memremap() - aliasing with memremap() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-05-25 01:40 +0200
    Re: Enhancing semantics with memremap() - aliasing with memremap() Christoph Hellwig <hch@infradead.org> - 2016-05-31 19:00 +0200
      Re: Enhancing semantics with memremap() - aliasing with memremap() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-05-31 19:30 +0200
        Re: Enhancing semantics with memremap() - aliasing with memremap() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-05-31 19:30 +0200
          Re: Enhancing semantics with memremap() - aliasing with memremap() "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2016-06-01 02:10 +0200

#1406513 — Enhancing semantics with memremap() - aliasing with memremap()

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

[toc] | [next] | [standalone]

#1410424

On Tue, May 24, 2016 at 04:36:42PM -0700, Luis R. Rodriguez wrote:
> 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.

So you want an explicit opt-in flag to allow aliasing?  Sounds fine to
me.

[toc] | [prev] | [next] | [standalone]

#1410464

On Tue, May 31, 2016 at 09:58:28AM -0700, Christoph Hellwig wrote:
> On Tue, May 24, 2016 at 04:36:42PM -0700, Luis R. Rodriguez wrote:
> > 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.
> 
> So you want an explicit opt-in flag to allow aliasing?  Sounds fine to
> me.
  
Yup! Can the default then safely already be no-aliasing then?

  Luis

[toc] | [prev] | [next] | [standalone]

#1410476

On Tue, May 31, 2016 at 07:25:14PM +0200, Luis R. Rodriguez wrote:
> On Tue, May 31, 2016 at 09:58:28AM -0700, Christoph Hellwig wrote:
> > On Tue, May 24, 2016 at 04:36:42PM -0700, Luis R. Rodriguez wrote:
> > > 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.
> > 
> > So you want an explicit opt-in flag to allow aliasing?  Sounds fine to
> > me.
>   
> Yup! Can the default then safely already be no-aliasing then?

Or if aliasing is truly not needed as often a different API, this
maybe useful later if we pick up again module namespace stuff.

  Luis

[toc] | [prev] | [next] | [standalone]

#1410695

On Tue, 2016-05-31 at 19:27 +0200, Luis R. Rodriguez wrote:
> On Tue, May 31, 2016 at 07:25:14PM +0200, Luis R. Rodriguez wrote:
> > 
> > On Tue, May 31, 2016 at 09:58:28AM -0700, Christoph Hellwig wrote:
> > > 
> > > On Tue, May 24, 2016 at 04:36:42PM -0700, Luis R. Rodriguez wrote:
> > > > 
> > > > 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.
> > > 
> > > So you want an explicit opt-in flag to allow aliasing?  Sounds fine to
> > > me.
> >   
> > Yup! Can the default then safely already be no-aliasing then?
>
> Or if aliasing is truly not needed as often a different API, this
> maybe useful later if we pick up again module namespace stuff.

I agree that we should be able to change memremap() to fail an aliasing
request since it's a relatively new interface.  ioremap() needs to start
from adding a warning message.

Thanks,
-Toshi 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web