Re: [PATCH 07/14] infiniband: utilize new device_add_cdev helper function

On 21/02/17 12:09 PM, Jason Gunthorpe wrote: > On Mon, Feb 20, 2017 at 10:00:46PM -0700, Logan Gunthorpe wrote: >> This patch updates core/ucm.c which didn't originally use the >> cdev.kobj.parent with it's parent device. I did not look heavily into >> whether this was a bug

[PATCH 11/14] rapidio: utilize new device_add_cdev helper function

Note: the chardev instance in rio_mport_cdev originally did not set the kobject parent. Thus, I'm reasonably confident that because of this, this code would have suffered from a minor use after free bug if the cdev was open when the backing device was released. Signed-off-by: Logan Gunthorpe

[PATCH 06/14] platform/chrome: utilize new device_add_cdev helper function

Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/platform/chrome/cros_ec_dev.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/platform/chrome/cros_ec_dev.c b/drivers/platform/chrome/cros_ec_dev.c index 47268ec..658fb99 100644 --- a/d

[PATCH 04/14] gpiolib: utilize new device_add_cdev helper function

Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/gpio/gpiolib.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index a07ae9e..04dbc4a 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -

[PATCH 10/14] mtd: utilize new device_add_cdev helper function

Note: neither of the cdev instances in the mtd tree originally set the kobject parent. Thus, I'm reasonably confident that both these instances would have suffered from a minor use after free bug if the cdevs were open when the backing device was released. Signed-off-by: Logan Gunthorpe <

[PATCH 14/14] switchtec: utilize new device_add_cdev helper function

Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/pci/switch/switchtec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c index 82bfd18..95aabd0 100644 --- a/drivers/pci/switch/switchtec.c

[PATCH 08/14] iio:core: utilize new device_add_cdev helper function

Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/iio/industrialio-core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index aaca428..b0ef245 100644 --- a/drivers/iio/industrialio-

Re: [PATCH 01/14] chardev: add helper function to register char devs with a struct device

On 20/02/17 10:35 PM, Dmitry Torokhov wrote: > My only objection is to this statement. There is absolutely nothing that > prevents from calling device_unregister() first and cdev_del() later. > Refcounting will sort it all out. Yeah, I was really trying to warn people against calling cdev_del

Re: [PATCH 01/14] chardev: add helper function to register char devs with a struct device

Hey, Ok, I'll do a v2 later this week with some of the feedback and tags? Logan On 21/02/17 11:18 AM, Dan Williams wrote: > On Mon, Feb 20, 2017 at 10:35 PM, Logan Gunthorpe <log...@deltatee.com> wrote: >> >> >> On 20/02/17 10:35 PM, Dmitry Torokhov w

Re: [PATCH] device-dax: don't set kobj parent during cdev init

On 11/02/17 11:27 AM, Dan Williams wrote: > Why, when the lifetime of the cdev is already correct? Well, it's only correct if you use the kobj parent trick which Greg is arguing against. As someone reviewing/copying code that trick is unclear, undocumented and it looks rather odd messing with

Re: [PATCH] device-dax: don't set kobj parent during cdev init

On 11/02/17 11:58 AM, Dan Williams wrote: > Also when using an embedded cdev how would you recommend avoiding this > problem? I don't know. Hopefully, Greg has a good idea. But it sounds like a general problem that a lot of cdev's actually suffer from without realizing. Perhaps we need a more

[PATCH] device-dax: don't set kobj parent during cdev init

://lkml.org/lkml/2017/2/10/370 Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/dax/dax.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index ed758b7..24e53b7 100644 --- a/drivers/dax/dax.c +++ b/drivers/dax

Re: [PATCH] device-dax: don't set kobj parent during cdev init

Hey, Also on the subject of very minor fixes: I noticed drivers/dax is not in the maintainers file. I just assumed the nvdimm list should have been included with those from get_maintainers. Thanks, Logan On 10/02/17 12:19 PM, Logan Gunthorpe wrote: > I copied this code and per feedback f

[PATCH v2 01/16] chardev: add helper function to register char devs with a struct device

] https://lkml.org/lkml/2017/2/13/700 [2] https://lkml.org/lkml/2017/2/10/370 Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Dan Williams <dan.j.willi...@intel.com> --- fs/char_dev.c| 67 include/linux

[PATCH v2 12/16] mtd: utilize new cdev_device_add helper function

to use put_device in the error path which simplifies things a good deal. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mtd/ubi/build.c | 91 + drivers/mtd/ubi/vmt.c | 49 +- 2 files changed, 33 inse

[PATCH v2 10/16] iio:core: utilize new cdev_device_add helper function

, but this doesn't appear to be required in any way. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/iio/industrialio-core.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c

[PATCH v2 06/16] tpm-chip: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- d

[PATCH v2 11/16] media: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- d

[PATCH v2 16/16] switchtec: utilize new device_add_cdev helper function

Very straightforward conversion to device_add_cdev. Drop cdev_add and device_add and use cdev_device_add. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/pci/switch/switchtec.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drive

[PATCH v2 08/16] IB/ucm: utilize new cdev_device_add helper function

ve out of the struct device release function. This cleans up the error path significantly and thus also fixes a minor bug where the devnum would not be released if cdev_add failed. Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> Signed-off-by: Logan Gunthorpe <log.

[PATCH v2 15/16] scsi: utilize new cdev_device_add helper function

is also moved out of __remove and into unregister to simplify things and follow the pattern other devices are using. This also drop an extra unnecessary get_device/put_device in the code. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/osd/osd_uld.

[PATCH v2 03/16] device-dax: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- d

[PATCH v2 09/16] infiniband: utilize the new cdev_set_parent function

This replaces the suspect looking cdev.kobj.parent lines with the equivalent cdev_set_parent function. This is a straightforward change that's largely cosmetic but it does push the kobj.parent ownership into char_dev.c where it belongs. Signed-off-by: Logan Gunthorpe <log...@deltatee.

[PATCH v2 07/16] platform/chrome: cros_ec_dev - utilize new cdev_device_add helper function

function: we use put_device instead of kfree directly as recommended by the device_initialize documentation. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/platform/chrome/cros_ec_dev.c | 31 +++ 1 file changed, 7 insertions(+), 24 deletions(-)

Re: [PATCH 2/3] iopmem : Add a block device driver for PCIe attached IO memory.

Hi Christoph, Thanks so much for the detailed review of the code! Even though by the sounds of things we will be moving to device dax and most of this is moot. Still, it's great to get some feedback and learn a few things. I've given some responses below. On 28/10/16 12:45 AM, Christoph Hellwig

Re: Enabling peer to peer device transactions for PCIe devices

On 23/11/16 02:55 PM, Jason Gunthorpe wrote: >>> Only ODP hardware allows changing the DMA address on the fly, and it >>> works at the page table level. We do not need special handling for >>> RDMA. >> >> I am aware of ODP but, noted by others, it doesn't provide a general >> solution to the

Re: Enabling peer to peer device transactions for PCIe devices

On 23/11/16 01:33 PM, Jason Gunthorpe wrote: > On Wed, Nov 23, 2016 at 02:58:38PM -0500, Serguei Sagalovitch wrote: > >>We do not want to have "highly" dynamic translation due to >>performance cost. We need to support "overcommit" but would >>like to minimize impact. To support

Re: Enabling peer to peer device transactions for PCIe devices

Hey, On 24/11/16 02:45 AM, Christian König wrote: > E.g. it can happen that PCI device A exports it's BAR using ZONE_DEVICE. > Not PCI device B (a SATA device) can directly read/write to it because > it is on the same bus segment, but PCI device C (a network card for > example) can't because it

Re: Enabling peer to peer device transactions for PCIe devices

On 24/11/16 09:42 AM, Jason Gunthorpe wrote: > There are three cases to worry about: > - Coherent long lived page table mirroring (RDMA ODP MR) > - Non-coherent long lived page table mirroring (RDMA MR) > - Short lived DMA mapping (everything else) > > Like you say below we have to handle

Re: Enabling peer to peer device transactions for PCIe devices

Hey, On 06/12/16 09:38 AM, Jason Gunthorpe wrote: >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial >>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the >>> device-dax instance under the nvme device, or if you already have the nvme >>> sysfs path

Re: Enabling peer to peer device transactions for PCIe devices

On 11/01/17 09:54 PM, Stephen Bates wrote: > The iopmem patchset addressed all the use cases above and while it is not > an in kernel API it could have been modified to be one reasonably easily. > As Logan states the driver can then choose to pass the VMAs to user-space > in a manner that makes

Re: Enabling peer to peer device transactions for PCIe devices

On 05/12/16 12:46 PM, Jason Gunthorpe wrote: NVMe might have to deal with pci-e hot-unplug, which is a similar problem-class to the GPU case.. Sure, but if the NVMe device gets hot-unplugged it means that all the CMB mappings are useless and need to be torn down. This probably means

Re: Enabling peer to peer device transactions for PCIe devices

On 05/12/16 12:14 PM, Jason Gunthorpe wrote: But CMB sounds much more like the GPU case where there is a specialized allocator handing out the BAR to consumers, so I'm not sure a general purpose chardev makes a lot of sense? I don't think it will ever need to be as complicated as the GPU

Re: Enabling peer to peer device transactions for PCIe devices

On 05/12/16 11:08 AM, Dan Williams wrote: I've already recommended that iopmem not be a block device and instead be a device-dax instance. I also don't think it should claim the PCI ID, rather the driver that wants to map one of its bars this way can register the memory region with the

Re: Enabling peer to peer device transactions for PCIe devices

On 06/01/17 11:26 AM, Jason Gunthorpe wrote: > Make a generic API for all of this and you'd have my vote.. > > IMHO, you must support basic pinning semantics - that is necessary to > support generic short lived DMA (eg filesystem, etc). That hardware > can clearly do that if it can support

Re: Enabling peer to peer device transactions for PCIe devices

Hey, > Okay, so clearly this needs a kernel side NVMe specific allocator > and locking so users don't step on each other.. Yup, ideally. That's why device dax isn't ideal for this application: it doesn't provide any way to prevent users from stepping on each other. > Or as Christoph says some

[RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device

enabling it and wondering why their performance dropped. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <sba...@raithlin.com> Signed-off-by: Steve Wise <sw...@opengridcomputing.com> --- drivers/memory/Kconfig | 5 + drivers/memory/Makefile | 2

[RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

Now that we are using p2pmem SG buffers we occasionally have to copy to and from this memory. For this, we add an iomem flag to sg_copy_buffer for copying with iomemcpy. We also add the sg_iocopy_ variants to use this more easily. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Sign

[RFC 8/8] p2pmem: Added char device user interface

=mmapshared:/dev/p2pmem0 ioengine=rdma port=14242 bs=64k size=10G iodepth=2 which would test the bandwidth of RDMA to/from the specified p2p memory. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <sba...@raithlin.com> Signed-off-by: St

[RFC 3/8] nvmet: Use p2pmem in nvme target

. This would save an extra PCI transfer as the NVME card could just take the data out of it's own memory. However, at this time, cards with CMB buffers don't seem to be available. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <sba...@raithlin.com> Signed-o

[RFC 2/8] cxgb4: setup pcie memory window 4 and create p2pmem region

From: Steve Wise <sw...@opengridcomputing.com> Some cxgb4 cards expose memory as part of BAR4. This patch registers this memory as a p2pmem device. Signed-off-by: Steve Wise <sw...@opengridcomputing.com> Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by:

[RFC 7/8] p2pmem: Support device removal

device) will be used. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephen Bates <sba...@raithlin.com> Signed-off-by: Steve Wise <sw...@opengridcomputing.com> --- drivers/memory/p2pmem.c| 75 --- drivers/nvme/

[RFC 4/8] p2pmem: Add debugfs "stats" file

From: Steve Wise <sw...@opengridcomputing.com> For each p2pmem instance, add a "stats" file to show the gen_pool statistics. Signed-off-by: Steve Wise <sw...@opengridcomputing.com> Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Stephe

Re: [PATCH v3 01/16] chardev: add helper function to register char devs with a struct device

> I don't know why kbuild didn't catch these before, but it looks like we > really need to include device.h in cdev.h now to fix up these build > warnings, right? > I'll try that out and rebase the char-misc-testing tree in the morning > to see if that fixes the build problems... Yeah, I think

[PATCH v4 01/16] chardev: add helper function to register char devs with a struct device

] https://lkml.org/lkml/2017/2/13/700 [2] https://lkml.org/lkml/2017/2/10/370 Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Dan Williams <dan.j.willi...@intel.com> Reviewed-by: Hans Verkuil <hans.verk...@cisco.com> Reviewed-by: Alexandre Belloni <a

Re: [PATCH v3 16/16] switchtec: utilize new device_add_cdev helper function

On 16/03/17 02:42 AM, Greg Kroah-Hartman wrote: > As this file isn't in 4.11-rc1, I can't take this patch, but I took all > of the others. You should resend this to Bjorn after 4.12-rc1 is out. Yup, I expected this. I'll keep an eye out and make sure it gets in when the time comes. Thanks,

[PATCH v5 12/16] mtd: utilize new cdev_device_add helper function

to use put_device in the error path which simplifies things a good deal. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mtd/ubi/build.c | 91 + drivers/mtd/ubi/vmt.c | 49 +- 2 files changed, 33 inse

[PATCH v5 01/16] chardev: add helper function to register char devs with a struct device

] https://lkml.org/lkml/2017/2/13/700 [2] https://lkml.org/lkml/2017/2/10/370 Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Signed-off-by: Dan Williams <dan.j.willi...@intel.com> Reviewed-by: Hans Verkuil <hans.verk...@cisco.com> Reviewed-by: Alexandre Belloni <a

[PATCH v5 09/16] infiniband: utilize the new cdev_set_parent function

This replaces the suspect looking cdev.kobj.parent lines with the equivalent cdev_set_parent function. This is a straightforward change that's largely cosmetic but it does push the kobj.parent ownership into char_dev.c where it belongs. Signed-off-by: Logan Gunthorpe <log...@deltatee.

[PATCH v5 13/16] rapidio: utilize new cdev_device_add helper function

). We also remove an unnecessary extra get_device from the code. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/rapidio/devices/rio_mport_cdev.c | 24 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/drivers/rapidio/devices/rio_mport_

[PATCH v5 15/16] scsi: utilize new cdev_device_add helper function

is also moved out of __remove and into unregister to simplify things and follow the pattern other devices are using. This also drop an extra unnecessary get_device/put_device in the code. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/osd/osd_uld.

[PATCH v5 08/16] IB/ucm: utilize new cdev_device_add helper function

ve out of the struct device release function. This cleans up the error path significantly and thus also fixes a minor bug where the devnum would not be released if cdev_add failed. Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> Signed-off-by: Logan Gunthorpe <log.

[PATCH v5 11/16] media: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Acked-by

[PATCH v5 03/16] device-dax: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Re

[PATCH v5 16/16] switchtec: utilize new device_add_cdev helper function

Very straightforward conversion to device_add_cdev. Drop cdev_add and device_add and use cdev_device_add. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/pci/switch/switchtec.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/pci/

[PATCH v5 14/16] rtc: utilize new cdev_device_add helper function

this by avoiding calling cdev_add if the devt is not set. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com> --- drivers/rtc/class.c| 14 ++ drivers/rtc/rtc-core.h | 10 -- drivers/rtc/rtc

[PATCH v5 10/16] iio:core: utilize new cdev_device_add helper function

, but this doesn't appear to be required in any way. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/iio/industrialio-core.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c

[PATCH v5 00/16] Cleanup chardev instances with helper function

n Williams (1): device-dax: fix cdev leak Jason Gunthorpe (1): IB/ucm: utilize new cdev_device_add helper function Logan Gunthorpe (14): chardev: add helper function to register char devs with a struct device device-dax: utilize new cdev_device_add helper function input: utilize new cd

[PATCH v5 02/16] device-dax: fix cdev leak

.willi...@intel.com> Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Reviewed-by: Johannes Thumshirn <jthumsh...@suse.de> --- drivers/dax/dax.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c index 8d9829f

[PATCH v5 05/16] gpiolib: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Re

[PATCH v5 06/16] tpm-chip: utilize new cdev_device_add helper function

Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Re

Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device

Hey, On 31/03/17 08:17 PM, ok...@codeaurora.org wrote: > See drivers/pci and drivers/acpi directory. The best I could find was the date of the firmware/bios. I really don't think that makes sense to tie the two together. And really the more that I think about it trying to do a date cutoff for

Re: [RFC 2/8] cxgb4: setup pcie memory window 4 and create p2pmem region

On 04/04/17 04:42 AM, Sagi Grimberg wrote: > This is weird, why even call this if !use_p2pmem? I personally find it cleaner than: if (use_p2pmem) setup_memwin_p2pmem(...) I'm not sure why that's so weird. Logan ___ Linux-nvdimm mailing list

Re: [RFC 3/8] nvmet: Use p2pmem in nvme target

On 04/04/17 04:40 AM, Sagi Grimberg wrote: > Hey Logan, > >> We create a configfs attribute in each nvme-fabrics target port to >> enable p2p memory use. When enabled, the port will only then use the >> p2p memory if a p2p memory device can be found which is behind the >> same switch as the

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

On 04/04/17 04:59 AM, Sagi Grimberg wrote: > We can never ever get here from an IO command, and that is a good thing > because it would have been broken if we did, regardless of what copy > method we use... Yes, I changed this mostly for admin commands. I did notice connect commands do end up

Re: [RFC 4/8] p2pmem: Add debugfs "stats" file

On 04/04/17 04:46 AM, Sagi Grimberg wrote: > >> +p2pmem_debugfs_root = debugfs_create_dir("p2pmem", NULL); >> +if (!p2pmem_debugfs_root) >> +pr_info("could not create debugfs entry, continuing\n"); >> + > > Why continue? I think it'd be better to just fail it. Yup, agreed.

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

b435a154a4ec4f82766f6ab838092c3c5a9388ac Author: Logan Gunthorpe <log...@deltatee.com> Date: Wed Feb 8 12:44:52 2017 -0700 scatterlist: Add support for iomem pages This patch steals another bit from the page_link field to indicate the sg points to iomem. In sg_copy_buffer we use this flag to

Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device

On 31/03/17 12:49 PM, Sinan Kaya wrote: > Don't you need to clean up the p->pool here. See Patch 7 in the series. >> +put_device(>dev); >> +} >> +EXPORT_SYMBOL(p2pmem_unregister); >> + > > I don't like the ugliness around the switch port to be honest. > > Going to whitelist/blacklist

Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device

On 01/04/17 08:26 PM, Sinan Kaya wrote: > I recommended a combination of blacklist + p2p capability + BIOS date. > Not just BIOS date. BIOS date by itself is useless. Well this proposal doesn't work for me at all. None of my hardware has the p2p ACS capability and my BIOS date is in 2013 and

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

On 05/04/17 11:33 PM, Sagi Grimberg wrote: > >>> Note that the nvme completion queues are still on the host memory, so >>> this means we have lost the ordering between data and completions as >>> they go to different pcie targets. >> >> Hmm, in this simple up/down case with a switch, I think it

Re: [RFC 3/8] nvmet: Use p2pmem in nvme target

