On 25/11/16 06:06 AM, Christian König wrote:
> Well Serguei send me a couple of documents about QPI when we started to
> discuss this internally as well and that's exactly one of the cases I
> had in mind when writing this.
>
> If I understood it correctly for such systems P2P is technical
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
Hey,
On 22/11/16 11:59 AM, Serguei Sagalovitch wrote:
> - How well we will be able to handle case when we need to "move"/"evict"
>memory/data to the new location so CPU pointer should point to the
> new physical location/address
> (and may be not in PCI device memory at all)?
IMO any
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
On 28/11/16 09:57 AM, Jason Gunthorpe wrote:
>> On PeerDirect, we have some kind of a middle-ground solution for pinning
>> GPU memory. We create a non-ODP MR pointing to VRAM but rely on
>> user-space and the GPU not to migrate it. If they do, the MR gets
>> destroyed immediately.
>
> That
On 28/11/16 12:35 PM, Serguei Sagalovitch wrote:
> As soon as PeerDirect mapping is called then GPU must not "move" the
> such memory. It is by PeerDirect design. It is similar how it is works
> with system memory and RDMA MR: when "get_user_pages" is called then the
> memory is pinned.
We
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
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
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
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
On 30/11/16 09:23 AM, Jason Gunthorpe wrote:
>> Two cases I can think of are RDMA access to an NVMe device's controller
>> memory buffer,
>
> I'm not sure on the use model there..
The NVMe fabrics stuff could probably make use of this. It's an
in-kernel system to allow remote access to an NVMe
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
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
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
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
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
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
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.
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
). 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_
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
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.
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
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(-)
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
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
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
,
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
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.
Replace the open coded registration of the cdev and dev with the
new device_add_cdev() helper in evdev, joydev and mousedev. 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 <
] 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
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/
.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
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>
Straightforward conversion to the new helper, except due to
the lack of error path, we have to warn if unmapable memory
is ever present in the sgl.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
---
drivers/block/xen-blkfront.c | 33 +++--
1 file chang
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
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
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
Very straightforward conversion to the new function in all four spots.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
---
drivers/md/dm-crypt.c | 38 +-
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers
Very straightforward conversion of three scsi drivers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
---
drivers/scsi/gdth.c| 9 +++--
drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 14 +-
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 13 +
d
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
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
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
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
, 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
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
Straightforward conversion except there's no error path, so we WARN if
the sg_map fails.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
---
net/rds/ib_recv.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
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 propogate a possible kmap error down and create
a new ISCSI_TCP_INTERNAL_ERR error type for this.
Signed-off-by: Logan Gunthorpe <
Very straightforward conversion to the new function in two crypto
drivers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
---
crypto/shash.c| 9 ++---
drivers/crypto/caam/caamalg.c | 8 +++-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/
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
certainly open to other suggestions to get
it merged.
The patchset is based on v4.11-rc6 and can be found in the sg_map
branch from this git tree:
https://github.com/sbates130272/linux-p2pmem.git
Thanks,
Logan
Logan Gunthorpe (22):
scatterlist: Introduce sg_map helper functions
nvmet: Make
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
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.
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
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.
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
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
] renaming it and pushing this patch ASAP.
To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)
[1] https://www.spinics.net/lists/target-devel/msg15070.html
Signed-off-by: Logan Gunthorpe <log...@deltatee.
Thanks for the information Milan.
On 15/04/17 06:10 AM, Milan Broz wrote:
> I think your patch is ok (if it is just plain conversion), if it is
> really needed, we can switch to ahash later in follow-up patch.
Sounds good to me.
> p.s.
> there is a lot of lists on cc, but for this patch is
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
gt;
> Hi Logan,
>
> [auto build test WARNING on scsi/for-next]
> [also build test WARNING on v4.11-rc6]
> [cannot apply to next-20170413]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https
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
On 14/04/17 02:35 AM, Christoph Hellwig wrote:
>> +
>> static inline int is_dma_buf_file(struct file *);
>>
>> struct dma_buf_list {
>
> I think the right fix here is to rename the operation to unmap_atomic
> and send out a little patch for that ASAP.
Ok, I can do that next week.
> I'd
On 14/04/17 02:39 AM, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote:
>> Very straightforward conversion to the new function in all four spots.
>
> I think the right fix here is to switch dm-crypt to the ahash API
> that takes a
imited as
it was, I had mailing lists yelling at me). My plan was to get buy in
for the first patch, get it merged and resend the rest independently to
their respective maintainers. Of course, though, I'd be open to other
suggestions.
>>>
>>> Signed-off-by: Logan Guntho
On 18/04/17 09:50 AM, Konrad Rzeszutek Wilk wrote:
> I am not sure if you know, but you can add on each patch the respective
> maintainer via 'CC'. That way you can have certain maintainers CCed only
> on the subsystems they cover. You put it after (or before) your SoB and
> git send-email
On 18/04/17 12:44 AM, Daniel Vetter wrote:
> On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote:
>> This is a single straightforward conversion from kmap to sg_map.
>>
>> Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
>
> Acked-by: Dani
it and pushing this patch ASAP.
To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)
[1] https://www.spinics.net/lists/target-devel/msg15070.html
Signed-off-by: Logan Gunthorpe <log...@deltatee.
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, I'll work up a draft proposal and send it in a couple days. But
without a lot of cleanup such as this series it's not going
On 27/04/17 12:53 AM, Christoph Hellwig wrote:
> I think you'll need to follow the existing kmap semantics and never
> fail the iomem version either. Otherwise you'll have a special case
> that's almost never used that has a different error path.
>
> Again, wrong way. Suddenly making things
On 26/04/17 09:56 PM, Herbert Xu wrote:
> On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
>> Very straightforward conversion to the new function in the caam driver
>> and shash library.
>>
>> Signed-off-by: Logan Gunthorpe <log...@deltate
On 27/04/17 09:27 AM, Jason Gunthorpe wrote:
> On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote:
> How about first switching as many call sites as possible to use
> sg_copy_X_buffer instead of kmap?
Yeah, I could look at doing that first.
One problem is we might get more Naks
On 26/04/17 02:59 AM, wrote:
> Good to know that somebody is working on this. Those problems troubled
> us as well.
Thanks Christian. It's a daunting problem and a there's a lot of work to
do before we will ever be where we need to be so any help, even an ack,
is greatly appreciated.
Logan
This is a prep patch to add a new error code to libiscsi. We want to
rework some kmap calls to be able to fail. When we do, we'd like to
use this error code.
This patch simply introduces ISCSI_TCP_INTERNAL_ERR and prints
"Internal Error." when it gets hit.
Signed-off-by: Logan Gunt
.
Also, in terms of cleanup, 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>
---
include/linux/scatterli
Very straightforward conversion to the new function in all four spots.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Alasdair Kergon <a...@redhat.com>
Cc: Mike Snitzer <snit...@redhat.com>
---
drivers/md/dm-crypt.c | 39 ++-
This is a single straightforward conversion from kmap to sg_map.
We also create the i915_gem_object_unmap function to common up the
unmap code.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
---
drivers/gpu/drm/i915/i91
of the offset but it's already added and
used earlier in the code.)
There's also no error path, so we use SG_MAP_MUST_NOT_FAIL which may
BUG_ON in certain cases in the future.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Alex Dubov <oa...@yahoo.com>
Cc: Ulf Hansson <ulf.han
Straightforward conversion to the new helper, except due to the lack
of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in
certain cases in the future.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juerge
Very straightforward conversion of three scsi drivers
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Adaptec OEM Raid Solutions <aacr...@adaptec.com>
Cc: Kashyap Desai <kashyap.de...@broadcom.com>
Cc: Sumit Saxena <sumit.sax...@broadcom.com>
Cc: Shivasharan S
Very straightforward conversion of three scsi drivers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Achim Leubner <achim_leub...@adaptec.com>
Cc: John Garry <john.ga...@huawei.com>
---
drivers/scsi/gdth.c| 9 +++--
drivers/scsi/hisi_sas/his
This is a straightforward conversion to the new function.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Sascha Sommer <saschasom...@freenet.de>
Cc: Ulf Hansson <ulf.hans...@linaro.org>
---
drivers/mmc/host/sdricoh_cs.c | 14 +-
1 file changed, 9 insertio
Straightforward conversion except there's no error path, so we
make use of SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases
in the future.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Santosh Shilimkar <santosh.shilim...@oracle.com>
Cc: "David S. Miller"
Very straightforward conversion of three scsi drivers.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Brian King <brk...@us.ibm.com>
Cc: Artur Paszkiewicz <artur.paszkiew...@intel.com>
---
drivers/scsi/ipr.c | 27 ++-
drivers/scsi/i
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>
Cc: Ulf Hansson <ulf.hans...@l
Straightforward conversion to the new function.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Acked-by: David Kershner <david.kersh...@unisys.com>
---
drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --g
Straightforward conversion, but we have to make use of
SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases
in the future.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Alex Dubov <oa...@yahoo.com>
---
drivers/memstick/host/jmb38x_ms.c | 11 ++-
drivers/m
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>
Cc
Very straightforward conversion to the new function in the caam driver
and shash library.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
---
crypto/shash.c|
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>
Cc: Johannes Thumsh
and then I can send the individual subsystem
patches on to their respective maintainers and get them merged
independantly. (This is to avoid the conflicts I created with my last
cleanup set... Sorry) Though, I'm certainly open to other suggestions to get
it merged.
Logan Gunthorpe (21
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 use ISCSI_TCP_INTERNAL_ERR error type that was prepared
earlier for this.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Lee Duncan
with this driver.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: "Nicholas A. Bellinger" <n...@linux-iscsi.org>
---
drivers/target/iscsi/iscsi_target.c| 29 +++---
drivers/target/target_core_rd.c| 3 +-
drivers/target/target_
Straightforward conversion, except due to the lack of an error path we
have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain cases
in the future.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Adrian Hunter <adrian.hun...@intel.com>
Cc: Ulf Hansson <ulf.han
Straightforward conversion to sg_map helper. Seeing there is no
cleare error path, SG_MAP_MUST_NOT_FAIL which may BUG_ON in certain
cases in the future.
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Cc: Wolfram Sang <wsa+rene...@sang-engineering.com>
Cc: Ulf Hansson <ulf.han
On 28/04/17 12:30 AM, Herbert Xu wrote:
> You are right. Indeed the existing code looks buggy as they
> don't take sg->offset into account when doing the kmap. Could
> you send me some patches that fix these problems first so that
> they can be easily backported?
Ok, I think the only buggy
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, what follows is a draft patch attempting to show where I'm thinking
of going with this. Obviously it will not compile because
On 28/04/17 11:51 AM, Herbert Xu wrote:
> On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote:
>>
>>
>> On 28/04/17 12:30 AM, Herbert Xu wrote:
>>> You are right. Indeed the existing code looks buggy as they
>>> don't take sg->offset into a
On 27/04/17 04:11 PM, Jason Gunthorpe wrote:
> On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> Well, that is in the current form, with more users it would make sense
> to optimize for the single page case, eg by providing the existing
> call, providing a faster
On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
> blkfront is one of the drivers I looked at, and it appears to only be
> memcpying with the bvec_data pointer, so I wonder why it does not use
> sg_copy_X_buffer instead..
Yes, sort of...
But you'd potentially end up calling sg_copy_to_buffer
1 - 100 of 115 matches
Mail list logo