When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up copying
(luckily zeroed-out) kernel buffer to userspace instead of reporting
error. Fix the problem by jumping to the right label.
CC: Jens Axboe ax...@kernel.dk
CC:
On 10/22/2014 12:04 AM, James Bottomley wrote:
On Tue, 2014-10-21 at 17:05 +0300, Boaz Harrosh wrote:
Hi Sir Linus
A small administrative stuff, was on vacation and the old email bounced on
me.
I was hoping to still make the 3 weeks merge window, but it was 2 weeks at
the
end.
Your call
Hi
I uploaded the new version of SCSI/device-mapper XCOPY patches here:
http://people.redhat.com/~mpatocka/patches/kernel/xcopy/series.html
I am also sending the patches in the following emails.
Mikulas
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a
The target can set the function num_write_bios - dm will issue this
callback to ask the target how many bios does it want to receive.
This was intended for the dm-cache target, but it is not useable due to a
race condition (see the description of
e2e74d617eadc15f601983270c4f4a6935c5a943).
The function bio_batch_end_io ignores -EOPNOTSUPP. It doesn't matter for
discard (the device isn't required to discard anything, so missing the
error code and reporting success shouldn't cause any trouble). However,
for WRITE SAME command, missing the error code is obviously wrong. It may
fool the
This function can be used if the target needs to receive another duplicate
of the current bio.
Signed-off-by: Mikulas Patocka mpato...@redhat.com
---
drivers/md/dm.c | 24 +++-
include/linux/device-mapper.h |2 ++
2 files changed, 21 insertions(+), 5
This patch changes the architecture of xcopy so that two bios are used.
There used to be just one bio that held pointers to both source and
destination block device. However a bio with two block devices cannot
really be passed though block midlayer drivers (dm and md).
When we need to send the
This is Martin Petersen's xcopy patch
(https://git.kernel.org/cgit/linux/kernel/git/mkp/linux.git/commit/?h=xcopyid=0bdeed274e16b3038a851552188512071974eea8)
with some bug fixes, ported to the current kernel.
This patch makes it possible to use the SCSI XCOPY command.
We create a bio that has
The block layer creates two bios for each copy operation. The bios travel
independently through the storage stack and they are paired at the block
device.
There is a theoretical problem with this - the block device stack only
guarantees forward progress for a single bio. When two bios are sent,
In dm-snapshot target there may be large number of copy requests in
progress. If every pending copy request consumed a process context, it
would put too much load on the system.
To avoid this load, we need asynchronous notification when copy finishes -
we can pass a callback to the function
We use merge_bvec_fn to make sure that copies do not split internal
boundaries of device mapper devices.
There is no possibility to split a copy bio (splitting would complicate
the design significantly), so we must use merge_bvec_fn to make sure that
the bios have appropriate size for the device
This patch suppresses error messages when copying between two arrays that
support XCOPY each, but that cannot copy data between each other.
Signed-off-by: Mikulas Patocka mpato...@redhat.com
---
drivers/scsi/sd.c | 12
1 file changed, 12 insertions(+)
Index:
If xcopy between two devices fails, it is pointless to send more xcopy
command between there two devices because they take time and they will
likely also fail.
This patch keeps a cache of (source_device,destination_device) pairs where
copying failed and makes sure that no xcopy command is sooner
This patch implements basic copy support for device mapper core.
Individual targets can enable copy support by setting ti-copy_supported.
Device mapper device advertises copy support if at least one target
supports copy and for this target, at least one underlying device supports
copy.
Support copy operation in the linear target.
Signed-off-by: Mikulas Patocka mpato...@redhat.com
---
drivers/md/dm-linear.c |1 +
1 file changed, 1 insertion(+)
Index: linux-3.16-rc4/drivers/md/dm-linear.c
===
---
Support the copy operation for the stripe target.
In stripe_merge, we verify that the underlying device supports copy. If it
doesn't, we can fail fast without any bio being contructed.
Signed-off-by: Mikulas Patocka mpato...@redhat.com
---
drivers/md/dm-stripe.c | 11 ++-
1 file
This patch adds copy offload support to dm-kcopyd. If copy offload fails,
copying is performed using dm-io, just like before.
There is a module parameter copy_offload that can be set to enable or
disable this feature. It can be used to test performance of copy offload.
Signed-off-by: Mikulas
We move some code to a function submit_job. It is needed for the next
patch that calls submit_job from another place.
Signed-off-by: Mikulas Patocka mpato...@redhat.com
---
drivers/md/dm-kcopyd.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
Index:
job-lock is only taken for a finite amount of time and the process
doesn't block while holding it, so change it from mutex to spinlock.
This change is needed for the next patch that makes it possible to call
segment_complete from an interrupt. Taking mutexes inside an interrupt is
not allowed.
Change dm kcopyd so that it calls blkdev_issue_copy with an asynchronous
callback. There can be large number of pending kcopyd requests and holding
a process context for each of them may put too much load on the workqueue
subsystem.
This patch changes it so that blkdev_issue_copy returns after it
On 10/22/2014 01:30 AM, Jan Kara wrote:
When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up copying
(luckily zeroed-out) kernel buffer to userspace instead of reporting
error. Fix the problem by jumping to the right label.
See below ...
On 14-10-22 03:26 PM, Mikulas Patocka wrote:
This is Martin Petersen's xcopy patch
(https://git.kernel.org/cgit/linux/kernel/git/mkp/linux.git/commit/?h=xcopyid=0bdeed274e16b3038a851552188512071974eea8)
with some bug fixes, ported to the current kernel.
This patch makes it
If you are convinced that dropping the null tests is a good idea, then you
can submit the patch that makes the change to the relevant maintainers and
mailing lists.
I resent the request once more because another Triple-X software development
adventure might follow ...?
Regards,
Markus
On 08/25/2014 11:34 AM, Song Liu wrote:
From: Song Liu [mailto:songliubrav...@fb.com]
Sent: Monday, August 25, 2014 10:26 AM
To: Song Liu
Subject: [PATCH 0/5] Feature enhancements for ses module
These patches include a few enhancements to ses module:
1: close potential race condition by
-Original Message-
From: Bart Van Assche [mailto:bvanass...@acm.org]
Sent: Tuesday, 07 October, 2014 8:07 AM
...
@@ -1927,7 +1931,7 @@ static int srp_queuecommand(struct Scsi_Host
*shost, struct scsi_cmnd *scmnd)
cmd-opcode = SRP_CMD;
cmd-lun= cpu_to_be64((u64)
On 14-10-22 09:12 PM, Jens Axboe wrote:
On 08/25/2014 11:34 AM, Song Liu wrote:
From: Song Liu [mailto:songliubrav...@fb.com]
Sent: Monday, August 25, 2014 10:26 AM
To: Song Liu
Subject: [PATCH 0/5] Feature enhancements for ses module
These patches include a few enhancements to ses module:
1:
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
Sent: Tuesday, 03 June, 2014 6:23 AM
To: James Bottomley
Cc: Christoph Hellwig; linux-scsi@vger.kernel.org; Hannes Reinecke
Subject: [PATCH 6/6] scsi:
Hi Doug,
I am not sure whether I fully understand the scenario. Actually patch 5 tries
to clear all reserved bits:
+ dest_desc[0] = 0;
+ /* only clear byte 1 for ENCLOSURE_COMPONENT_DEVICE */
+ if (ecomp-type == ENCLOSURE_COMPONENT_DEVICE)
+ dest_desc[1] = 0;
+ dest_desc[2] = 0xde;
+
On 14-10-23 01:01 AM, Song Liu wrote:
Hi Doug,
I am not sure whether I fully understand the scenario. Actually patch 5 tries
to clear all reserved bits:
+ dest_desc[0] = 0;
+ /* only clear byte 1 for ENCLOSURE_COMPONENT_DEVICE */
+ if (ecomp-type == ENCLOSURE_COMPONENT_DEVICE)
+
Sitsofe == Sitsofe Wheeler sits...@gmail.com writes:
Last time around we identified this as a problem with Microsoft's
interpretation of the T10 SBC spec. And they promised that they are
going to fix that.
Sitsofe OK but if we were happy to wait for Microsoft to fix the
Sitsofe problem on
Sitsofe == Sitsofe Wheeler sits...@gmail.com writes:
Sitsofe 2. On top of the above, when a disk is small (has less than
Sitsofe2^32 sectors which is typically 2 TBytes in size) READ
SitsofeCAPACITY(16) won't be triggered.
static int sd_try_rc16_first(struct scsi_device *sdp)
{
Hi Doug,
The power on/off field together with fault, locate, and active are for
HDD (i.e. DeviceSlot and ArrayDeviceSlot). They are not for enclosure or other
elements. So we are not dealing with power off duration, etc. here.
Thanks,
Song
-Original Message-
From: Douglas Gilbert
32 matches
Mail list logo
