lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 9 Jan 2019 08:26:54 -0800
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Pankaj Gupta <pagupta@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        qemu-devel@...gnu.org, linux-nvdimm@...1.01.org,
        linux-fsdevel@...r.kernel.org,
        virtualization@...ts.linux-foundation.org,
        linux-acpi@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-xfs@...r.kernel.org, jack@...e.cz, stefanha@...hat.com,
        dan.j.williams@...el.com, riel@...riel.com, nilal@...hat.com,
        kwolf@...hat.com, pbonzini@...hat.com, zwisler@...nel.org,
        vishal.l.verma@...el.com, dave.jiang@...el.com, david@...hat.com,
        jmoyer@...hat.com, xiaoguangrong.eric@...il.com, hch@...radead.org,
        mst@...hat.com, jasowang@...hat.com, lcapitulino@...hat.com,
        imammedo@...hat.com, eblake@...hat.com, willy@...radead.org,
        tytso@....edu, adilger.kernel@...ger.ca, rjw@...ysocki.net
Subject: Re: [PATCH v3 5/5] xfs: disable map_sync for virtio pmem

On Wed, Jan 09, 2019 at 08:17:36PM +0530, Pankaj Gupta wrote:
> Virtio pmem provides asynchronous host page cache flush
> mechanism. we don't support 'MAP_SYNC' with virtio pmem 
> and xfs.
> 
> Signed-off-by: Pankaj Gupta <pagupta@...hat.com>
> ---
>  fs/xfs/xfs_file.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index e474250..eae4aa4 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -1190,6 +1190,14 @@ xfs_file_mmap(
>  	if (!IS_DAX(file_inode(filp)) && (vma->vm_flags & VM_SYNC))
>  		return -EOPNOTSUPP;
>  
> +	/* We don't support synchronous mappings with guest direct access
> +	 * and virtio based host page cache mechanism.
> +	 */
> +	if (IS_DAX(file_inode(filp)) && virtio_pmem_host_cache_enabled(

Echoing what Jan said, this ought to be some sort of generic function
that tells us whether or not memory mapped from the dax device will
always still be accessible even after a crash (i.e. supports MAP_SYNC).

What if the underlying file on the host is itself on pmem and can be
MAP_SYNC'd?  Shouldn't the guest be able to use MAP_SYNC as well?

--D

> +		xfs_find_daxdev_for_inode(file_inode(filp))) &&
> +					(vma->vm_flags & VM_SYNC))
> +		return -EOPNOTSUPP;
> +
>  	file_accessed(filp);
>  	vma->vm_ops = &xfs_file_vm_ops;
>  	if (IS_DAX(file_inode(filp)))
> -- 
> 2.9.3
> 

Powered by blists - more mailing lists