Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 1 Mar 2022 10:13:51 -0800
From:   Ira Weiny <ira.weiny@intel.com>
To:     Dan Williams <dan.j.williams@intel.com>
Cc:     Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V8 42/44] dax: Stray access protection for
 dax_direct_access()
Message-ID: <Yh5iX0WEKrwCg3/H@iweiny-desk3>
References: <20220127175505.851391-1-ira.weiny@intel.com>
 <20220127175505.851391-43-ira.weiny@intel.com>
 <CAPcyv4gDBnUQCe7BSWzccWGfcPZRza3PSBLqReBQgobSf09JGA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPcyv4gDBnUQCe7BSWzccWGfcPZRza3PSBLqReBQgobSf09JGA@mail.gmail.com>
Precedence: bulk

On Thu, Feb 03, 2022 at 09:19:58PM -0800, Dan Williams wrote:
> On Thu, Jan 27, 2022 at 9:55 AM <ira.weiny@intel.com> wrote:
> >
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > dax_direct_access() provides a way to obtain the direct map address of
> > PMEM memory.  Coordinate PKS protection with dax_direct_access() of
> > protected devmap pages.
> >
> > Introduce 3 new dax_operation calls .map_protected .mk_readwrite and
> > .mk_noaccess. These 3 calls do not have to be implemented by the dax
> > provider if no protection is implemented.
> >
> > Threads of execution can use dax_mk_{readwrite,noaccess}() to relax the
> > protection of the dax device and allow direct use of the kaddr returned
> > from dax_direct_access().  The dax_mk_{readwrite,noaccess}() calls only
> > need to be used to guard actual access to the memory.  Other uses of
> > dax_direct_access() do not need to use these guards.
> >
> > For users who require a permanent address to the dax device such as the
> > DM write cache.  dax_map_protected() indicates that the dax device has
> > additional protections and that user should create it's own permanent
> > mapping of the memory.  Update the DM write cache code to create this
> > permanent mapping.
> >
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> [..]
> > diff --git a/include/linux/dax.h b/include/linux/dax.h
> > index 9fc5f99a0ae2..261af298f89f 100644
> > --- a/include/linux/dax.h
> > +++ b/include/linux/dax.h
> > @@ -30,6 +30,10 @@ struct dax_operations {
> >                         sector_t, sector_t);
> >         /* zero_page_range: required operation. Zero page range   */
> >         int (*zero_page_range)(struct dax_device *, pgoff_t, size_t);
> > +
> > +       bool (*map_protected)(struct dax_device *dax_dev);
> > +       void (*mk_readwrite)(struct dax_device *dax_dev);
> > +       void (*mk_noaccess)(struct dax_device *dax_dev);
> 
> So the dax code just recently jettisoned -the >copy_{to,from}_iter()
> ops and it would be shame to grow more ops. Given that the
> implementation is pgmap generic I think all that is needed is way to
> go from a daxdev to a pgmap and then use the pgmap helpers directly
> rather than indirecting through the pmem driver just to get the pgmap.

Ok done.

dax_device now has knowledge of the pgmap which was pretty clean.

Ira