Re: [RFC v3 2/2] pmem: enable pmem_submit_bio for asynchronous flush

2022-02-16 Thread Dan Williams
On Wed, Feb 16, 2022 at 12:39 AM Pankaj Gupta wrote: > > > > > > > Return from "pmem_submit_bio" when asynchronous flush is > > > still in progress in other context. > > > > > > Signed-off-by: Pankaj Gupta > > > --- > > > drivers/nvdimm/pmem.c| 15 --- > > >

Re: [RFC v3 1/2] virtio-pmem: Async virtio-pmem flush

2022-02-16 Thread Dan Williams
On Wed, Feb 16, 2022 at 12:47 AM Pankaj Gupta wrote: > > > > > > > Enable asynchronous flush for virtio pmem using work queue. Also, > > > coalesce the flush requests when a flush is already in process. > > > This functionality is copied from md/RAID code. > > > > > > When a flush is already in

Re: [RFC v3 2/2] pmem: enable pmem_submit_bio for asynchronous flush

2022-02-15 Thread Dan Williams
On Tue, Jan 11, 2022 at 8:21 AM Pankaj Gupta wrote: > > Return from "pmem_submit_bio" when asynchronous flush is > still in progress in other context. > > Signed-off-by: Pankaj Gupta > --- > drivers/nvdimm/pmem.c| 15 --- > drivers/nvdimm/region_devs.c | 4 +++- > 2 files

Re: [RFC v3 1/2] virtio-pmem: Async virtio-pmem flush

2022-02-15 Thread Dan Williams
On Tue, Jan 11, 2022 at 8:23 AM Pankaj Gupta wrote: > > Enable asynchronous flush for virtio pmem using work queue. Also, > coalesce the flush requests when a flush is already in process. > This functionality is copied from md/RAID code. > > When a flush is already in process, new flush requests

Re: [PATCH 4/5] dax: remove the copy_from_iter and copy_to_iter methods

2021-12-15 Thread Dan Williams
On Wed, Dec 15, 2021 at 7:53 AM Vivek Goyal wrote: > > On Tue, Dec 14, 2021 at 03:43:38PM -0800, Dan Williams wrote: > > On Tue, Dec 14, 2021 at 12:33 PM Vivek Goyal wrote: > > > > > > On Tue, Dec 14, 2021 at 08:41:30AM -0800, Dan Williams wrote: > > >

Re: [PATCH 4/5] dax: remove the copy_from_iter and copy_to_iter methods

2021-12-14 Thread Dan Williams
On Tue, Dec 14, 2021 at 12:33 PM Vivek Goyal wrote: > > On Tue, Dec 14, 2021 at 08:41:30AM -0800, Dan Williams wrote: > > On Tue, Dec 14, 2021 at 6:23 AM Vivek Goyal wrote: > > > > > > On Mon, Dec 13, 2021 at 09:23:18AM +0100, Christoph Hellwig wrote: > > &g

Re: [PATCH 4/5] dax: remove the copy_from_iter and copy_to_iter methods

2021-12-14 Thread Dan Williams
On Tue, Dec 14, 2021 at 6:23 AM Vivek Goyal wrote: > > On Mon, Dec 13, 2021 at 09:23:18AM +0100, Christoph Hellwig wrote: > > On Sun, Dec 12, 2021 at 06:44:26AM -0800, Dan Williams wrote: > > > On Fri, Dec 10, 2021 at 6:17 AM Vivek Goyal wrote: > > > > Goi

Re: [PATCH 5/5] dax: always use _copy_mc_to_iter in dax_copy_to_iter

2021-12-13 Thread Dan Williams
On Mon, Dec 13, 2021 at 12:20 AM Christoph Hellwig wrote: > > On Sun, Dec 12, 2021 at 06:48:05AM -0800, Dan Williams wrote: > > On Fri, Dec 10, 2021 at 6:05 AM Vivek Goyal wrote: > > > > > > On Thu, Dec 09, 2021 at 07:38:28AM +0100, Christoph Hellwig wrote: > &

Re: [PATCH 5/5] dax: always use _copy_mc_to_iter in dax_copy_to_iter

2021-12-12 Thread Dan Williams
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote: > > While using the MC-safe copy routines is rather pointless on a virtual device > like virtiofs, it also isn't harmful at all. So just use _copy_mc_to_iter > unconditionally to simplify the code. >From a correctness perspective, yes,