Hey Sagi, On 05/04/17 11:47 PM, Sagi Grimberg wrote: > Because the user can get it wrong, and its our job to do what we can in > order to prevent the user from screwing itself. Well, "screwing" themselves seems a bit strong. It wouldn't be much different from a lot of other tunables in the

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 12/04/17 03:55 PM, Benjamin Herrenschmidt wrote: > Look at pcibios_resource_to_bus() and pcibios_bus_to_resource(). They > will perform the conversion between the struct resource content (CPU > physical address) and the actual PCI bus side address. Ah, thanks for the tip! On my system, this

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 16/04/17 04:32 PM, Benjamin Herrenschmidt wrote: >> I'll consider this. Given the fact I can use your existing >> get_dev_pagemap infrastructure to look up the p2pmem device this >> probably isn't as hard as I thought it would be anyway (we probably >> don't even need a page flag). We'd just

[PATCH 18/22] mmc: spi: Make use of the new sg_map helper function

We use the sg_map helper but it's slightly more complicated as we only check for the error when the mapping actually gets used. Such that if the mapping failed but wasn't needed then no error occurs. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/mmc_spi.

[PATCH 01/22] scatterlist: Introduce sg_map helper functions

, a few of the existing kmap(sg_page) users play things a bit loose in terms of whether they apply sg->offset so using these helper functions should help avoid such issues. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/dma-buf/dma-buf.c | 3 ++ include/linux/scatterli

[PATCH 19/22] mmc: tmio: Make use of the new sg_map helper function

Straightforward conversion to sg_map helper. A couple paths will WARN if the memory does not end up being mappable. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/tmio_mmc.h | 12 ++-- drivers/mmc/host/tmio_mmc_dma.c | 5 + drivers/mm

[PATCH 14/22] scsi: arcmsr, ips, megaraid: Make use of the new sg_map helper function

Very straightforward conversion of three scsi drivers Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/arcmsr/arcmsr_hba.c | 16 drivers/scsi/ips.c | 8 drivers/scsi/megaraid.c | 9 +++-- 3 files changed, 23 inse

[PATCH 06/22] crypto: hifn_795x: Make use of the new sg_map helper function

t t->offset is likely always zero anyway. So, this patch cleans that brokeness up. Also, a change to the error path: if ablkcipher_get failed, everything seemed to proceed as if it hadn't. Setting 'error' should hopefully clear that up. Signed-off-by: Logan Gunthorpe <log...@deltatee.com>

[PATCH 04/22] target: Make use of the new sg_map function at 16 call sites

with this driver. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/target/iscsi/iscsi_target.c| 27 +--- drivers/target/target_core_rd.c| 3 +- drivers/target/target_core_sbc.c | 122 +++-- drivers/target/target_core_transport.c

[PATCH 05/22] drm/i915: Make use of the new sg_map helper function

This is a single straightforward conversion from kmap to sg_map. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/gpu/drm/i915/i915_gem.c | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/d

[PATCH 02/22] nvmet: Make use of the new sg_map helper function

This is a straight forward conversion in two places. Should kmap fail, the code will return an INVALD_DATA error in the completion. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/nvme/target/fabrics-cmd.c | 16 1 file changed, 12 insertions(+), 4 del

[PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

Straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c b/d

[PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function

The get_page in this area looks *highly* suspect due to there being no corresponding put_page. However, I've left that as is to avoid breaking things. I've also removed the KMAP_ATOMIC_ARGS check as it appears to be dead code that dates back to when it was first committed... Signed-off-by: Logan

[PATCH 15/22] scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers

These two drivers appear to duplicate the functionality of sg_copy_buffer. So we clean them up to use the common code. This helps us remove a couple of instances that would otherwise be slightly tricky sg_map usages. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/cs

[PATCH 12/22] scsi: ipr, pmcraid, isci: Make use of the new sg_map helper in 4 call sites

Very straightforward conversion of three scsi drivers. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/scsi/ipr.c | 27 ++- drivers/scsi/isci/request.c | 42 +- drivers/scsi/pmcraid.c

[PATCH 20/22] mmc: sdricoh_cs: Make use of the new sg_map helper function

This is a straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/sdricoh_cs.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c

[PATCH 21/22] mmc: tifm_sd: Make use of the new sg_map helper function

of the offset but it's already added and used earlier in the code. There's also no error path, so if unmappable memory finds its way into the sgl we can only WARN. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/tifm_sd.

[PATCH 22/22] memstick: Make use of the new sg_map helper function

Straightforward conversion, but we have to WARN if unmappable memory finds its way into the sgl. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/memstick/host/jmb38x_ms.c | 23 ++- drivers/memstick/host/tifm_ms.c | 22 +- 2 files c

[PATCH 17/22] mmc: sdhci: Make use of the new sg_map helper function

Straightforward conversion, except due to the lack of error path we have to WARN if the memory in the SGL is not mappable. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> --- drivers/mmc/host/sdhci.c | 35 ++- 1 file changed, 30 insertions(+), 5 del

Re: [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On 13/04/17 10:59 PM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote: >> This is a straight forward conversion in two places. Should kmap fail, >> the code will return an INVALD_DATA error in the completion. > > It r

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 19/04/17 12:11 PM, Logan Gunthorpe wrote: > > > On 19/04/17 11:41 AM, Dan Williams wrote: >> No, not quite ;-). I still don't think we should require the non-HMM >> to pass NULL for all the HMM arguments. What I like about Logan's >> proposal is to have a separat

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 19/04/17 12:30 PM, Dan Williams wrote: > Letting others users do the container_of() arrangement means that > struct page_map needs to become public and move into struct > dev_pagemap directly. Ah, yes, I got a bit turned around by that and failed to notice that page_map and dev_pagemap are

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 19/04/17 01:31 PM, Jason Gunthorpe wrote: > Try it with VT-D turned on. It shouldn't work or there is a notable > security hole in your platform.. Ah, ok. >>> const struct dma_map_ops *comp_ops = get_dma_ops(completer); >>> const struct dma_map_ops *init_ops =

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

Thanks, Benjamin, for the summary of some of the issues. On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote > So I assume the p2p code provides a way to address that too via special > dma_ops ? Or wrappers ? Not at this time. We will probably need a way to ensure the iommus do not attempt to

Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

On 14/04/17 02:36 AM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote: >> Convert the kmap and kmap_atomic uses to the sg_map function. We now >> store the flags for the kmap instead of a boolean to indicate >> atomicitiy. We also

Re: [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

Great, thanks! Logan On 14/04/17 10:07 AM, Kershner, David A wrote: > Can you add Acked-by for this patch? > > Acked-by: David Kershner > > Tested on s-Par and no problems. > > Thanks, > David Kershner > >> --- >> drivers/staging/unisys/visorhba/visorhba_main.c

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 15/04/17 09:01 PM, Benjamin Herrenschmidt wrote: > Are ZONE_DEVICE pages identifiable based on the struct page alone ? (a > flag ?) Well you can't use ZONE_DEVICE as an indicator. They may be regular RAM, (eg. pmem). It would need a separate flag indicating it is backed by iomem. Logan

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 15/04/17 04:17 PM, Benjamin Herrenschmidt wrote: > You can't. If the iommu is on, everything is remapped. Or do you mean > to have dma_map_* not do a remapping ? Well, yes, you'd have to change the code so that iomem pages do not get remapped and the raw BAR address is passed to the DMA

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 16/04/17 09:53 AM, Dan Williams wrote: > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve > context about the physical address in question. I'm thinking you can > hang bus address translation data off of that structure. This seems > vaguely similar to what HMM is doing.

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 16/04/17 09:44 AM, Dan Williams wrote: > I think we very much want the dma mapping layer to be in the way. > It's the only sane semantic we have to communicate this translation. Yes, I wasn't proposing bypassing that layer, per say. I just meant that the layer would, in the end, have to

  1   2   3   4   5   >