[patch 2/2] megaraid_sas: missing curly braces in megasas_detach_one()
The indenting indicates that there are supposed to be some curly braces
here. Presumably it means we free something unintentionally leading to
a use after free.
Fixes: 3761cb4cf65e ('megaraid_sas: JBOD sequence number support')
Signed-off-by: Dan Carpenter
---
Not tested.
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 829e9e9..91e200d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5932,7 +5932,7 @@ static void megasas_detach_one(struct pci_dev *pdev)
fusion->max_map_sz,
fusion->ld_map[i],
fusion->ld_map_phys[i]);
- if (fusion->ld_drv_map[i])
+ if (fusion->ld_drv_map[i]) {
free_pages((ulong)fusion->ld_drv_map[i],
fusion->drv_map_pages);
if (fusion->pd_seq_sync)
@@ -5940,6 +5940,7 @@ static void megasas_detach_one(struct pci_dev *pdev)
pd_seq_map_sz,
fusion->pd_seq_sync[i],
fusion->pd_seq_phys[i]);
+ }
}
free_pages((ulong)instance->ctrl_context,
instance->ctrl_context_pages);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/2] megaraid_sas: remove a stray tab
One line was indented more than the others.
Signed-off-by: Dan Carpenter
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index cc95372..829e9e9 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5923,9 +5923,9 @@ static void megasas_detach_one(struct pci_dev *pdev)
if (instance->ctrl_context) {
megasas_release_fusion(instance);
- pd_seq_map_sz = sizeof(struct MR_PD_CFG_SEQ_NUM_SYNC) +
+ pd_seq_map_sz = sizeof(struct MR_PD_CFG_SEQ_NUM_SYNC) +
(sizeof(struct MR_PD_CFG_SEQ) *
- (MAX_PHYSICAL_DEVICES - 1));
+ (MAX_PHYSICAL_DEVICES - 1));
for (i = 0; i < 2 ; i++) {
if (fusion->ld_map[i])
dma_free_coherent(&instance->pdev->dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
aacraid and rotational 1 even for ssd disks
Hi. I wonder if aacraid shouldn't properly inform kernel about sdd disk via /sys/devices/../queue/rotational flag? Using 3.18.22 kernel and aacraid driver tells linux that all drives are rotational: raid: # cat /sys/devices/pci:80/:80:03.0/:81:00.0/host10/target10:0:0/10:0:0:0/block/sda/queue/rotational 1 lvm on top of that raid: # cat /sys/devices/virtual/block/dm-*/queue/rotational 1 1 1 while this system has raid array of SSD drives only (INTEL SSDSC2BB30). No rotational disks. Adaptec ASR8405 7.8-0 (32730) firmware. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron
Hello, In continuation to the issue described in [1] and [2]: Unfortunately, I still suffer from the same problem on Linux kernel v4.2.3. The problem is in detailed described in [3], in particular I see the following in dmesg: sd 6:0:0:0: [sdd] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 6:0:0:0: [sdd] 4096-byte physical blocks sd 6:0:0:0: [sdd] Write Protect is off sd 6:0:0:0: [sdd] Mode Sense: 53 00 10 08 sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA ... sd 6:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sd 6:0:0:0: [sdd] tag#0 Sense Key : Illegal Request [current] sd 6:0:0:0: [sdd] tag#0 Add. Sense: Invalid field in cdb sd 6:0:0:0: [sdd] tag#0 CDB: Write(10) 2a 08 00 00 10 80 00 00 08 00 blk_update_request: critical target error, dev sdd, sector 4224 BTRFS: lost page write due to I/O error on /dev/sdd1 BTRFS: bdev /dev/sdd1 errs: wr 9, rd 0, flush 0, corrupt 0, gen 0 I believe that according to patches [4], [5] I should see something like "Disabling FUA" in logs. Any information about how to fix the problem is appreciated. > [1] http://permalink.gmane.org/gmane.linux.scsi/91997 > [2] http://permalink.gmane.org/gmane.linux.usb.general/120430 > [3] http://unix.stackexchange.com/questions/237204/ > [4] > https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+blame/v4.2.3/drivers/scsi/sd.c#2446 > [5] > https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+blame/v4.2.3/drivers/usb/storage/unusual_devs.h#1990 -- With best regards, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [dm-devel] [RFC PATCH 00/32] separate operations from flags in the bio/request structs
On Wed, Nov 04, 2015 at 10:53:39AM -0600, Mike Christie wrote: > > If you have to touch submit_bio() and submit_bio_wait(), how about > > requiring the callers of these functions to set the cmd and flags > > arguments in the bio structure and to leave out the cmd and flags > > arguments from the submit_bio() and submit_bio_wait() functions ? A > > (compile tested only) patch that implements this idea is available at > > https://lkml.org/lkml/2014/6/2/173. > > > > Yeah, I can do that. I think this would be useful to do at the beginning of the series. While this will have a huge trickle effect through the series it should make thing a bit simpler overall. By leaving op 0 undefined it should also help to create a nice error trap for unconverted code. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 32/32] block: remove __REQ op defs and reduce bi_op/bi_rw sizes
I love this series! Also I think it's very good that we finally split the ioprio out to it's own field. Thanks a lot for doing this work. > I was not sure if or how much or where people wanted to stick things. > There also appears to be room in the bi_flags field. If bi_flags is > only using 13 bits and there are only 16 REQ_XYZs bits related bios, > I could put them all in one variable if we wanted to go wild with trying > to shrink the bio while I am at it.. This sounds interesting, but I'd rather do it as a separate project later. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [dm-devel] [PATCH 19/32] block: add helper to get data dir from op
On Thu, Nov 05, 2015 at 11:34:07AM -0600, Mike Christie wrote: > I can do that. You are right in how they are used. I just did the above, > to follow the other *_data_dir calls. I think the *_data_dir calls are horrible interfaces. But your series already is huge, so if it makes your life easier I'd say keep it as-is for now. But in the long run we should have the interfaces that Bart suggested, and one that gives you a dma_data_direction from a request, as that's what a lot of the driver ultimatively want. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND RFC PATCH 00/32] separate operations from flags in the bio/request structs
On Wed, Nov 04, 2015 at 04:07:57PM -0600, mchri...@redhat.com wrote: > Known issues: > - REQ_FLUSH is still a flag, but should probably be a operation. > For lower level drivers like SCSI where we only get a flush, it makes > more sense to be a operation. However, upper layers like filesystems > can send down flushes with writes, so it is more of a flag for them. > I am still working on this. Actually it should be both. REQ_OP_FLUSH for a real flush operation, and a REQ_PREFLUSH bio flag that the request layer will sequence into an actual write an a flush operation. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
