All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Williams, Dan J" <dan.j.williams@intel.com>
To: "sfr@canb.auug.org.au" <sfr@canb.auug.org.au>
Cc: "darrick.wong@oracle.com" <darrick.wong@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jack@suse.cz" <jack@suse.cz>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: MAP_SYNC in libnvdimm-for-next and collision fixups
Date: Fri, 3 Nov 2017 03:20:38 +0000	[thread overview]
Message-ID: <1509679236.16079.1.camel@intel.com> (raw)

Hi Stephen,

I've pushed a new libnvdimm-for-next branch that includes the libnvdimm
update for 4.15 as well as the MAP_SYNC patch set for -next exposure.
It has some collisions with code already pending in -next. My proposed
merge resolution is here:

https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git/log/?h=
libnvdimm-vs-next-20171102

---
commit 2adeca04276acb4e747dbe7a5668efe03b164566
Merge: fa8785e862ef c29c91a9daa3
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Nov 2 19:20:59 2017 -0700

    Merge branch 'libnvdimm-for-next' into test

diff --cc fs/dax.c
index 3652b26a0048,78233c716757..f3a7fb804a50
--- a/fs/dax.c
+++ b/fs/dax.c
@@@ -825,38 -820,42 +825,42 @@@ out
  }
  EXPORT_SYMBOL_GPL(dax_writeback_mapping_range);
  
- static int dax_insert_mapping(struct address_space *mapping,
- 		struct block_device *bdev, struct dax_device *dax_dev,
- 		sector_t sector, size_t size, void *entry,
- 		struct vm_area_struct *vma, struct vm_fault *vmf)
+ static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos)
  {
- 	unsigned long vaddr = vmf->address;
- 	void *ret, *kaddr;
 -	return iomap->blkno + (((pos & PAGE_MASK) - iomap->offset) >> 9);
++	return (iomap->addr + (pos & PAGE_MASK) - iomap->offset) >> 9;
+ }
+ 
+ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
+ 			 pfn_t *pfnp)
+ {
+ 	const sector_t sector = dax_iomap_sector(iomap, pos);
  	pgoff_t pgoff;
+ 	void *kaddr;
  	int id, rc;
- 	pfn_t pfn;
+ 	long length;
  
- 	rc = bdev_dax_pgoff(bdev, sector, size, &pgoff);
+ 	rc = bdev_dax_pgoff(iomap->bdev, sector, size, &pgoff);
  	if (rc)
  		return rc;
- 
  	id = dax_read_lock();
- 	rc = dax_direct_access(dax_dev, pgoff, PHYS_PFN(size), &kaddr, &pfn);
- 	if (rc < 0) {
- 		dax_read_unlock(id);
- 		return rc;
+ 	length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
+ 				   &kaddr, pfnp);
+ 	if (length < 0) {
+ 		rc = length;
+ 		goto out;
  	}
+ 	rc = -EINVAL;
+ 	if (PFN_PHYS(length) < size)
+ 		goto out;
+ 	if (pfn_t_to_pfn(*pfnp) & (PHYS_PFN(size)-1))
+ 		goto out;
+ 	/* For larger pages we need devmap */
+ 	if (length > 1 && !pfn_t_devmap(*pfnp))
+ 		goto out;
+ 	rc = 0;
+ out:
  	dax_read_unlock(id);
- 
- 	ret = dax_insert_mapping_entry(mapping, vmf, entry, sector, 0);
- 	if (IS_ERR(ret))
- 		return PTR_ERR(ret);
- 
- 	trace_dax_insert_mapping(mapping->host, vmf, ret);
- 	if (vmf->flags & FAULT_FLAG_WRITE)
- 		return vm_insert_mixed_mkwrite(vma, vaddr, pfn);
- 	else
- 		return vm_insert_mixed(vma, vaddr, pfn);
+ 	return rc;
  }
  
  /*
diff --cc fs/ext4/inode.c
index 59d31fec67ae,13a198924a0f..7250861f0f7b
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@@ -3383,6 -3393,20 +3383,19 @@@ static int ext4_releasepage(struct pag
  		return try_to_free_buffers(page);
  }
  
 -#ifdef CONFIG_FS_DAX
+ static bool ext4_inode_datasync_dirty(struct inode *inode)
+ {
+ 	journal_t *journal = EXT4_SB(inode->i_sb)->s_journal;
+ 
+ 	if (journal)
+ 		return !jbd2_transaction_committed(journal,
+ 					EXT4_I(inode)->i_datasync_tid);
+ 	/* Any metadata buffers to write? */
+ 	if (!list_empty(&inode->i_mapping->private_list))
+ 		return true;
+ 	return inode->i_state & I_DIRTY_DATASYNC;
+ }
+ 
  static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
  			    unsigned flags, struct iomap *iomap)
  {
diff --cc include/linux/iomap.h
index a61be86710b5,73e3b7085dbe..a309d611d380
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@@ -21,8 -21,12 +21,13 @@@ struct vm_fault
  /*
   * Flags for all iomap mappings:
   */
 -#define IOMAP_F_NEW	0x01	/* blocks have been newly allocated */
 +#define IOMAP_F_NEW		0x01	/* blocks have been newly allocated */
 +#define IOMAP_F_BOUNDARY	0x02	/* mapping ends at metadata boundary */
+ /*
+  * IOMAP_F_DIRTY indicates the inode has uncommitted metadata needed to access
+  * written data and requires fdatasync to commit them to persistent storage.
+  */
 -#define IOMAP_F_DIRTY	0x02
++#define IOMAP_F_DIRTY		0x04
  
  /*
   * Flags that only need to be reported for IOMAP_REPORT requests:

                 reply	other threads:[~2017-11-03  3:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1509679236.16079.1.camel@intel.com \
    --to=dan.j.williams@intel.com \
    --cc=darrick.wong@oracle.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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.