Re: [PATCH 5/5] dax: always use _copy_mc_to_iter in dax_copy_to_iter

2021-12-12 Thread Dan Williams
On Fri, Dec 10, 2021 at 6:05 AM Vivek Goyal wrote: > > On Thu, Dec 09, 2021 at 07:38:28AM +0100, Christoph Hellwig wrote: > > While using the MC-safe copy routines is rather pointless on a virtual > > device > > like virtiofs, > > I was wondering about that. Is it completely pointless. > >

Re: [PATCH 4/5] dax: remove the copy_from_iter and copy_to_iter methods

2021-12-12 Thread Dan Williams
On Fri, Dec 10, 2021 at 6:17 AM Vivek Goyal wrote: > > On Thu, Dec 09, 2021 at 07:38:27AM +0100, Christoph Hellwig wrote: > > These methods indirect the actual DAX read/write path. In the end pmem > > uses magic flush and mc safe variants and fuse and dcssblk use plain ones > > while device

Re: [PATCH 4/5] dax: remove the copy_from_iter and copy_to_iter methods

2021-12-12 Thread Dan Williams
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote: > > These methods indirect the actual DAX read/write path. In the end pmem > uses magic flush and mc safe variants and fuse and dcssblk use plain ones > while device mapper picks redirects to the underlying device. > > Add

Re: [PATCH 3/5] dax: remove the DAXDEV_F_SYNC flag

2021-12-12 Thread Dan Williams
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote: > > Remove the DAXDEV_F_SYNC flag and thus the flags argument to alloc_dax and > just let the drivers call set_dax_synchronous directly. > > Signed-off-by: Christoph Hellwig Sure, looks good to me. Reviewed-b

Re: [PATCH 2/5] dax: simplify dax_synchronous and set_dax_synchronous

2021-12-12 Thread Dan Williams
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote: > > Remove the pointless wrappers. > > Signed-off-by: Christoph Hellwig Looks good, not sure why those ever existed. Reviewed-by: Dan Williams > --- > drivers/dax/super.c | 8 > include/linux/dax.h |

Re: [PATCH 1/5] uio: remove copy_from_iter_flushcache() and copy_mc_to_iter()

2021-12-12 Thread Dan Williams
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote: > > These two wrappers are never used. > > Signed-off-by: Christoph Hellwig > --- > drivers/nvdimm/pmem.c | 4 ++-- > include/linux/uio.h | 20 +--- > 2 files changed, 3 insertions(+), 21 deletions(-) > > diff --git

Re: [PATCH 29/29] fsdax: don't require CONFIG_BLOCK

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > The file system DAX code now does not require the block code. So allow > building a kernel with fuse DAX but not block layer. Looks good to me. Reviewed-by: Dan Williams ___ Virtu

Re: [PATCH 28/29] iomap: build the block based code conditionally

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Only build the block based iomap code if CONFIG_BLOCK is set. Currently > that is always the case, but it will change soon. Looks good. Reviewed-by: Dan Williams ___ Virtualizatio

Re: [PATCH 27/29] dax: fix up some of the block device related ifdefs

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > The DAX device <-> block device association is only enabled if > CONFIG_BLOCK is enabled. Update dax.h to account for that and use > the right conditions for the fs_put_dax stub as well. Looks good to me. Reviewe

Re: [PATCH 26/29] fsdax: shift partition offset handling into the file systems

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Remove the last user of ->bdev in dax.c by requiring the file system to > pass in an address that already includes the DAX offset. As part of the > only set ->bdev or ->daxdev when actually required in the ->iomap_begin > methods.

Re: [PATCH 25/29] dax: return the partition offset from fs_dax_get_by_bdev

2021-11-23 Thread Dan Williams
bdev; > - td->dm_dev.dax_dev = fs_dax_get_by_bdev(bdev); > + td->dm_dev.dax_dev = fs_dax_get_by_bdev(bdev, _off); Perhaps allow NULL as an argument for callers that do not care about the start offset? Otherwise, looks good / clever. Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 24/29] xfs: use xfs_direct_write_iomap_ops for DAX zeroing

2021-11-23 Thread Dan Williams
o me. Reviewed-by: Dan Williams > Signed-off-by: Christoph Hellwig > --- > fs/xfs/xfs_iomap.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c > index 8cef3b68cba78..704292c6ce0c7 100644 > --- a/fs/xfs

