Re: [PATCH 19/20] dax: Protect PTE modification on WP fault by radix tree entry lock

2016-10-19 Thread Ross Zwisler 
On Wed, Oct 19, 2016 at 09:25:05AM +0200, Jan Kara wrote:
> On Tue 18-10-16 13:53:32, Ross Zwisler wrote:
> > On Tue, Sep 27, 2016 at 06:08:23PM +0200, Jan Kara wrote:
> > > - void *entry;
> > > + void *entry, **slot;
> > >   pgoff_t index = vmf->pgoff;
> > >  
> > >   spin_lock_irq(>tree_lock);
> > > - entry = get_unlocked_mapping_entry(mapping, index, NULL);
> > > - if (!entry || !radix_tree_exceptional_entry(entry))
> > > - goto out;
> > > + entry = get_unlocked_mapping_entry(mapping, index, );
> > > + if (!entry || !radix_tree_exceptional_entry(entry)) {
> > > + if (entry)
> > > + put_unlocked_mapping_entry(mapping, index, entry);
> > 
> > I don't think you need this call to put_unlocked_mapping_entry().  If we get
> > in here we know that 'entry' is a page cache page, in which case
> > put_unlocked_mapping_entry() will just return without doing any work.
> 
> Right, but that is just an implementation detail internal to how the
> locking works. The rules are simple to avoid issues and thus the invariant
> is: Once you call get_unlocked_mapping_entry() you either have to lock the
> entry and then call put_locked_mapping_entry() or you have to drop it with
> put_unlocked_mapping_entry(). Once you add arguments about entry types
> etc., errors are much easier to make...

Makes sense.  You can add:

Reviewed-by: Ross Zwisler 
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH 19/20] dax: Protect PTE modification on WP fault by radix tree entry lock

2016-10-19 Thread Jan Kara 
On Tue 18-10-16 13:53:32, Ross Zwisler wrote:
> On Tue, Sep 27, 2016 at 06:08:23PM +0200, Jan Kara wrote:
> > -   void *entry;
> > +   void *entry, **slot;
> > pgoff_t index = vmf->pgoff;
> >  
> > spin_lock_irq(>tree_lock);
> > -   entry = get_unlocked_mapping_entry(mapping, index, NULL);
> > -   if (!entry || !radix_tree_exceptional_entry(entry))
> > -   goto out;
> > +   entry = get_unlocked_mapping_entry(mapping, index, );
> > +   if (!entry || !radix_tree_exceptional_entry(entry)) {
> > +   if (entry)
> > +   put_unlocked_mapping_entry(mapping, index, entry);
> 
> I don't think you need this call to put_unlocked_mapping_entry().  If we get
> in here we know that 'entry' is a page cache page, in which case
> put_unlocked_mapping_entry() will just return without doing any work.

Right, but that is just an implementation detail internal to how the
locking works. The rules are simple to avoid issues and thus the invariant
is: Once you call get_unlocked_mapping_entry() you either have to lock the
entry and then call put_locked_mapping_entry() or you have to drop it with
put_unlocked_mapping_entry(). Once you add arguments about entry types
etc., errors are much easier to make...

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm