Re: [RFC PATCH 1/9] kernel.h: add do_empty() macro

2020-04-18 Thread Bart Van Assche
On 4/18/20 11:41 AM, Randy Dunlap wrote: --- linux-next-20200327.orig/include/linux/kernel.h +++ linux-next-20200327/include/linux/kernel.h @@ -40,6 +40,14 @@ #define READ 0 #define WRITE 1 +/* + * When using -Wextra, an "if" statement followed by an

Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles

2019-09-12 Thread Bart Van Assche
On 9/12/19 8:34 AM, Joe Perches wrote: > On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote: >> On 9/11/19 5:40 PM, Martin K. Petersen wrote: >>> * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__") >>> and does not incur any zer

Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles

2019-09-12 Thread Bart Van Assche
On 9/11/19 5:40 PM, Martin K. Petersen wrote: > * Do not use custom To: and Cc: for individual patches. We want to see the > whole series, even patches that potentially need to go through a different > subsystem tree. Hi Martin, Thanks for having written this summary. This is very helpful.

Re: [Ksummit-discuss] [PATCH v2 0/3] Maintainer Entry Profiles

2019-09-12 Thread Bart Van Assche
On 9/11/19 4:48 PM, Dan Williams wrote: > At last years Plumbers Conference I proposed the Maintainer Entry > Profile as a document that a maintainer can provide to set contributor > expectations and provide fodder for a discussion between maintainers > about the merits of different maintainer

Re: [driver-core PATCH v6 9/9] libnvdimm: Schedule device registration on node local to the device

2018-11-27 Thread Bart Van Assche
On Tue, 2018-11-27 at 12:50 -0800, Dan Williams wrote: > Thanks Bart, so tying this back to Alex's patches, does the ordering > problem that Alex's patches solve impact the SCSI case? I'm looking > for something like "SCSI depends on asynchronous probing and without > 'driver core: Establish clear

Re: [driver-core PATCH v6 9/9] libnvdimm: Schedule device registration on node local to the device

2018-11-27 Thread Bart Van Assche
On Tue, 2018-11-27 at 11:34 -0800, Dan Williams wrote: > On Tue, Nov 27, 2018 at 10:04 AM Alexander Duyck > wrote: > > > > On Mon, 2018-11-26 at 18:21 -0800, Dan Williams wrote: > > > On Thu, Nov 8, 2018 at 10:07 AM Alexander Duyck > > > wrote: > > > > > > > > Force the device registration for

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-23 Thread Bart Van Assche
On 11/22/18 5:23 PM, Rong Chen wrote: Kbuild robot printed all warnings and the below warning was found in patch 5/9. "include/linux/device.h:1056: warning: Function parameter or member 'async_probe' not described in 'device'" Hi Rong, Thanks for having taken a look. That's indeed

Re: [driver-core PATCH v6 2/9] async: Add support for queueing on specific NUMA node

2018-11-11 Thread Bart Van Assche
On 11/11/18 12:33 PM, Greg KH wrote: When I see new major patches show up from an Intel developer without _any_ other review from anyone else, directed at me, I get suspicious it is happening again. Hi Greg, Please note that I reviewed this patch four days ago. See also

Re: [driver-core PATCH v6 6/9] driver core: Probe devices asynchronously instead of the driver