Re: [PATCH 23/29] xfs: use IOMAP_DAX to check for DAX mappings

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Use the explicit DAX flag instead of checking the inode flag in the > iomap code. It's not immediately clear to me why this is a net benefit, are you anticipating inode-less operations? With reflink and multi-inode operations a single

Re: [PATCH 22/29] iomap: add a IOMAP_DAX flag

2021-11-23 Thread Dan Williams
an add: Reviewed-by: Dan Williams > > Signed-off-by: Christoph Hellwig > --- > fs/dax.c | 7 --- > include/linux/iomap.h | 1 + > 2 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/fs/dax.c b/fs/dax.c > index 5b52b878124ac..0bd6cdcbacfc4 1

Re: [PATCH 21/29] xfs: move dax device handling into xfs_{alloc, free}_buftarg

2021-11-23 Thread Dan Williams
ain about missing sign-off? Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 20/29] ext4: cleanup the dax handling in ext4_fill_super

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Only call fs_dax_get_by_bdev once the sbi has been allocated and remove > the need for the dax_dev local variable. Looks good. Reviewed-by: Dan Williams ___ Virtualization mai

Re: [PATCH 19/29] ext2: cleanup the dax handling in ext2_fill_super

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Only call fs_dax_get_by_bdev once the sbi has been allocated and remove > the need for the dax_dev local variable. Looks good. Reviewed-by: Dan Williams ___ Virtualization mai

Re: [PATCH 18/29] fsdax: decouple zeroing from the iomap buffered I/O code

2021-11-23 Thread Dan Williams
callers. Most callers already have DAX special casing anyway > and XFS will need it for reflink support as well. Looks ok, a tangential question below about iomap_truncate_page(), but you can add: Reviewed-by: Dan Williams > > Signed-off-by: Christoph Hellwig > --- >

Re: [PATCH 17/29] fsdax: factor out a dax_memzero helper

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Factor out a helper for the "manual" zeroing of a DAX range to clean > up dax_iomap_zero a lot. > Small / optional fixup below: Reviewed-by: Dan Williams > Signed-off-by: Christoph Hellwi

Re: [PATCH 16/29] fsdax: simplify the offset check in dax_iomap_zero

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > The file relative offset must have the same alignment as the storage > offset, so use that and get rid of the call to iomap_sector. Agree. Reviewed-by: Dan Williams ___ Virtu

Re: [PATCH 15/29] xfs: add xfs_zero_range and xfs_truncate_page helpers

2021-11-23 Thread Dan Williams
ks good to me. Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 14/29] fsdax: simplify the pgoff calculation

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Replace the two steps of dax_iomap_sector and bdev_dax_pgoff with a > single dax_iomap_pgoff helper that avoids lots of cumbersome sector > conversions. Looks good, Reviewed-by: Dan Williams > > Signed-off-by:

Re: [PATCH 13/29] fsdax: use a saner calling convention for copy_cow_page_dax

2021-11-23 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Just pass the vm_fault and iomap_iter structures, and figure out the rest > locally. Note that this requires moving dax_iomap_sector up in the file. Looks good, Reviewed-by: Dan Williams > > Signed-off-by: Ch

Re: [PATCH 04/29] dax: simplify the dax_device <-> gendisk association

2021-11-23 Thread Dan Williams
On Mon, Nov 22, 2021 at 9:58 PM Christoph Hellwig wrote: > > On Mon, Nov 22, 2021 at 07:33:06PM -0800, Dan Williams wrote: > > Is it time to add a "DAX" symbol namespace? > > What would be the benefit? Just the small benefit of identifying DAX core users with a commo

Re: [PATCH 12/29] fsdax: remove a pointless __force cast in copy_cow_page_dax

2021-11-22 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Despite its name copy_user_page expected kernel addresses, which is what > we already have. Yup, Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@li

Re: [PATCH 11/29] dm-stripe: add a stripe_dax_pgoff helper

2021-11-22 Thread Dan Williams
ted. > > Signed-off-by: Christoph Hellwig > Acked-by: Mike Snitzer Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 10/29] dm-log-writes: add a log_writes_dax_pgoff helper

2021-11-22 Thread Dan Williams
ted. > > Signed-off-by: Christoph Hellwig > Acked-by: Mike Snitzer Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 09/29] dm-linear: add a linear_dax_pgoff helper

2021-11-22 Thread Dan Williams
ted. > > Signed-off-by: Christoph Hellwig > Acked-by: Mike Snitzer Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 08/29] dax: remove dax_capable

2021-11-22 Thread Dan Williams
B-P7TQMD6M-0146.local ...and Darrick's https://lore.kernel.org/r/20211019154447.GL24282@magnolia ...which had a few more review comments below, otherwise you can also add: Reviewed-by: Dan Williams > --- > drivers/dax/super.c | 36 >

Re: [PATCH 07/29] xfs: factor out a xfs_setup_dax_always helper

2021-11-22 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Factor out another DAX setup helper to simplify future changes. Also > move the experimental warning after the checks to not clutter the log > too much if the setup failed. > > Signed-off-by: Christoph Hellwig

Re: [PATCH 06/29] dax: move the partition alignment check into fs_dax_get_by_bdev

2021-11-22 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > fs_dax_get_by_bdev is the primary interface to find a dax device for a > block device, so move the partition alignment check there instead of > wiring it up through ->dax_supported. > Reviewe

Re: [PATCH 05/29] dax: remove the pgmap sanity checks in generic_fsdax_supported

2021-11-22 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Drivers that register a dax_dev should make sure it works, no need > to double check from the file system. Reviewed-by: Dan Williams ...with a self-reminder to migrate this validation to a unit test to backstop any future re

Re: [PATCH 04/29] dax: simplify the dax_device <-> gendisk association

2021-11-22 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Replace the dax_host_hash with an xarray indexed by the pointer value > of the gendisk, and require explicitly calls from the block drivers that > want to associate their gendisk with a dax_device. > > Signed-off-by: Christoph Hellwig

Re: [PATCH 03/29] dax: remove CONFIG_DAX_DRIVER

2021-11-22 Thread Dan Williams
On Wed, Nov 17, 2021 at 9:43 AM Dan Williams wrote: > > On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > > > CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it. > > Applied. Unapplied, R

Re: [PATCH 02/29] dm: make the DAX support dependend on CONFIG_FS_DAX

2021-11-22 Thread Dan Williams
On Thu, Nov 18, 2021 at 10:55 PM Christoph Hellwig wrote: > > On Wed, Nov 17, 2021 at 09:23:44AM -0800, Dan Williams wrote: > > Applied, fixed the spelling of 'dependent' in the subject and picked > > up Mike's Ack from the previous send: > > > > https://l

Re: [PATCH 01/29] nvdimm/pmem: move dax_attribute_group from dax to pmem

2021-11-19 Thread Dan Williams
On Thu, Nov 18, 2021 at 10:56 PM Christoph Hellwig wrote: > > On Wed, Nov 17, 2021 at 09:44:25AM -0800, Dan Williams wrote: > > On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > > > > > dax_attribute_group is only used by the pmem driver, and can avoid

Re: [PATCH 01/29] nvdimm/pmem: move dax_attribute_group from dax to pmem

2021-11-17 Thread Dan Williams
the same ifdef block as that caller. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Dan Williams > Link: https://lore.kernel.org/r/20210922173431.2454024-3-...@lst.de > Signed-off-by: Dan Williams This one already made v5.16-rc1. _

Re: [PATCH 03/29] dax: remove CONFIG_DAX_DRIVER

2021-11-17 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it. Applied. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: [PATCH 02/29] dm: make the DAX support dependend on CONFIG_FS_DAX

2021-11-17 Thread Dan Williams
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > The device mapper DAX support is all hanging off a block device and thus > can't be used with device dax. Make it depend on CONFIG_FS_DAX instead > of CONFIG_DAX_DRIVER. This also means that bdev_dax_pgoff only needs to > be built

Re: futher decouple DAX from block devices

2021-11-04 Thread Dan Williams
On Thu, Nov 4, 2021 at 10:36 AM Christoph Hellwig wrote: > > On Thu, Nov 04, 2021 at 10:34:17AM -0700, Darrick J. Wong wrote: > > /me wonders, are block devices going away? Will mkfs.xfs have to learn > > how to talk to certain chardevs? I guess jffs2 and others already do > > that kind of

Re: futher decouple DAX from block devices

2021-10-29 Thread Dan Williams
On Fri, Oct 29, 2021 at 8:55 AM Darrick J. Wong wrote: > > On Fri, Oct 29, 2021 at 08:42:29AM -0700, Dan Williams wrote: > > On Thu, Oct 28, 2021 at 4:52 PM Stephen Rothwell > > wrote: > > > > > > Hi Dan, > > > > > > On Wed,

Re: futher decouple DAX from block devices

2021-10-29 Thread Dan Williams
On Thu, Oct 28, 2021 at 4:52 PM Stephen Rothwell wrote: > > Hi Dan, > > On Wed, 27 Oct 2021 13:46:31 -0700 Dan Williams > wrote: > > > > My merge resolution is here [1]. Christoph, please have a look. The > > rebase and the merge result are both passing my tes

Re: [PATCH 11/11] dax: move bdev_dax_pgoff to fs/dax.c

2021-10-27 Thread Dan Williams
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > No functional changet, but this will allow for a tighter integration s/changet/changes/ > with the iomap code, including possible passing the partition offset s/possible/possibly/ > in the iomap in the future. For now it mostly

Re: [PATCH 10/11] dm-stripe: add a stripe_dax_pgoff helper

2021-10-27 Thread Dan Williams
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Add a helper to perform the entire remapping for DAX accesses. This > helper open codes bdev_dax_pgoff given that the alignment checks have > already been done by the submitting file system and don't need to be > repeated. Again,

Re: [PATCH 09/11] dm-log-writes: add a log_writes_dax_pgoff helper

2021-10-27 Thread Dan Williams
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Add a helper to perform the entire remapping for DAX accesses. This > helper open codes bdev_dax_pgoff given that the alignment checks have > already been done by the submitting file system and don't need to be > repeated. Looks good.

Re: [PATCH 08/11] dm-linear: add a linear_dax_pgoff helper

2021-10-27 Thread Dan Williams
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Add a helper to perform the entire remapping for DAX accesses. This > helper open codes bdev_dax_pgoff given that the alignment checks have > already been done by the submitting file system and don't need to be > repeated. Looks good.

Re: [dm-devel] [PATCH 07/11] dax: remove dax_capable

2021-10-27 Thread Dan Williams
On Tue, Oct 19, 2021 at 8:45 AM Darrick J. Wong wrote: > > On Mon, Oct 18, 2021 at 06:40:50AM +0200, Christoph Hellwig wrote: > > Just open code the block size and dax_dev == NULL checks in the callers. > > > > Signed-off-by: Christoph Hellwig > > --- > > drivers/dax/super.c | 36

Re: [PATCH 07/11] dax: remove dax_capable

2021-10-27 Thread Dan Williams
I am going to change the subject of this patch to: dax: remove ->dax_supported() On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > I'll add a bit more background to help others review this. The ->dax_supported() operation arranges for a stack of devices to each answer the question

Re: [PATCH 06/11] xfs: factor out a xfs_setup_dax helper

2021-10-27 Thread Dan Williams
On Tue, Oct 19, 2021 at 12:24 AM Christoph Hellwig wrote: > > On Mon, Oct 18, 2021 at 09:43:51AM -0700, Darrick J. Wong wrote: > > > --- a/fs/xfs/xfs_super.c > > > +++ b/fs/xfs/xfs_super.c > > > @@ -339,6 +339,32 @@ xfs_buftarg_is_dax( > > > bdev_nr_sectors(bt->bt_bdev)); > >

Re: [PATCH 05/11] dax: move the partition alignment check into fs_dax_get_by_bdev

2021-10-27 Thread Dan Williams
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > fs_dax_get_by_bdev is the primary interface to find a dax device for a > block device, so move the partition alignment check there instead of > wiring it up through ->dax_supported. Looks good. > > Signed-off-by: Christoph Hellwig >

Re: [PATCH 04/11] dax: remove the pgmap sanity checks in generic_fsdax_supported

2021-10-27 Thread Dan Williams
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Drivers that register a dax_dev should make sure it works, no need > to double check from the file system. > > Signed-off-by: Christoph Hellwig > --- > drivers/dax/super.c | 49 + > 1 file

Re: [PATCH 03/11] dax: simplify the dax_device <-> gendisk association

2021-10-27 Thread Dan Williams
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Replace the dax_host_hash with an xarray indexed by the pointer value > of the gendisk, and require explicitl calls from the block drivers that s/explicitl/explicitl/ I've fixed that up locally. > want to associate their gendisk with

Re: [PATCH 02/11] dax: remove CONFIG_DAX_DRIVER

2021-10-27 Thread Dan Williams
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it. Looks good, I don't think an s390 ack is needed for this one. > Signed-off-by: Christoph Hellwig > --- > drivers/dax/Kconfig| 4 > drivers/nvdimm/Kconfig