2018-11-08 Thread Bart Van Assche
> driver not be loaded until after the devices have already been added. Reviewed-by: Bart Van Assche ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [driver-core PATCH v6 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-08 Thread Bart Van Assche
move the above from the patch description since I think this part is no longer relevant. Anyway: Reviewed-by: Bart Van Assche ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-08 Thread Bart Van Assche
On Tue, 2018-11-06 at 17:34 -0800, Joe Perches wrote: > On Tue, 2018-11-06 at 15:48 -0800, Bart Van Assche wrote: > > On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote: > > > One change I made in addition is I replaced the use of "bool X:1" to > > > d

Re: [driver-core PATCH v6 2/9] async: Add support for queueing on specific NUMA node

2018-11-08 Thread Bart Van Assche
ork on specific NUMA nodes in order to > improve performance of memory initialization. Reviewed-by: Bart Van Assche ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [driver-core PATCH v5 2/9] async: Add support for queueing on specific NUMA node

2018-11-06 Thread Bart Van Assche
On Mon, 2018-11-05 at 13:11 -0800, Alexander Duyck wrote: > +/** > + * async_schedule_domain - schedule a function for asynchronous execution > within a certain domain > + * @func: function to execute asynchronously > + * @data: data pointer to pass to the function > + * @domain: the domain > + *

Re: [driver-core PATCH v5 9/9] libnvdimm: Schedule device registration on node local to the device

2018-11-06 Thread Bart Van Assche
mance numbers. Reviewed-by: Bart Van Assche ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [driver-core PATCH v5 8/9] PM core: Use new async_schedule_dev command

2018-11-06 Thread Bart Van Assche
> device that is sensitive to latency/locality in the setup will now be > initializing on the node closest to the device. Reviewed-by: Bart Van Assche ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [driver-core PATCH v5 7/9] driver core: Attach devices on CPU local to device node

2018-11-06 Thread Bart Van Assche
edule(__driver_attach_async_helper, dev); > + async_schedule_dev(__driver_attach_async_helper, dev); > } > device_unlock(dev); > return 0; Reviewed-by: Bart Van Assche ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [driver-core PATCH v5 6/9] driver core: Probe devices asynchronously instead of the driver

2018-11-06 Thread Bart Van Assche
On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote: > diff --git a/include/linux/device.h b/include/linux/device.h > index fc7091d436c2..4d9a39769081 100644 > --- a/include/linux/device.h > +++ b/include/linux/device.h > [ ... ] > +static inline struct device_driver *dev_get_drv_async(const

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-06 Thread Bart Van Assche
On Tue, 2018-11-06 at 12:10 +0800, kbuild test robot wrote: > Hi Alexander, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on driver-core/master] > > url: >

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-06 Thread Bart Van Assche
On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote: > One change I made in addition is I replaced the use of "bool X:1" to define > the bitfield to a "u8 X:1" setup in order to resolve some checkpatch > warnings. Please use "bool X:1" instead of "u8 X:1". I think it was a bad idea to make

Re: [driver-core PATCH v5 4/9] driver core: Move async_synchronize_full call

2018-11-06 Thread Bart Van Assche
On Tue, 2018-11-06 at 08:18 -0800, Alexander Duyck wrote: > On Mon, 2018-11-05 at 17:04 -0800, Bart Van Assche wrote: > > On Mon, 2018-11-05 at 13:11 -0800, Alexander Duyck wrote: > > > This patch moves the async_synchronize_full call out of > > > __device_release_dr

Re: [driver-core PATCH v5 4/9] driver core: Move async_synchronize_full call

2018-11-05 Thread Bart Van Assche
On Mon, 2018-11-05 at 13:11 -0800, Alexander Duyck wrote: > This patch moves the async_synchronize_full call out of > __device_release_driver and into driver_detach. > > The idea behind this is that the async_synchronize_full call will only > guarantee that any existing async operations are

Re: [driver-core PATCH v5 0/9] Add NUMA aware async_schedule calls

2018-11-05 Thread Bart Van Assche
On Mon, 2018-11-05 at 13:11 -0800, Alexander Duyck wrote: > This patch set provides functionality that will help to improve the > locality of the async_schedule calls used to provide deferred > initialization. Hi Alexander, Is this patch series perhaps available in a public git tree? That would

Re: [driver-core PATCH v5 1/9] workqueue: Provide queue_work_node to queue work near a given NUMA node

2018-11-05 Thread Bart Van Assche
select? > + /* If CPU is valid return that, otherwise just defer */ > + return (cpu < nr_cpu_ids) ? cpu : WORK_CPU_UNBOUND; Please leave out the superfluous parentheses if this patch series would have to be reposted. Anyway: Reviewed-b

Re: [PATCH v7 02/13] PCI/P2PDMA: Add sysfs group to display p2pmem stats

2018-09-25 Thread Bart Van Assche
On Tue, 2018-09-25 at 12:15 -0600, Logan Gunthorpe wrote: > On 2018-09-25 11:29 a.m., Bart Van Assche wrote: > > On Tue, 2018-09-25 at 10:22 -0600, Logan Gunthorpe wrote: > > > @@ -83,9 +132,14 @@ static int pci_p2pdma_setup(struct pci_dev *pdev) > > >

Re: [PATCH v7 03/13] PCI/P2PDMA: Add PCI p2pmem DMA mappings to adjust the bus offset

2018-09-25 Thread Bart Van Assche
On Tue, 2018-09-25 at 10:22 -0600, Logan Gunthorpe wrote: > +int pci_p2pdma_map_sg(struct device *dev, struct scatterlist *sg, int nents, > + enum dma_data_direction dir) > +{ > + struct dev_pagemap *pgmap; > + struct scatterlist *s; > + phys_addr_t paddr; > + int

Re: [PATCH v7 02/13] PCI/P2PDMA: Add sysfs group to display p2pmem stats

2018-09-25 Thread Bart Van Assche
On Tue, 2018-09-25 at 10:22 -0600, Logan Gunthorpe wrote: > @@ -83,9 +132,14 @@ static int pci_p2pdma_setup(struct pci_dev *pdev) > > pdev->p2pdma = p2p; > > + error = sysfs_create_group(>dev.kobj, _group); > + if (error) > + goto out_pool_destroy; > + > return

Re: [PATCH v2 08/10] nvme-pci: Add support for P2P memory in requests

2018-03-08 Thread Bart Van Assche
On Thu, 2018-03-01 at 15:58 +, Stephen Bates wrote: > > Any plans adding the capability to nvme-rdma? Should be > > straight-forward... In theory, the use-case would be rdma backend > > fabric behind. Shouldn't be hard to test either... > > Nice idea Sagi. Yes we have been starting to look

Re: [LSF/MM TOPIC] Filesystem-DAX, page-pinning, and RDMA

2018-01-24 Thread Bart Van Assche
On Wed, 2018-01-24 at 19:56 -0800, Dan Williams wrote: > The get_user_pages_longterm() api was recently added as a stop-gap > measure to prevent applications from growing dependencies on the > ability to to pin DAX-mapped filesystem blocks for RDMA indefinitely > with no ongoing coordination with

Re: [RFC 01/16] NOVA: Documentation

2017-08-04 Thread Bart Van Assche
On Thu, 2017-08-03 at 00:48 -0700, Steven Swanson wrote: > +### DAX Support > + > +Supporting DAX efficiently is a core feature of NOVA and one of the > challenges > +in designing NOVA is reconciling DAX support which aims to avoid file system > +intervention when file data changes, and other

Re: dm: enable opt-out of device-mapper dax support

2017-08-01 Thread Bart Van Assche
On Tue, 2017-08-01 at 13:59 -0700, Dan Williams wrote: > On Tue, Aug 1, 2017 at 12:45 PM, Dan Williams > wrote: > > On Tue, Aug 1, 2017 at 12:02 PM, Mike Snitzer wrote: > > > On Tue, Aug 01 2017 at 2:12pm -0400, > > > Dan Williams

Re: [resend PATCH v2 11/33] dm: add dax_device and dax_operations support

2017-07-28 Thread Bart Van Assche
On Mon, 2017-04-17 at 12:09 -0700, Dan Williams wrote: > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig > index b7767da50c26..1de8372d9459 100644 > --- a/drivers/md/Kconfig > +++ b/drivers/md/Kconfig > @@ -200,6 +200,7 @@ config BLK_DEV_DM_BUILTIN > config BLK_DEV_DM > tristate

Re: Enabling peer to peer device transactions for PCIe devices

2016-11-23 Thread Bart Van Assche
On 11/23/2016 09:13 AM, Logan Gunthorpe wrote: IMO any memory that has been registered for a P2P transaction should be locked from being evicted. So if there's a get_user_pages call it needs to be pinned until the put_page. The main issue being with the RDMA case: handling an eviction when a

Re: [PATCH v4 2/5] mmc: move 'parent' tracking to mmc_blk_data

2016-06-22 Thread Bart Van Assche
On 06/21/2016 10:46 PM, Dan Williams wrote: In preparation for the removal of 'driverfs_dev' from 'struct gendisk', carry this data in mmc_blk_data. It is used for registration of parent disks and partitions. Cc: Ulf Hansson <ulf.hans...@linaro.org> Reported-by: Bart Van Assche <ba

Re: [PATCH v4 3/5] um: track 'parent' device in a local variable

2016-06-22 Thread Bart Van Assche
ted-by: Bart Van Assche <bart.vanass...@sandisk.com> Signed-off-by: Dan Williams <dan.j.willi...@intel.com> --- arch/um/drivers/ubd_kern.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c index ef6b4d960