Re: [PATCH 01/11] dm: make the DAX support dependend on CONFIG_FS_DAX

2021-10-27 Thread Dan Williams
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > The device mapper DAX support is all hanging off a block device and thus > can't be used with device dax. Make it depend on CONFIG_FS_DAX instead > of CONFIG_DAX_DRIVER. This also means that bdev_dax_pgoff only needs to > be built

Re: futher decouple DAX from block devices

2021-10-27 Thread Dan Williams
[ add sfr ] On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Hi Dan, > > this series cleans up and simplifies the association between DAX and block > devices in preparation of allowing to mount file systems directly on DAX > devices without a detour through block devices. So I

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

2021-10-12 Thread Dan Williams
On Tue, Oct 12, 2021 at 2:28 PM Andi Kleen wrote: [..] > >> But how do you debug the kernel then? Making early undebuggable seems > >> just bad policy to me. > > I am not proposing making the early undebuggable. > > > That's the implication of moving the policy into initrd. > > > If only initrd

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

2021-10-12 Thread Dan Williams
On Tue, Oct 12, 2021 at 11:35 AM Andi Kleen wrote: > > > > The "better safe-than-sorry" argument is hard to build consensus > > around. The spectre mitigations ran into similar problems where the > > community rightly wanted to see the details and instrument the > > problematic paths rather than

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

2021-10-12 Thread Dan Williams
On Tue, Oct 12, 2021 at 11:57 AM Reshetova, Elena wrote: > > > > I suspect the true number is even higher because that doesn't include IO > > inside calls to other modules and indirect pointers, correct? > > Actually everything should be included. Smatch has cross-function db and > I am using it

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

2021-10-12 Thread Dan Williams
On Sun, Oct 10, 2021 at 3:11 PM Andi Kleen wrote: > > > On 10/9/2021 1:39 PM, Dan Williams wrote: > > On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote: > >> On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote: > >>> From: Andi Kl

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

2021-10-09 Thread Dan Williams
On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote: > > On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote: > > From: Andi Kleen > > > > For Confidential VM guests like TDX, the host is untrusted and hence > > the devices emulated by the host or any data coming from

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

2021-10-05 Thread Dan Williams
On Sun, Oct 3, 2021 at 10:16 PM Mika Westerberg wrote: > > Hi, > > On Fri, Oct 01, 2021 at 12:57:18PM -0700, Dan Williams wrote: > > > > Ah, so are you saying that it would be sufficient for USB if the > > > > generic authorized implementation did something l

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

2021-10-04 Thread Dan Williams
On Sat, Oct 2, 2021 at 7:20 AM Andi Kleen wrote: > > > On 10/2/2021 4:14 AM, Greg Kroah-Hartman wrote: > > On Sat, Oct 02, 2021 at 07:04:28AM -0400, Michael S. Tsirkin wrote: > >> On Fri, Oct 01, 2021 at 08:49:28AM -0700, Andi Kleen wrote: > Do you have a list of specific drivers and

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

2021-10-01 Thread Dan Williams
On Fri, Oct 1, 2021 at 12:02 PM Alan Stern wrote: > > On Fri, Oct 01, 2021 at 11:09:52AM -0700, Dan Williams wrote: > > On Fri, Oct 1, 2021 at 9:47 AM Alan Stern wrote: > > > > > > On Fri, Oct 01, 2021 at 09:13:54AM -0700, Dan Williams wrote: > > >

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

2021-10-01 Thread Dan Williams
On Fri, Oct 1, 2021 at 9:47 AM Alan Stern wrote: > > On Fri, Oct 01, 2021 at 09:13:54AM -0700, Dan Williams wrote: > > Bear with me, and perhaps it's a lack of imagination on my part, but I > > don't see how to get to a globally generic "authorized" sysfs ABI > &

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

2021-10-01 Thread Dan Williams
amy, Sathyanarayanan > > > wrote: > > > > > > > > > > > > On 9/30/21 6:36 AM, Dan Williams wrote: > > > > > > And in particular, not all virtio drivers are hardened - > > > > > > I think at this point blk and scsi drivers have be

Re: [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices

2021-09-30 Thread Dan Williams
On Thu, Sep 30, 2021 at 6:41 PM Alan Stern wrote: > > On Thu, Sep 30, 2021 at 01:52:59PM -0700, Dan Williams wrote: > > On Thu, Sep 30, 2021 at 1:44 PM Alan Stern > > wrote: > > > > > > On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote: > &g

Re: [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices

2021-09-30 Thread Dan Williams
On Thu, Sep 30, 2021 at 1:44 PM Alan Stern wrote: > > On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote: > > > > > I don't think the current mitigations under discussion here are about > > > keeping the system working. In fact most encrypted VM configs tend to > > > stop booting as a

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

2021-09-30 Thread Dan Williams
On Thu, Sep 30, 2021 at 12:50 PM Kuppuswamy, Sathyanarayanan wrote: > > > > On 9/30/21 12:04 PM, Dan Williams wrote: > >>> That's why it was highlighted in the changelog. Hopefully a > >>> Thunderbolt developer can confirm if it is a non-issue. >

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

2021-09-30 Thread Dan Williams
On Thu, Sep 30, 2021 at 11:25 AM Yehezkel Bernat wrote: > > On Thu, Sep 30, 2021 at 6:28 PM Dan Williams wrote: > > > > On Thu, Sep 30, 2021 at 4:20 AM Yehezkel Bernat > > wrote: > > > > > > On Thu, Sep 30, 2021 at 4:05 AM Kuppuswamy Sathyanarayanan &

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

2021-09-30 Thread Dan Williams
On Thu, Sep 30, 2021 at 4:20 AM Yehezkel Bernat wrote: > > On Thu, Sep 30, 2021 at 4:05 AM Kuppuswamy Sathyanarayanan > wrote: > > > > no functional > > changes other than value 2 being not visible to the user. > > > > Are we sure we don't break any user-facing tool with it? Tools might use this

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

2021-09-30 Thread Dan Williams
On Thu, Sep 30, 2021 at 8:00 AM Alan Stern wrote: > > On Wed, Sep 29, 2021 at 06:55:12PM -0700, Dan Williams wrote: > > On Wed, Sep 29, 2021 at 6:43 PM Alan Stern > > wrote: > > > > > > On Wed, Sep 29, 2021 at 06:05:06PM -0700, Kuppuswamy Sathyanarayanan

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

2021-09-30 Thread Dan Williams
gt; > arrange for all devices to default to unauthorized (via > > dev_default_authorization) in device_initialize(). Since virtio > > driver is already hardened against the attack from the un-trusted host, > > override the confidential computing default unauthorized state >

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

2021-09-29 Thread Dan Williams
On Wed, Sep 29, 2021 at 7:39 PM Kuppuswamy, Sathyanarayanan wrote: > > > > On 9/29/21 6:55 PM, Dan Williams wrote: > >> Also, you ignored the usb_[de]authorize_interface() functions and > >> their friends. > > Ugh, yes. > > I did not change it because I

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

2021-09-29 Thread Dan Williams
reated as bool value. So when converting the authorized > > attribute from int to bool value, there should be no functional > > changes other than value 2 being not visible to the user. > > > > [1]: > > https://lore.kernel.org/all/CACK8Z6E8pjVeC934oFgr=vb3p

Re: [PATCH v2 1/3] /dev/mem: disallow access to explicitly excluded system RAM regions

2021-08-25 Thread Dan Williams
On Wed, Aug 25, 2021 at 12:23 AM David Hildenbrand wrote: > > On 25.08.21 02:58, Dan Williams wrote: > > On Mon, Aug 16, 2021 at 7:25 AM David Hildenbrand wrote: > >> > >> virtio-mem dynamically exposes memory inside a device memory region as > >

Re: [PATCH v2 1/3] /dev/mem: disallow access to explicitly excluded system RAM regions

2021-08-24 Thread Dan Williams
On Mon, Aug 16, 2021 at 7:25 AM David Hildenbrand wrote: > > virtio-mem dynamically exposes memory inside a device memory region as > system RAM to Linux, coordinating with the hypervisor which parts are > actually "plugged" and consequently usable/accessible. On the one hand, the > virtio-mem

Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}

2021-08-24 Thread Dan Williams
On Tue, Aug 24, 2021 at 2:57 PM Rajat Jain wrote: > > On Mon, Aug 23, 2021 at 6:06 PM Dan Williams wrote: > > > > On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan > > wrote: > > > > > > > > > > > > On 8/23/21 4:56 PM, Micha

Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}

2021-08-24 Thread Dan Williams
On Tue, Aug 24, 2021 at 1:50 PM Andi Kleen wrote: > > > On 8/24/2021 1:31 PM, Bjorn Helgaas wrote: > > On Tue, Aug 24, 2021 at 01:14:02PM -0700, Andi Kleen wrote: > >> On 8/24/2021 11:55 AM, Bjorn Helgaas wrote: > >>> [+cc Rajat; I still don't know what "shared memory with a hypervisor > >>> in a

Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}

2021-08-23 Thread Dan Williams
On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan wrote: > > > > On 8/23/21 4:56 PM, Michael S. Tsirkin wrote: > >> Add a new variant of pci_iomap for mapping all PCI resources > >> of a devices as shared memory with a hypervisor in a confidential > >> guest. > >> > >> Signed-off-by:

Re: [PATCH v2 4/4] bus: Make remove callback return void

2021-07-06 Thread Dan Williams
mented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-

Re: [RFC v2 PATCH 4/4] mm: pre zero out free pages to speed up page allocation for __GFP_ZERO

2021-01-04 Thread Dan Williams
On Mon, Jan 4, 2021 at 12:11 PM David Hildenbrand wrote: > > > > Am 04.01.2021 um 20:52 schrieb Dave Hansen : > > > > ´╗┐On 1/4/21 11:27 AM, Matthew Wilcox wrote: > >>> On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote: > >>> On 12/21/20 8:30 AM, Liang Li wrote: > ---

Re: [RFC v2 PATCH 4/4] mm: pre zero out free pages to speed up page allocation for __GFP_ZERO

2021-01-04 Thread Dan Williams
On Mon, Jan 4, 2021 at 11:28 AM Matthew Wilcox wrote: > > On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote: > > On 12/21/20 8:30 AM, Liang Li wrote: > > > --- a/include/linux/page-flags.h > > > +++ b/include/linux/page-flags.h > > > @@ -137,6 +137,9 @@ enum pageflags { > > > #endif >

Re: [PATCH mlx5-next v1 06/11] vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus

2020-11-04 Thread Dan Williams
On Wed, Nov 4, 2020 at 11:32 PM gregkh wrote: > > On Wed, Nov 04, 2020 at 03:21:23PM -0800, Dan Williams wrote: > > On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote: > > [..] > > > > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table); > > > >

Re: [PATCH mlx5-next v1 06/11] vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus

2020-11-04 Thread Dan Williams
On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote: [..] > > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table); > > + > > +static struct auxiliary_driver mlx5v_driver = { > > + .name = "vnet", > > + .probe = mlx5v_probe, > > + .remove = mlx5v_remove, > > + .id_table =

Re: [RFC] treewide: cleanup unreachable breaks

2020-10-17 Thread Dan Williams
/claim.c > +++ b/drivers/nvdimm/claim.c > @@ -200,11 +200,10 @@ ssize_t nd_namespace_store(struct device *dev, > } > break; > default: > len = -EBUSY; > goto out_attach; > - break; > } Acked-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-02 Thread Dan Williams
On Sat, May 2, 2020 at 2:27 AM David Hildenbrand wrote: > > >> Now, let's clarify what I want regarding virtio-mem: > >> > >> 1. kexec should not add virtio-mem memory to the initial firmware > >>memmap. The driver has to be in charge as discussed. > >> 2. kexec should not place kexec images

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 2:11 PM David Hildenbrand wrote: > > On 01.05.20 22:12, Dan Williams wrote: [..] > >>> Consider the case of EFI Special Purpose (SP) Memory that is > >>> marked EFI Conventional Memory with the SP attribute. In that case the &g

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 12:18 PM David Hildenbrand wrote: > > On 01.05.20 20:43, Dan Williams wrote: > > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote: > >> > >> On 01.05.20 20:03, Dan Williams wrote: > >>> On Fri, May 1, 2020 a

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote: > > On 01.05.20 20:03, Dan Williams wrote: > > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote: > >> > >> On 01.05.20 19:45, David Hildenbrand wrote: > >>> On 01.05.20 19:39, Dan Williams

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote: > > On 01.05.20 19:45, David Hildenbrand wrote: > > On 01.05.20 19:39, Dan Williams wrote: > >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote: > >>> > >>> On 01.05.20 18:56, Dan Willi

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote: > > On 01.05.20 18:56, Dan Williams wrote: > > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote: > >> > >> On 01.05.20 00:24, Andrew Morton wrote: > >>> On Thu, 30 Apr 2020 20:4

  1   2   >